Bandwidth Bucket Explorer: Video Rate vs Link Capacity

Uncompressed video is one multiplication: pixels per frame × frames per second × bits per pixel. Bits per pixel is itself bit depth × samples per pixel: 3 for 4:4:4, 2 for 4:2:2, 1.5 for 4:2:0. Four taps feed the flow, and the connector is a bucket with a hard rim. There is no negotiating with the rim: if the flow exceeds it, something must give.

What gives is the whole game of signal engineering. Keep 2160p60 but drop to 8-bit. Keep 12-bit but subsample to 4:2:2. Keep everything and halve the frame rate. Every spec-sheet line like "4K60 4:4:4 supported" is really a statement about which taps were quietly closed to make the water fit.

A "1080p" frame is not 1920×1080 on the wire; it is 2200×1125, a raster still carrying the horizontal and vertical blanking a CRT beam once needed to fly back. That heritage is why 4K60 needs a 594 MHz pixel clock (4400×2250×60), and why SDI's rates are so satisfying: 2200×1125×60 pixels × 20 bits of 4:2:2 10-bit is exactly 2.970 Gb/s. The number on the BNC is the raster, priced honestly.

DisplayPort, born in the PC world, uses CVT reduced blanking, a slimmer raster, which is partly why it squeezes in formats HDMI of the same vintage cannot. And SMPTE ST 2110 simply throws the blanking away: only active pixels ride the network. Forty years after the last CRT mattered, the industry is still deciding how much to pay for flyback time that no longer exists.

The number on the box is the raw line rate; the bucket is smaller. TMDS links (HDMI through 2.0, DisplayPort through 1.4) use 8b/10b coding: ten wire bits per eight payload bits, a flat 20% tax that turns HDMI 2.0's "18 Gb/s" into 14.4 usable. HDMI 2.1's FRL switches to 16b/18b (≈11% tax; 48 becomes ≈42.7), and DisplayPort 2.1's 128b/132b pays barely 3% (80 becomes ≈77.4).

SDI, characteristically, pays no line-code tax at all: scrambled NRZI, so the payload rate is the line rate. The lesson for reading spec sheets: always ask whether a number is raw or effective. Marketing quotes raw; the bucket only holds effective.

Broadcast's bucket lineage is a clean doubling series: SMPTE ST 259 (1989) carried SD at 270 Mb/s; ST 292 (1998) brought HD at 1.485 Gb/s; ST 424 (2006) doubled to 2.970 for 1080p60; ST 2081 and ST 2082 (2015) doubled twice more, to 6G for 2160p30 and 12G for 2160p60. The names are the payloads. One 75 Ω coax, a locking BNC, 100 m runs, zero handshake drama.

The trade for that honesty is rigidity: single-link SDI's standard mappings are built around 4:2:2 10-bit, the broadcast production format, and higher formats mean more links (quad 12G for 8K) or heavier mappings, not a menu of chroma modes. Broadcast chose determinism over flexibility, and for plant engineering that was the right call for thirty years. What replaces it is not a faster BNC: see the ST 2110 card.

HDMI 1.0 (2002) was DVI with audio and a friendlier plug, at 4.95 Gb/s. Version 1.4 (2009) stretched TMDS to 10.2 and delivered 4K at 30 Hz. Version 2.0 (2013) reached 18 Gb/s and created the crunch this module was built to explain: 4K60 fits at 8-bit RGB, or 12-bit 4:2:2, or 4:2:0, but never 10/12-bit 4:4:4. Every "why does my HDR look banded" forum thread of 2015 to 2019 lives inside that sentence. HDMI 2.1 (2017) replaced TMDS with FRL at 48 Gb/s: 4K120 and 8K60 become real, with 4:2:0 or DSC for the biggest formats.

The catch is that HDMI negotiates in secret. Source and sink read EDIDs, weigh cable quality, and settle on a format, and when the bucket would overflow they quietly downgrade rather than fail. The picture keeps working; the signal is just no longer what the menu says. That gap is a calibrator's daily bread (see the last card).

DisplayPort (VESA, 2006) is the PC-native answer, and its flexibility is architectural: video travels as micro-packets over 1, 2 or 4 lanes that negotiate their own speed, with no pixel clock on the wire at all. DP 1.2 (2010, HBR2) offered 17.28 Gb/s effective when HDMI had 8.16; DP 1.4 (2016, HBR3) reached 25.92 and adopted DSC early; DP 2.1 (2022, UHBR20) pays only a 3% coding tax on 80 Gb/s raw.

Packetization buys tricks a fixed-clock link cannot do: multi-stream (two monitors down one cable), USB-C alt-mode, fine-grained rate steps, reduced-blanking rasters. It is why same-vintage DP almost always swallows a format the contemporary HDMI cannot: compare DP 1.2 against HDMI 1.4 in the matrix, or DP 1.4's 4K120 against HDMI 2.0's.

VESA's Display Stream Compression is the escape hatch both modern links share: a line-based, fixed-rate codec around 3:1, adding well under a millisecond, rated "visually lossless" under the ISO/IEC 29170 test protocol, meaning trained viewers in side-by-side flicker tests could not reliably spot it. It is how 4K144, 8K60 4:4:4 and beyond ship over today's copper. Toggle it in the panel and watch two-thirds of the water fold away.

"Visually lossless" is a perceptual claim, not a mathematical one, and it was validated on pictorial content, not on single-pixel calibration patterns or synthetic gradients. For most work it is genuinely transparent; for measurement chains it is one more transform between generator and panel, and you should at least know whether it is on. Most chains will not tell you unless you ask the OSD.

SMPTE ST 2110 (2017) stops asking "which cable" entirely. Video, audio and ancillary data become separate RTP streams on ordinary IP networks: 2110-20 carries only the active pixels, audio travels as 2110-30, everything locked to nanosecond-grade PTP time (ST 2059) instead of a house sync pulse. Capacity is no longer a connector property: it is whatever Ethernet you buy. A 25 GbE port swallows 4K60; a 100 GbE spine carries dozens of HD streams; 2110-22 adds JPEG XS as a roughly 10:1 mezzanine when even that is not enough.

This is the looking-ahead answer: broadcast plants are already rebuilding around it, and IPMX is carrying the same architecture into pro-AV. The bucket does not get bigger forever: at some point you stop carrying water and lay pipe. The trade is complexity: an SDI cable either works or does not; an IP fabric has PTP domains, multicast routing and QoS to misconfigure.

In the field, an overflowing bucket almost never announces itself. The chain renegotiates behind your back: the pattern generator's menu says 4K60 12-bit 4:4:4, an AVR in the middle only passes 18 Gb/s, and the panel quietly receives 4:2:0, or 8-bit, or a black screen with a handshake loop. EDIDs lie, long cables drop lanes, and every device in the path has its own opinion about what fits.

So the working rule: never trust the menu, verify the link. Confirm what the display actually receives (most panels report the incoming format), test with patterns that expose subsampling and banding, and treat every splitter, extender and receiver as a suspect bucket. It is not measured until the signal path itself is verified: that's part of what a calibration visit is for