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.

Ada Lovelace Day - Valerie Aurora

So, it's Ada Lovelace Day. The day on which geeks everywhere are asked to point out geeky women who've inspired them. I would love for this to be an irrelevance, and for no-one to care that much; unfortunately, the geek community is still male-dominated. I've therefore picked on Valerie Aurora as a geek who's work inspires me, and who happens to be female.

Why do I find Val's work inspiring? In part, it's inspiring because she tackles important problems; not necessarily interesting problems to the general population, but problems that need to be dealt with now. However, there are lots of programmers who do that; what makes this one special?

The difference in Val's work is the clarity of explanation she produces. Most programmers struggle to explain their work to other programmers in the same field; if you read any of the publications linked on her homepage, you'll note that she writes clearly and concisely in English, not just in the usual set of programming languages. Combine that with the high technical standards maintained in the publications and in Val's work on things like the Linux kernel, and I'm impressed.

To top all this off, she's written a very good document aimed at encouraging women to break out of unfair social constraints: HOWTO negotiate your salary. Often, all it takes to break a bad cycle is someone to notice it, and point it out to the people involved; this document is a perfect example of how to make a difference.

It's often said (with good cause) that when members of a previously underrepresented group enter a field, they have to be not just good, but noticeably above average. Val's work fits this stereotype, and sets a standard that I hope to be able to meet one day.

DIY garden replacement

People who know me well know that about 3 years ago, my wife and I bought a house in need of a lot of TLC. This week's decision has been that we should redo the garden before hay fever season makes it horrendous to go outside.

We've got a lot ahead of us. The grass isn't appropriate for a lawn, there's stones everywhere, and Rachael wants a vegetable patch. The current plan of campaign is to use two weekends to do it.

Weekend 1 plans

• Hire a sod cutter and remove the entire top surface of the garden.
• Tear down the remains of the shed.
• Place new turf over the lawn area.
• Cover the area that's going to be vegetable garden with plastic sheeting.
• Cover the area that'll be used to extend the patio with plastic sheeting.
• Cover the area that'll be used for a new shed with plastic sheeting.

Weekend 2 plans

• Buy a new shed, cement, and a taller pole for the satellite dish.
• Cement in the tall pole.
• Move the satellite dish and recable.
• Lay the shed foundations.
• Put up the new shed (just for storage space, no need for power/light).
• Lay extra patio.
• Start putting in raised beds (large) for the vegetable garden.

As you can see, this is a fairly hefty work plan; I hope we're up to it...

Calculating the number of VoIP channels you can fit on an ADSL line

A question that occasionally comes up in the #A&A IRC channel is "how many VoIP channels can I fit on one ADSL line?" The answer is quite simple to calculate, and you can do similar arithmetic for other realtime traffic:

We start with some general knowledge; people who read my previous post on ADSL overheads will be aware that ADSL sync rates are the number of ATM cell bits you can fit down the line. ATM cells are 53 bytes long, so you divide your sync rate by 424 (bits per cell) to get the cell rate. So, all we need to know is how many cells per second in a VoIP call. The table below has details of all the bits in a single 20 millisecond packet of G.711 (a-law or µ-law) VoIP:

Bytes	Reason
8	AAL5 trailer
2	PPP framing for PPPoA
20	IPv4 header
8	UDP header
12	RTP header
160	G.711 voice data

This adds up to 210 bytes; cells carry 48 bytes each, and can only be used for one packet, so we need 5 cells, with 30 bytes padding. There are 50 of these packets in a second of VoIP, so each call needs 250 cells/second, or 106 kbit/s of sync rate.

Because we have 30 bytes of padding, we can deduce that the extra 20 bytes overhead of PPPoE won't hurt us; nor will the extra 20 bytes header size of IPv6. However, if we use both IPv6 and PPPoE, we will need one more cell per packet, making it 6 cells for one packet, or 300 cells/second, or 127.2 kbit/s of sync rate per call.

We know we need a little spare capacity for signalling and monitoring, but from this, we can deduce that a 448kbit/s ADSL upstream (IP Stream Standard) can support 4 calls, or 3 if you're using both PPPoE and IPv6. An 832kbit/s upstream supports 8 calls, or 6 if you're using both PPPoE and IPv6. The 2MBit/s I get on Annex M supports 15 calls with PPPoE and IPv6, or 18 calls with either IPv4 or PPPoA.