how many b-frames is "optimal" for h264 encoding?

[deadrats]

just want to hear some opinions as to how many b frames and how many reference frames you guys think should be used before quality is degraded.

the sources are all vc-1 (in a wmv container), 720p, 4mb/s with wma audio and i'm converting them to h264 4mb/s with aac audio in an mp4 container. the reason i'm converting them is because the original wmv's have weird playback issues, i.e. when you try and seek you get corrupted images.

i usually use intel quick sync from within tmpg vmw5, primarily because it's about 3 times faster than x264 with the ultra fast preset on my i3 2100 (even if i use media coder, which in my experience uses the fastest encoder and decoder builds).

tmpg allows me to set the max b frames to 16 and the max reference frames to 9 when using QS and the same for x264 (incidentally, you can set up to 15 reference frames for certain resolutions).

so, what do you guys think, is it advantageous to use more b frames or is there a point where you see the law of diminishing returns kick in and actually start to hurt final quality?

[jagabo]

Two or three.

[deadrats]

what happens after 2 or 3 b frames? does the quality start to suffer? how about with regards to reference frames? my gut instinct tells me that the more reference frames the higher the quality, am i right?

[jagabo]

I-frames are encoded with a lower quantizer. You get more quality strobing if you have frequent i-frames. Ie, you get a nice clean i-frame, quality slowly degrades with P and B frames, then suddenly you get a higher quality i-frame again.

B-frames are encoded with higher quantizers. You get similar (short term) quality strobing if you have too many in a row.

[somespirit]

Max. Ref. frames: In contrast to MPEG-4 ASP, H.264 allows multiple reference frames. This setting controls how many frames can be referenced by P- and B-Frames. Higher values will usually result in a more efficient compression, which means better visual quality at same file size. Unfortunately more reference frames will require more time for encoding (and also a tiny bit more CPU power for playback). By default the number of reference frames is limited to 1. It's highly recommended to raise the number of references to at least 3. Nevertheless using more than 4 or 5 reference frames for “real life” footage should be avoided, as it won't improve the results any further! At the same time Anime and cartoons benefit a lot from additional reference frames. Sometimes even the maximum of 16 reference frames can be helpful for such material.

4 or 5 is fine

• Max Consecutive: This setting controls the maximum number of consecutive B-Frames. B-Frames refer to both, the previous and the following I-Frame (or P-Frame). This way B-Frames can compress even more efficient than P-Frames. B-Frames can significantly improve the visual quality of the video at the same file size. Therefore using B-Frames is highly recommended. Also note that allowing more B-Frames will never hurt the quality: You can even safely choose the maximum of 16 consecutive B-Frames. That's because you only specify the upper bound for the number of consecutive B-Frames. x264 will still decide how many consecutive B-Frames are actually used. So even if you allow up to 16 consecutive B-Frames, the encoder will rarely go that high. Nevertheless limiting the maximum number of B-Frames to less than 16 is reasonable, because most videos won't benefit from using more than ~4 consecutive B-Frames anyway! Raising the B-Frame limit higher than that would only slowdown the encoding process for no real benefit! If you set the B-Frame limit to 0 (the default), B-Frames will be disabled. Of course disabling B-Frames is not recommended!

here depends how fast is your system ...........more is better (again 4 or 5 is good)

[jagabo]

I use 3 or 4 re-frames. If you look at the report generated at the end of an x264 encoding you'll see that the encoder rarely uses more than 4 reference frames (anime is a bit of an exception) when you specify more than 4. So don't waste time looking for more. And more re-frames requires more memory on the part of the decoder (all the reference frames have to be decoded in memory). That's why many devices are limited in re-frames.

In theory b-frames result in more compression because they allow for bidirectional encoding. In reality, most of their compression comes from the higher quantizer.

[poisondeathray]

There is no straight simple answer. There are too many variables involved, including specific type of content, level of compression , speed tradeoffs you're willing to make.

If you're more inclined for fast settings, you're probably not using --b-adapt 2 (not very well multithreaded, exponentially slower with increasing max b-frames), but it's required to get the "optimal" b-frame placement.

At lower parts of the compression curve, more b-frames are almost mandatory for maximum compression. Also you'll notice worse quality "faster" settings reflected more in b-frames because of the higher quantizer when you are in this bitrate range. "Faster" settings will propogate lower quality frames through the p-frames , b-frames, and non IDR i-frames

On higher parts of the compression curve, if you give adequate bitrate for that type of content, differences quickly become negligible

On your encode logs, you can check the # of ref and b-frames actually used. This way you can get a feel for dialing in better settings next time on related typical content

[jagabo]

By the way, I (and I think the others here) have been talking specifically about x264. Other h.264 encoders may vary a bit.

[deadrats]

By the way, I (and I think the others here) have been talking specifically about x264. Other h.264 encoders may vary a bit.

yeah, i realized that, as i said i use the intel hardware accelerated h264 encoder from within the latest tmpg; x264 at the fastest settings gives crappy quality in my opinion and it's still 3 times slower than QS on my system.

btw, has anyone else come to the conclusion that x264 seems to have regressed quality wise with the "ultra fast" preset? there was a time i thought that "ultra fast" was just fine for most users but lately it seems to me that with the newer builds the quality at similar bit rates has taken a step or two backwards.

maybe it's that my previous conclusions were based on tests with SD content but now that i work almost exclusively with HD content i'm noticing the shortcomings more and more.