lotus

previous page: 03  So how does MPEG I work?
  
page up: MPEG FAQ
  
next page: 05  Hmm. Where did they get 352x240? (MPEG-video)

04 So is each frame predicted from the last frame? (MPEG-video)




Description

This article is from the MPEG FAQ, by Frank Gadegast phade@cs.tu-berlin.de with numerous contributions by others.

04 So is each frame predicted from the last frame? (MPEG-video)

No. The scheme is a little more complicated than that. There are
three types of coded frames. There are "I" or intra frames. They
are simply a frame coded as a still image, not using any past
history. You have to start somewhere. Then there are "P" or
predicted frames. They are predicted from the most recently
reconstructed I or P frame. (I'm describing this from the point
of view of the decompressor.) Each macroblock in a P frame can
either come with a vector and difference DCT coefficients for a
close match in the last I or P, or it can just be "intra" coded
(like in the I frames) if there was no good match.

Lastly, there are "B" or bidirectional frames. They are predicted
from the closest two I or P frames, one in the past and one in the
future. You search for matching blocks in those frames, and try
three different things to see which works best. (Now I have the
point of view of the compressor, just to confuse you.) You try using
the forward vector, the backward vector, and you try averaging the
two blocks from the future and past frames, and subtracting that from
the block being coded. If none of those work well, you can intra-
code the block.

The sequence of decoded frames usually goes like:

IBBPBBPBBPBBIBBPBBPB...

Where there are 12 frames from I to I (for US and Japan anyway.)
This is based on a random access requirement that you need a
starting point at least once every 0.4 seconds or so. The ratio
of P's to B's is based on experience.

Of course, for the decoder to work, you have to send that first
P *before* the first two B's, so the compressed data stream ends
up looking like:

0xx312645...

where those are frame numbers. xx might be nothing (if this is
the true starting point), or it might be the B's of frames -2 and
-1 if we're in the middle of the stream somewhere.

You have to decode the I, then decode the P, keep both of those
in memory, and then decode the two B's. You probably display the
I while you're decoding the P, and display the B's as you're
decoding them, and then display the P as you're decoding the next
P, and so on.

Q. You've got to be kidding.
No, really!

 

Continue to:













TOP
previous page: 03  So how does MPEG I work?
  
page up: MPEG FAQ
  
next page: 05  Hmm. Where did they get 352x240? (MPEG-video)