malvasia bianca

I’ve been reading through the MPEG 2 standard recently, specifically the video parts. It’s pretty interesting, in a weird way; makes me want to go out and write an MPEG decoder, just to experience that particular sort of complexity, except that doing so would take years with no real reward at the end. I’m used to standards that are either much more straightforward to understand, or if they aren’t (C++), they’re complicated because they want to expand the realm of what’s theoretically possible, and doing that expansion into areas that aren’t well understood.

MPEG is different. MPEG just wants to be able to paint pixels on the screen, and have those pixels change over time. It is, of course, trivial to come up with a format that allows you to describe this. But you need the resulting files to be small enough to fit on disks using current manufacturing technology, or to be streamed over the air using currently available transmission technologies. You need them to be able to be decompressed quickly using current hardware (which can, admittedly, be custom-made for the purpose). You need them to play on current TV’s, not just current computer monitors. And you need them to be good at compressing certain specific kinds of content, like movies and TV shows. I am not used to formats in which all these challenges come together this way.

Take frame rate, for example. If I were designing a format, I’d just say “make it an integer, the number of frames per second”, and if pressed, my first reaction would be “computers usually use 32 bits these days, so let’s go with that”. But of course we don’t need movies that contain 4 billion frames per second, so I would admit that only 16 bits, or even a lowly byte would probably be adequate.

But, actually, MPEG uses (if I’m remembering correctly) 4 bits for this. They don’t do this by limiting the frame rate to 16 frames per second – instead, they only allow a few specific frame rates, so 0001 stands for a certain frame rate, 0010 for another, etc. MPEG cares about TV, so one of the allowed frame rates is 30 frames per second. Except that TV actually shows 60 half-frames per second (because of interlacing), so MPEG also allows 60 frames per second. And MPEG cares about encoding movies, which are at 24 frames per second, so that’s another value. And it’s a world-wide standard, while the 60 half-frames per second is an NTSC thing, so it allows 50 and 25 frames per second for PAL content.

But that’s not the whole story. In fact, TV isn’t 30 (or 60) frames per second – it’s 29.97, more or less. The story here is that TV used to be black and white, of course, so only brightness (“luminance” is the term used) was encoded. Then, to add color, they stole a little bit of bandwidth by (among other things, I think) squeezing the frame rate ever so slightly, to 29.97 (or 30,000 / 1001, I think) frames per second. (This also means that TVs expect much less color data than luminance data, which also leaves relics in the MPEG standard, but never mind that.) So MPEG can be at exactly 24, 30, or 60 frames per second, but it can also be at 23.97, 29.97, or 59.94 frames per second. But for 25 or 50 frames per second, only the exact values are allowed, because the historical reasons only apply to NTSC, not PAL.

(Side note: Manny! Good start to the playoffs.)