Orchid XP v8 wrote:
> The MPEG standard specifies *exactly* how to decode an MPEG file into 
> something that can be displayed. However, it leaves several parts of the 
> *encoding* process open to interpretation.

Yep. And the parts that are left open are difficult to implement. For 
example, one of the decoding commands is "take the block of pixels from 
X1,Y1 in the previous frame and draw them at X2,Y2 in this frame." 
(Called something like "motion compensation".) Which means you have to 
look all over the current frame to try to find a block of pixels that 
matches the previous frame somewhere. Works well for fast-moving 
objects, like a car driving past, but computationally expensive.

Plus, there's I frames, P frames, and B frames. Normally it's encoded 
something like
   IbbPbbPbbIbbPbbPbbI....
where the I frames are basically jpeg, the P frames are differences from 
the I frames, and the B frames are differences from both the previous 
frame and the following frame.  Lots and lots of encoders only go one 
direction, so they don't even generate B frames, which are usually far 
smaller than the other two types of frames.  (The I frames are the ones 
you can seek to, and the P frames are the ones you can show when you 
"fast forward" basically. Usually, I frames are twice a second or so.)

You can check pretty easily by trying to compress some video that's 
flattish (like, looking into cloudy water, say) and some that's moving 
fast in lots of directions (like explosions) and see if you see artifacts.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message