Info requested...

[MoonWalker]

It might be a little "off-forum" this question...

Where can i find information about mpeg-4 codecs?How do they work?Which are the standards.What is B-frame(it will bue used by XviD)..Any site??


Thanks,
MoonWalker

[-h]

Good question.

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 uses that B-frame and the P-frame to compress the second B-frame.

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 B-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

[Nic]

Thanks for that -h, I'd been wondering about B-frames for a while & couldn't find a description half as good as that :)

Cheers + Thanx,
-Nic

[MoonWalker]

Greatly thanks -h...You know I study electronics and I want to know more about mpeg4 and those stuff cause I am interested to build(I don't Know if this possible) a mpeg-4 player.I have found a great microcontroler that you can implant c code ;)...But I am at veeeery early stages...:)

Thanks,

MoonWalker

[-h]

Greatly thanks -h...You know I study electronics and I want to know more about mpeg4 and those stuff cause I am interested to build(I don't Know if this possible) a mpeg-4 player.I have found a great microcontroler that you can implant c code ;)...But I am at veeeery early stages...:)

Ouch :)

I wish you good luck.

-h

[rui]

Originally posted by Nic
Thanks for that -h, I'd been wondering about B-frames for a while & couldn't find a description half as good as that :)

Cheers + Thanx,
-Nic

-h, i believe you should consider a career in teatching ;)

[Foo]

@ -h

How will this (b frames) effect encoding speed? Will this be another option in the config, or a seperate branch altogether?

cheers,

foo

[-h]

How will this (b frames) effect encoding speed? Will this be another option in the config, or a seperate branch altogether?

Encoding should be around 40% slower. You can test this yourself - set the motion search precision to 5 and see how long a clip takes to encode. Now encode the same clip with motion search precision set to 0 (this disables motion estimation) - the difference is the time spent in the motion estimation phase. Since B-frames perform motion estimation on 2 frames instead of one, each B-frame will spend twice as long in the motion search phase as a normal P-frame. I dare say the compression will be worth it, however.

Decoding should be pretty much the same speed.

B-frames will be an option in the encoding program eventually used, in conjunction with an option in the codec config - you won't be able to encode them using just the codec alone.

-h