What's the point of B-Frames?

[smitbret]

I have been converting some BR Rips to AVC/AC3 .m2ts files for playback with my PS3. Some of them had horrible blocking in shadow and dark areas after I had tried to re-encode them to a smaller size. Given enough bitrate, they would go away, but then the file was barely smaller than the original so I pretty much just remuxed them and left them as raw rips.

After doing some research and tinkering, I tried to re-encode with the b-frames set to "0" and BINGO... no more blocks. So I guess my question is what is the point of b-frames at all?

I didn't really notice much difference in re-encoding times. I also haven't had time to completely rewatch the couple of movies that I re-encoded so maybe there is some other image quality issue that I haven't noticed yet.

[filmboss80]

After doing some research and tinkering, I tried to re-encode with the b-frames set to "0" and BINGO... no more blocks. So I guess my question is what is the point of b-frames at all?

File size. Compression.

Duh...

[smitbret]

After doing some research and tinkering, I tried to re-encode with the b-frames set to "0" and BINGO... no more blocks. So I guess my question is what is the point of b-frames at all?

File size. Compression.

Duh...

Then why was my video quality better for the same amount compression when b-frames were turned off?

[Cornucopia]

Not wanting to point fingers, but I'd say (without seeing either of the videos) that the settings were wrong on the 1st and possibly even the 2nd encode.

Scott

[filmboss80]

If you use the exact same bitrate on both encodes, the size of the video file with the b-frames will be smaller than the one without the b-frames. (Of course, if you don't use many B-frames in the GOPs, the difference in file sizes may be negligible.) B-frames are more compressed than I-frames or P-frames. That is why you get blocks in b-frames using the low encoding bitrate you evidently use. The lower your bitrate, the more your b-frames are affected.

Or did you assume that video engineers created b-frames for no other reason than to frustrate you?

[smitbret]

If you use the exact same bitrate on both encodes, the size of the video file with the b-frames will be smaller than the one without the b-frames. (Of course, if you don't use many B-frames in the GOPs, the difference in file sizes may be negligible.) B-frames are more compressed than I-frames or P-frames. That is why you get blocks in b-frames using the low encoding bitrate you evidently use. The lower your bitrate, the more your b-frames are affected.

Or did you assume that video engineers created b-frames for no other reason than to frustrate you?

This is the answer I was looking for. Thanks. I literally wanted to know why b-frames were even useful. All I understood was that B-frames were partial frames but I didn't understand why they were useful when you already had P and I frames. I have a very rudimentary knowledge of encoding and finger pointing will be useful in this case.

I had originally re-encoded a 29GB file with a CQ setting of 18 in Ripbot264. The resulting file was 11GB and had blocking in the shadows. So I tried again with a CQ of 14 and the resulting file was 24GB and still had blocking. I went back, set the b-frames to "0" and set up a 2-pass 18GB target and it seems to accomplish everything I needed. What I gleen from this is that 11GB is sufficient for general PQ versus the original, but that would necessitate B-frames that would introduce blocking.

I'm really not obssessed with squeezing out every last bit of efficiency from my encodes. A 30-35% space saving makes me more than happy if the PQ doesn't suffer. If I remove the B-frames and set a 2-pass for a target about 2/3 of the original I can't tell the difference and that makes me happy.

I would love to hear any other ideas or if anyone knows where on the internet I can learn more about h264 settings and hwo to do a quality encode, then I would be more than happy to put the time in to learn. Right now, everything I read seems to assume I either know lot more than I do or that I'm dumber than a post and just need to set the CQ between 18 & 22 and let the software do the work.

[Cornucopia]

and to add to what filmboss80 just said,

Encoding B-frames and ending up with blockiness connotes bitrate-starvation (among other things). Fixing the blockiness by removing the B-frames is actually counter-productive, because NOW your bitrate needs (in order to remain blocky-free) are higher.***
If the subsequent encode shows NO blockiness, the original problem was probably not just strictly about bitrate starvation (like I said, there are other things involved).

***If an I-frame for a given resolution & quality uses up 100% of the bitrate required for that quality,
a P-frame uses up ~35-55% of that bitrate, and
a B-frame uses up ~10-25% of the bitrate.

This is a rough average, as the more MOTION & RANDOMNESS is involved, the harder it is to code P- and B-frames (those are some of those OTHER THINGS I mentioned), possibly to the point where it MIGHT be less to encode all I-frames (but not likely).

Scott

[smitbret]

and to add to what filmboss80 just said,

Encoding B-frames and ending up with blockiness connotes bitrate-starvation (among other things). Fixing the blockiness by removing the B-frames is actually counter-productive, because NOW your bitrate needs (in order to remain blocky-free) are higher.***
If the subsequent encode shows NO blockiness, the original problem was probably not just strictly about bitrate starvation (like I said, there are other things involved).

***If an I-frame for a given resolution & quality uses up 100% of the bitrate required for that quality,
a P-frame uses up ~35-55% of that bitrate, and
a B-frame uses up ~10-25% of that bitrate.

This is a rough average, as the more MOTION & RANDOMNESS is involved, the harder it is to code P- and B-frames (those are some of those OTHER THINGS I mentioned), possibly to the point where it MIGHT be less to encode all I-frames (but not likely).

Scott

So, then my guess at 30-35% with b-frames turned off should be ok for general use and will probably show negligible difference for a movie like 'Sophie's Choice", but may not be sufficient something like "Crank"?

[Cornucopia]

Something like that...

Scott

[smitbret]

Correction, I should have said 30-35% reduction should work with no b-frames.

Thanks for the guidelines, Cornucopia. I will adjust from there.

[manono]

If you use the exact same bitrate on both encodes, the size of the video file with the b-frames will be smaller than the one without the b-frames.

Not likely since filesize is entirely dependent on bitrate and the length of the video, and has nothing to do with whether or not B-Frames were used.

[dragonkeeper]

I had originally re-encoded a 29GB file with a CQ setting of 18 in Ripbot264. The resulting file was 11GB and had blocking in the shadows. So I tried again with a CQ of 14 and the resulting file was 24GB and still had blocking.

Did you tweak any other settings? Are you using the profiles that come with Ripbot or have you downloaded other profiles. Something sounds a bit off, I recently switch to Ripbot to back up my HD-DVD collection to my HTPC (Megui didn't seem to like evo files) all the movies i have backed up thus far look great. I also just encoded some test clips from "Dark City", "The Matrix" and "The Dark Knight" from my collection of blu-ray titles these look great as well. I purposely choose some of the dark scenes to encode. I encoded the scenes at 18 CQ, then 20 CQ, 22 CQ, and finally at 24 CQ, none of the encodes have any blockiness in the them.
I'm viewing these on a 12" foot screen so any errors (blocks etc) would clearly be visible.

[jagabo]

If you use the exact same bitrate on both encodes, the size of the video file with the b-frames will be smaller than the one without the b-frames.

This is the answer I was looking for.

Unfortunately, it's wrong. At the same bitrate both will be the same size. That's the whole point of bitrate based encoding. At the same CRF or QP they file with b frames will be smaller.

B frames reduce the bitrate requirement in two ways:

1) The are encoded with a higher quantizer (lower quality). The idea being that having a few frames of lower quality for a short period of time won't be noticeable most of the time. An i or p frame will come along soon and clean up the picture. With bitrate based encoding the lower bitrate used on the b frames means more bitrate can be used on the i and p frames -- hopefully increasing the perceived quality.

2) b frames can use motion vectors from both prior and future frames, not just prior frames (p frames can only refernce prior frames, i frames are encoded in their entirety, much like a JPG image). In theory this can reduce the bitrate even more

In my experience #1 is responsible for most of the bitrate savings. You can force the encoder to use the same quality for b frames as it does for p frames (--pbratio 1.0 in x264). If you do that you'll find only a tiny difference in the size of a CRF encode with ibp frames compared to an encode with only ip frames, with most material.

[smitbret]

If you use the exact same bitrate on both encodes, the size of the video file with the b-frames will be smaller than the one without the b-frames.

This is the answer I was looking for.

Unfortunately, it's wrong. At the same bitrate both will be the same size. That's the whole point of bitrate based encoding. At the same CRF they file with b frames will be smaller.

B frames reduce the bitrate requirement in two ways:

1) The are encoded with a higher quantizer (lower quality). The idea being that having a few frames of lower quality for a short period of time won't be noticeable most of the time. An i or p frame will come along soon and clean up the picture.

2) b frames can use motion vectors from both prior and future frames, not just prior frames (p frames can only refernce prior frames, i frames are encoded in their entirety, much like a JPG image). In theory this can reduce the bitrate even more

In my experience #1 is responsible for most of the bitrate savings. You can force the encoder to use the same quality for b frames as it does for p frames. If you do that you'll find only a tiny difference in the size of a CRF encode with most material.

I think he meant at the same CQ setting the file with the b-frames will be smaller....... at least that's how I took it.

[jagabo]

I encoded the scenes at 18 CQ, then 20 CQ, 22 CQ, and finally at 24 CQ, none of the encodes have any blockiness in the them.

Maybe smitbret's player is skipping the deblocking stage for some reason*? But even at CRF 18 with playback deblocking you get visible posterization artifacts in dark areas. The result is wiggly motions where there shouldn't be any.


*Maybe other settings he's using is stressing the player so it's skipping the deblocking stage in order to keep up with the frame rate. He mentioned using 4 b frames in another thread.

[poisondeathray]

You can force the encoder to use the same quality for b frames as it does for p frames (--pbratio 1.0 in x264).

note this will only work if mbtree is disabled; pbratio switch is disabled when mbtree is active (mbtree is enabled by default)

[jagabo]

You can force the encoder to use the same quality for b frames as it does for p frames (--pbratio 1.0 in x264).

note this will only work if mbtree is disabled; pbratio switch is disabled when mbtree is active (mbtree is enabled by default)

Thanks for the clarification.

By the way, if you look at the x264 wiki you'll see many tips regarding the limitations for Blu-ray encoding:

http://mewiki.project357.com/wiki/X264_Settings

Many players may be able to play video that exceeds those limits but the farther you go the more likely you are to have problems.

[poisondeathray]

By the way, if you look at the x264 wiki you'll see lots of limitations for Blu-ray encoding:
http://mewiki.project357.com/wiki/X264_Settings

Many players may be able to play video that exceeds those limitations but the farther you go the more likely you are to have problems.

Yes there are many limitations . But he mentioned PS3, which is one of the more capable players out there and can play out of spec streams

This 1st link is a useful resource, as the specs are copied from the actual blu-ray specs (spec book is $5000 for 1 year , like the DVD spec book)
http://forum.doom9.org/showthread.php?t=154533

http://sites.google.com/site/x264bluray/home

[deadrats]

You can force the encoder to use the same quality for b frames as it does for p frames (--pbratio 1.0 in x264). If you do that you'll find only a tiny difference in the size of a CRF encode with ibp frames compared to an encode with only ip frames, with most material.

this might be a silly question but why wouldn't an encoder use the same quality for b frames as it does for p frames by default? why would any developer of any encoder code the encoder so that it used different quality for different frame types? doesn't that seem counter to producing the best possible encodes?

[jagabo]

You can force the encoder to use the same quality for b frames as it does for p frames (--pbratio 1.0 in x264). If you do that you'll find only a tiny difference in the size of a CRF encode with ibp frames compared to an encode with only ip frames, with most material.

this might be a silly question but why wouldn't an encoder use the same quality for b frames as it does for p frames by default? why would any developer of any encoder code the encoder so that it used different quality for different frame types? doesn't that seem counter to producing the best possible encodes?

The idea is that you won't perceive the decrease in quality for the duration of a few frames. Ie, the lower quality frames flash by so quickly that you don't notice their lower quality. The higher quality p frames keep the overall quality from degrading during the GOP.

[filmboss80]

If you use the exact same bitrate on both encodes, the size of the video file with the b-frames will be smaller than the one without the b-frames.

This is the answer I was looking for.

Unfortunately, it's wrong. At the same bitrate both will be the same size. That's the whole point of bitrate based encoding. At the same CRF they file with b frames will be smaller.

B frames reduce the bitrate requirement in two ways:

1) The are encoded with a higher quantizer (lower quality). The idea being that having a few frames of lower quality for a short period of time won't be noticeable most of the time. An i or p frame will come along soon and clean up the picture.

2) b frames can use motion vectors from both prior and future frames, not just prior frames (p frames can only refernce prior frames, i frames are encoded in their entirety, much like a JPG image). In theory this can reduce the bitrate even more

In my experience #1 is responsible for most of the bitrate savings. You can force the encoder to use the same quality for b frames as it does for p frames. If you do that you'll find only a tiny difference in the size of a CRF encode with most material.

I think he meant at the same CQ setting the file with the b-frames will be smaller....... at least that's how I took it.

Yeah--oversimplified perhaps. Much too lazy to write a dissertation about allocation of bits to this frame or that. I'll just paste a couple of links here and leave it at that.

http://en.wikipedia.org/wiki/Inter_frame

http://forum.digital-digest.com/f20/i-p-b-frames-explained-9785.html