Is it time to stop using B frames?

[sophisticles]

Happy Memorial Day folks, remember to make sure not to burn your burgers on the grill as you read this post.

The CRF vs CQP thread got me thinking about somethings and I started doing a bunch of test encodes.

One of the things I wanted to see was if we were at the point with x264 to do away with B frames altogether. The reason is that eliminating B frames from the equation will make both decoding and encoding faster, and in theory any quality lose from not using B frames could be offset by using more aggressive settings.

I decided to test where we stand by encoding the same source i used in the CRF vs CQP thread, with 2 CRF 30 encodes, both with the fast preset, no tune and one with the default B frame configuration and one with B frames set to 0, otherwise there is no difference in the settings.

Here's the thing, the claims about CRF are that they represent "quality" (which is nonsense) and in theory, CRF 30 ultrafast should have the same perceptual quality as CRF 30 placebo and the only difference should be file size.

Let's assume for a second this is true, then the two encodes i did should have the same visual quality.

If this is true, then there is no longer any reason to use B frames because the encode without B frames is smaller and was encoded in less time, by 3 minutes.

After I finish grilling, stuffing my face and drinking some Bud Light, I will repeat this experiment with x265 and svt-av1 to see what happens.

[poisondeathray]

One of the things I wanted to see was if we were at the point with x264 to do away with B frames altogether. The reason is that eliminating B frames from the equation will make both decoding and encoding faster, and in theory any quality lose from not using B frames could be offset by using more aggressive settings.

If you're using lower bitrate ranges for encoding, you *NEED* b-frames. This is true for any encoder, not just AVC either

If you have high bitrates, you can do without b-frames. Very high bitrates, you can do without b or p-frames

Another way to effect change over frametype quality is to adjust the ib / pb ratios . For example if b-frame quality was noticably poorer, you can lower the ratios


For that test, the "normal" encode has about 5% more bitrate . I would try to adjust one or both (decimal CRF values) to make it a valid comparison

Here's the thing, the claims about CRF are that they represent "quality" (which is nonsense) and in theory, CRF 30 ultrafast should have the same perceptual quality as CRF 30 placebo and the only difference should be file size.

It's nonsense. CRF is just a rate control method. That's it.

Once you change any other encode settings, you can no longer compare between CRF values. It's no longer a valid comparison. This is a well established fact.

The only thing you can say is lower CRF values at a given setting produce higher quality/less loss than higher CRF values using the same settings , provided you're using a x264 build from the same core version (CRF has been rebalanced several times in the past)

[Sharc]

Wondering why NVIDIA have been striving long and hard to support B-frames for their GPUs?
I mean if B-frames are obsolete or useless why would they have spent money to support B-frames....?

[pandy]

My 2 cents:

I frame - approx 100KB
P frame approx 10KB
B frame approx 1KB

It is up to you to mix and use it - depends on encoding complexity (i.e. ultrafast vs placebo and all between), source entropy and of course target quality vs bitrate.

Ideal encoder will do proper frame types selection - but there no such thing like ideal encoder...

[JN-]

May be of interest, average GOP varies between 2 files ...


[Attachment 71347 - Click to enlarge]



[Attachment 71346 - Click to enlarge]

How does one give/create a link to a file in a post as sophisticles has done in his #1 post ?

[pandy]

CQP will not change dynamically GOP length or frame type - good encoder in CRF mode should dynamically adapt to video optimal (within particular constrains) GOP length and frame types.