Tim Lesher wrote: > > "Jeremy C. Reed" wrote: > > > I am looking at the Berkeley mpeg_encoder. I am a little unfamiliar MPEG > > II -- is it lossless or does it lose data from every load and then resave > > (using an editor)? > > Yes. Almost all video codecs have some generational loss; MPEG is a > particularly bad one, unless you use "editable" MPEG (I-frame only). > > Most Quicktime and AVI compressors, except MJPEG and editable MPEG, > also share this trait. > > However, if your editor is really worth its salt, it won't > recompress the entire video, just the cut ends of it. Then the parts that > aren't changing can be sent back to the file wholesale. The problem with MPEG is not really generational loss per se (unless you for some reason are filtering rather than merely editting). The problem is reconstructing a valid stream. The video is divided in to GOP's - groups-of-pictures. Usually 12 frames worth. Only the first of the 12, the I-frame, is stored in its own right (more or less like a JPEG image). The rest are sub-divided into P-frames and B-frames. The P-frames typically come every 3rd frame and are store the change in image from the nearest preceding P or I frame. The B frames store (on a block by block basis) differences forward from the nearest preceding P frame, differences backward from the next following P frame, or even differences from average of the two nearest P frames. Obviously, if you simply cut and paste MPEG it won't work. The I and P frames will refer to images that "aren't there" in the editted stream. Worse still, you can't easily just "correct" by re-encoding around the seams. The problem is bit-allocation. A good MPEG encoder works very hard to maximise the efficiency with which pictures are stored. Typically, it keeps track of how full the decoders buffers are likely to be to see how many bits it can use for encoding the current GOP and carefully optimises the allocation between I,B and P frames. Obviously, at the edit point all those calculations will be invalidated. Furthermore the mere fact that it is an edit may mean abrupt scene changes and big bit demands. The upshot is that the encoder would have to re-encode a surprisingly long way either side of the edit to free up enough bits to make a valid stream. This is where the generational losses creep in. The usual result is that editting packages simply don't support MPEG or just do a minimal hack to legalise the result (with usually rather visible results!). Andrew
