還有B-Frame
==========
MPEG4 video is based heavily on H.263 - most of the MPEG4 docs assume a prior knowledge of H.263 so you may be better off looking for it instead.
B-frames are one of 3 different frame types that MPEG4 supports. I-frames (Intra frames) are completely self-contained, that is they don't reference any other frames. These are commonly called key frames. P-frames (Predicted (?) frames, can't remember for some reason) are frames which reference the frame that came before it for image data. Each 16x16 block (macroblock) of a P-frame can either be encoded independently of anything else (an "intra" block) or be "compensated" from the frame that came before it. By expoiting the similarities often found in subsequent frames, P-frames are significantly smaller than I-frames - the cost is that you must decode every preceding P-frame from the last I-frame in order to decode one.
B-frames are a different matter, and complicate the encoding/decoding procedure by quite a bit. They are "Bidirectional" frames, meaning that they can reference frames that come both before and after itself. How can a frame reference a frame that comes after itself, you ask? The encoder reorders the frames so that they are no longer stored one after the other in order, that's how.
Say you had 4 frames. You wanted the first to be an I-frame (naturally), the next to to be B-frames (as they are usually a quarter of the size of P-frames, to give you some idea of the compression benefits), and the last frame to be a P-frame (as B-frames need something ahead of themselves to be predicted from). The frames would sequentially look like this:
1 2 3 4
I B B P
However, they would be stored in the file as:
1 4 2 3
I P B B
After encoding the I-frame, the encoder skips ahead and grabs the frame that is destined to be the P-frame, and encodes it as if it immediately followed the I-frame. Now, that will increase the size of the P-frame, as more will have changed between the I-frame and itself over the 2 intermediate frames, but we are hoping that the B-frames will make up for this loss of compressability. Now we have an I-frame and a P-frame compressed. Once this is done, the encoder goes back to the second frame (which was destined to be our first B-frame), and references both the I-frame and the P-frame to find similarities. Once the first B-frame is completed, the encoder again uses the original I-frame and the P-frame to compress the second B-frame. Note that B-frames can't reference other B-frames for finding matches.
As you can see, B-frames make things messy
Anyway, here's another diagram:
1 2 3 4
I B B P
1. Codec compresses I-frame
2. Codec jumps ahead and compresses P-frame as if it immediately followed the I-frame. Our bitstream now contains:
1 4
I P
3. Codec grabs the 2nd frame, and references both the I-frame and the P-frame to compress it. Adds compressed B-frame to bitstream:
1 4 2
I P B
4. Codec grabs the 3rd frame, and references both the I-frame and P-frame to compress it. We have finally completed our encoding:
1 4 2 3
I P B B
Since B-frame encoding requires frames to be fed to the encoder "out of order", there is talk of creating a custom encoding program to generate XviD AVI's containing B-frames. These AVI's will be playable with all the normal tools (Media Player, PowerDivX, etc.), it's just the encoding that's tricky.
Hope that's made things less (more?) confusing.
-h
And this, again by -h:
The I-frame quantization settings restrict the quantizers that may be used for I-frames (key frames). If you set the min and max to 2 and 2, then the keyframes in your movies will be high quality and large in size.
Now, because of the way the 2-pass "bit bucket" works, setting the I-frames to artificially low quantizers will result in the P-frames following it to have extremely high quantizers - such a quick jump will produce ugly output. So, the "Smooth quantizers" checkbox will prevent the quantizer from jumping too far between subsequent frames.
If you're going to mess with the I-frame quantizers, you should check that box.
-h
==========
再還有
來自射手網的介紹
http://bbs.et8.net/bbs/showthread.php?threadid=273867http://www.shooter.com.cn/?artid=55&show=1==========
B 帧在 MPEG-4 中有四种参考模式，如果是同时参考前后的画面压缩，
则记录的是 和 (前画面 pixel 值 + 后画面 pixel 值)/2 的差值，
也就是 和 「前后画面的平均」的差值。
所以记录的差值个数和 P 帧一样，只有一个，没有增加。
而因为 B 帧位于前后画面的中间，以「前后画面的平均」，也就是「前后画面的中间值」
来作为预测数值（预测 B 帧的 pixel 数值为多少？如果有误差，再记录差值），
这样这个预测数值会比单独使用前一个画面来预测，更接近目前真正的 B 帧的数值，
可想而知，如此所需要记录的差值就会很小甚至可以根本不用记录，
所以便可以省下很多的 bits，提高压缩率。
例如
亮度变化 ->
I B P
7 8 9
如果 B 只参考前一个画面压缩，则需记录差值 1。
如果以 (I + P)/2 压缩，则差值为 0，不需记录差值。
（虽然要记录两个矢量，不过矢量也可以再做进一步预测压缩，总的来说，
还是会比单独参考前一个画面压缩来得小很多）
如果画面不是这样变化怎么办？通常来讲画面都会是这样变化，
如果不是这样变化我们就不使用 B 帧
就算变化不是如此规则，换个方式想，B 帧可以参考的画面还是比 P 帧多，
再怎么找，也还是 B 帧可以找到误差更小的方块来使用的机率大
（因为可以选择、参考的对象较多），所以 B 帧还是比 P 帧的压缩率来得高。
（而且高很多，差距非常大）
除了压缩率以外，B 帧对画质的影响.....
是有的，因为 B 帧这种参考前后画面的特性，等于有内插（interpolation）的效果，所以可以减少噪讯。
MPEG-4 中的 B 帧，也是非常具有威力的，除了以前的三种参考模式，
还有 Direct Mode，连矢量的纪录都省了。
虽然 MPEG-4 之中有 4MV 的功能，可以记录四个矢量，不过编码器在压缩的时候会判断，
到底是使用 4MV 压出来的结果小，还是使用传统的方法压出来的结果小？
如果使用传统的方法压出来的结果小，便使用传统的方法记录，
如果使用 4MV 压出来的结果小，才使用 4MV 来记录。
（ps. 4MV 不会用在 backward 预测）
您可以观察 VirtualDub 压缩时画面上显示的蓝线，您会发现蓝线和蓝线之间通常会有很短的
蓝线插在中间，造成空隙，而且差距很大，这个就是夹在 P 之间的 B 在发挥压缩威力
如果是用 DivX 5 更明显，因为 DivX 5 只能够使用 IBPBPBPB... 这种一个 B 接一个 P 的形式，
所以画面上的蓝线就是「一长一短、一长一短」这样排列。
==========
