How a 1980s telecoms compromise helped set the Bluray video format.

I've mentioned the ATM committee's weird decisions before, when talking about ADSL; this post is meant to make you think about how seemingly small committee decisions can have long term impact.

To recap; in the 1980s, telecoms engineers were setting standards for "fast" data links (45MBit/s and above), to be used to carry voice, fax and data; the decision was made to use small cells, so that even slow links could use the same standard. The resulting standard, ATM, has a 48 byte payload and a 5 byte header on every cell.

There's only one standard set worth considering if you're interested in serious video; the MPEG standards. Both DVD and Bluray are built on MPEG; DVD uses MPEG-2 exclusively, carrying video and audio in an MPEG-2 program stream, extended to add timecode to packets, resulting in the "VOB" file format. This has limitations when it comes to seeking; when an optical disk player seeks, it moves the read head to a location that's approximately right, then reads the disk until it finds the timecode it's after, then either moves the heads again (to a better estimate of the correct place), or resumes playback. Because program stream packets are variable-length, the player can end up reading a significant amount of data, only to discover that the timecode tells it that it's badly off, and it has to seek again.

Bluray escapes this by using MPEG-2 transport streams as the container, but with a 4-byte timecode added to each transport packet. Transport stream packets are fixed in length at 188 bytes, so a Bluray player never needs read more than 192 bytes after seeking before it can decide whether it needs to seek again to a better guess at the correct location, or whether it can just read to the right point.

188 bytes is a rather unusual number; the header is 4 bytes long, and the payload length of 184 bytes is neither a nice number for humans, nor is it a nice number for computers to deal with. So, why did the MPEG-2 committee choose 188 bytes for transport stream packet size? It all comes back round to ATM; when MPEG-2 was being designed, ATM was the telecommunications networking technology of choice, and it was considered important that you should be able to easily carry MPEG-2 transport packets in ATM.

There are two sensible ATM Adaptation Layers for MPEG-2; AAL1, meant for constant bit rate services (such as carrying a multiplex from BBC headquarters to the Freeview transmission sites around the country), and AAL5, for services that can cope with a long delay. AAL1 takes 1 byte from every cell's payload, leaving 47 bytes for the user; 47 times 4 is 188, which is where MPEG-2 gets 188 bytes from. It also works well for AAL5; AAL5 uses 8 bytes from every group of up to 1366 cells, leaving 40 bytes in that cell and 48 bytes in the remaining cells in the group for user data; two 188 byte packets plus 8 bytes of AAL5 overhead fit precisely in 8 cells with no padding.

So, to interoperate well with ATM, the MPEG-2 guys chose 188 bytes for their fixed-packet-length container. MPEG has been wildly successful, so that the Bluray guys didn't want to design their own container format. As a result, a compromise between France (who wanted 32 bytes payload), and the USA (who wanted 64 bytes payload) has influenced the design of the most modern consumer video format to date. Next time you're compromising on a technical issue, think hard; your compromise may live on longer than you expected, and affect more people than you thought it would.