(no subject)

[noahgibbs]

I've been mostly off LJ for the last week. You people post a lot. I'll probably be caught up by later today, at least with the much-reduced reading list I scan regularly.

I'm going to my post-surgery followup shortly, at about 9:30 this morning. I don't expect any problems, but rest assured, I'll tell people if there are any.

Anybody know a good online reference on MPEG decompression and/or format? I know JPEG pretty tolerably already, but we're talking about hardware MPEG acceleration stuff at work, and my current knowledge of decompression is, at best, rough. I'm thinking MPEG3 or maybe H.264 here... Full-on MPEG4 is simply too wide a variety of codecs to allow this discussion to usefully occur, much less for me to really understand in a day or two :)

Comments

[msde.livejournal.com]

The best I've seen is http://www.mp3-tech.org/programmer/programmers.html
Even then, you may have to figure a lot of it out by reverse engineering reference implementations.

Licensing issues when writing your own mp3 decoder look annoying.

[mj2q.livejournal.com]

Heh, I have some modules for a hardware mpeg implementation right here on my computer. Can't give it to you though :P

[http://users.livejournal.com/_duncan/]

Well, ya know, I have just the guy in mind...

[zqfmbg.livejournal.com]

The MPEG standards are available at the ISO, but they cost money. As for the basics, I have a pretty good grasp of it (having wrestled with the damn thing for years), but I'm not really sure that it all came from one source... I think it was just piles and piles of reading accumulated over a course of years that gave me my mental image. I don't really know of any good online sources, so I'll just do a mild braindump.

If you know JPEG, then MPEG itself is a, shall we say, extension of it. You basically use the DCT, quantize high-frequency bits, then pack in as much of that stuff as you can based on how many bits you have available. However, MPEG also supports motion compensation, where if you know a certain block of pixels in one frame moves to another area in the next, you can encode this as a position change and save even more on the ever-scarce bits. I think this is pretty much it, at least up to MPEG-2, though there may be other frame-difference modes I forget. (MPEG-4 seems to define more than just a basic video stream, but I haven't had time to mess with it.)

In MPEG speak, video is encoded into I-, P-, and B-frames. I-frames are "intra-coded" and depend only on themselves for reconstruction, so they're basically JPEG pictures. P-frames are forward-predictive frames only; they depend on themselves and the previous frame (I-frame or not, I forget) for reconstruction. B-frames depend on both the frame before and frame after. Typically, you'll find groups of frames consisting of an I followed by a series of P and B. Be warned that the order in which the frames appear in the stream is not always the same as the order in which they are to be displayed.

The standards are nice enough to say "this is how the bitstream should look; this is what features we support in it; this is how the decoder should operate"; in essence, making encoder design open-ended. So designing an MPEG encoder is complicated stuff while designing an MPEG decoder basically amounts to taking their idealized decoder and figuring out how to make it efficient for your target.

Oh, and as far as I know there is no MPEG-3. There's MPEG-1 (coded pictures up to around 1.5 Mbps), MPEG-2 (

[zqfmbg.livejournal.com]

(argh, hit the wrong key and it submitted)

MPEG-2 (generic coding, usually for higher bitrate applications like DVD), MPEG-4, MPEG-7, and MPEG-21. Why they chose this numbering scheme is a total mystery to me.