Too few b-frames with x264

[csd79]

Hi Everyone,

Some days ago I noticed that x264 produces only a few b-frames in my encodings. (Earlier I missed this info somehow...:stupid:) Here's an example command line for a small test video:

x264.exe --keyint 240 --min-keyint 24 --scenecut 40 --bframes 3 --b-pyramid --b-bias 100 --ref 5 --no-deblock --bitrate 1800 --ipratio 1.40 --pbratio 1.30 --chroma-qp-offset 0 --pass 1 --qcomp 0.60 --8x8dct --partitions all --direct temporal --direct-8x8 -1 --weightb --me "umh" --subme 7 --b-rdo --mixed-refs --bime --no-fast-pskip --fps 24 --progress --no-psnr --no-ssim --thread-input -o test.mkv test.avs 720x448

and the results:

x264 [info]: slice I:3
x264 [info]: slice P:79
x264 [info]: slice B:18

I was under the impression that there should be more B than P frames. Am I missing something?

BTW the same thing occurs on normal film encodings too. Originally I didn't use --b-bias, I just set it when I noticed this thing.

Anyone knows why this happening?

thx

[Trahald]

one day (to test some tweakings in my compile.) i tried to get a short segment to force in some b-frames... i wanted a ipbbpbbp pattern. the encoded mostly only would do single b's between p's if any b's at all. i tried b-bias 100 and some others that are supposed to help. tried high and low crf values. i was never able to do it (some of the settings caused less b-frames actually. ) I switch my trim section to a section of the film that had less motion and the result was 2 bframes as i wanted. so i was never able to force the issue, the encoder basically decided what was best and only gave me 2 b's when it wanted.

[Sharktooth]

--no-b-adapt ...

[Trahald]

one of the first things i tried... no impact. is there another setting that may be nullifying it?

[Sharktooth]

none that i can remember

[Trahald]

I found it. I used threads 2 in my command line. Cant find in the docs where it says that conflicts with --no-b-adapt.

[burfadel]

I would have said try more b-frames, 3 isn't that many! Setting the bias to 100 is counter-productive, although it seems that the bias is a little low at 0... I played around with it the other day with various clips, and using a crf of 25, and max of 16 b-frames, the smallest file size obtained was almost always around the 40 bias mark. The sources were various, most real life stuff but one animated clip. Around 40 always seemed the best (average) in terms of file size, and the output looked the same regardless of whether the bias was 0 or 40 :) Would someone else look in to this? (and remember to use 16 b-frames for this comparison) - the b-frame settings is use that number as a maximum, there probably are never the 16 used unless in still credits? but regardless, this is for a comparison!

[Dark Shikari]

I would have said try more b-frames, 3 isn't that many! Setting the bias to 100 is counter-productive, although it seems that the bias is a little low at 0... I played around with it the other day with various clips, and using a crf of 25, and max of 16 b-frames, the smallest file size obtained was almost always around the 40 bias mark. The sources were various, most real life stuff but one animated clip. Around 40 always seemed the best (average) in terms of file size, and the output looked the same regardless of whether the bias was 0 or 40 :) Would someone else look in to this? (and remember to use 16 b-frames for this comparison) - the b-frame settings is use that number as a maximum, there probably are never the 16 used unless in still credits? but regardless, this is for a comparison!
Compare the SSIM or PSNR between the --b-bias 0 and 40... higher --b-bias lowers the quality along with the bitrate, so the best quality per bitrate might not be at a high --b-bias.

[akupenguin]

@csd79
http://thread.gmane.org/gmane.comp.video.x264.devel/2918

@burfadel
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/28956/focus=29030

[Trahald]

@csd79
http://thread.gmane.org/gmane.comp.video.x264.devel/2918
adding -no-b-adapt alone is enough to increase b's over p's (unless its a really busy movie). If you want perfect adhearance to a particular b-frame param then thats where the thread comes in. but...

The thread linked sorta ends without a resolution. I can see what Wang means. The IBBPBBPPPP|I... choice over IBBPBBPBBP|I... or even IBBPBBP|IB|IB... makes sense on a bits/quality level, but not if you specifically chose no-b-adapt. generally with forced 2-b's out put of IBBPBBP|IP|IP.. with min keyint 2 or IBBPBBP|IBBP|... with min keyint4 if encountering motion/fading is expected. even though the encoder would want P's it should be forced to the 2b. having said that i dont know if there are muxing apps so nit-picky as some for mpeg2 were. although since its there would be cool if it went 100% b at any cost.

[fields_g]

I found it. I used threads 2 in my command line. Cant find in the docs where it says that conflicts with --no-b-adapt.

Beyond if x264 is producing the most efficient GOP sequence, I am curious about the above statement. IS there really a difference with the # of threads? If so, which way is correct?

[csd79]

Well, --no-b-adapt did the trick for me. But it didn't really do any magic to bitrate proportion. I think it's still better to leave adaptive b-frames on.

Thanks for the help!

[Trahald]

Well, --no-b-adapt did the trick for me. But it didn't really do any magic to bitrate proportion. I think it's still better to leave adaptive b-frames on.

Thanks for the help!
x264 is making the best decision bitrate/quality wise. The only reason to do no-b-adapt is if you MUST have the b's there.

Beyond if x264 is producing the most efficient GOP sequence, I am curious about the above statement. IS there really a difference with the # of threads? If so, which way is correct?Well.. the issue is having --threads X. It must impact x264's decision on frame type. understanding the cost of having to do a frame like a b over a p in a multithread environment, it makes sense.

Wangs patch takes care of both issues. makes no-b-adapt forced to your b-setting no matter the cost, even with threads on.

[SealTooGreat]

Is Wangs patch implemented in regular x264 distribution?

[Trahald]

not as of 667.

[Sharktooth]

pengvado will commit it when it will be ready

[Terranigma]

Compare the SSIM or PSNR between the --b-bias 0 and 40... higher --b-bias lowers the quality along with the bitrate, so the best quality per bitrate might not be at a high --b-bias.

I just did a ssim/psnr test with 16 b-frames with a bias of 40, and 16 b-frames with a bias of 0 because I too been using a bias of 40 way before burfadel ever mentioning it. I've done tons of test as well with 5 different sources using the CRF method with all possible bias settings from 0-100 (So that's 500 tests :p), and found most of the time, a bias of 40 gave me a smaller size at the specified CRF than all other possible settings.
(deadzone settings are at 21,11 for all 3 tests)


16 b-frames (Bias-40)
SSIM Mean Y:0.9666312
PSNR Mean Y:40.536 U:43.311 V:44.045 AVG:41.255 Global 39.858
(encode speed: 3.49fps)
(final ratefactor: 22.94)

16 b-frames (Bias-0)
SSIM Mean Y:0.9666153
PSNR Mean Y:40.530 U:43.313 V:44.048 AVG:41.251 Global:39.857
(encode speed: 3.33fps)
(final ratefactor: 23.03)

So it looks like the higher bias setting won, but only by a small margin. :D

---
Forgot to mention that for both tests, I used the exact same bitrate of 1500 on a 704X480 source up to 3000 frames.


---
To add some irrelevance to the mix, I did'nt use trellis at all, but I did do a trellis-1 test as well using 16 b-frames and a bias of 40. Here's the result.

16 b-frames (Bias-40 & Trellis-1)
SSIM Mean Y:0.9668233
PSNR Mean Y:40.631U:43.290 V:44.029 AVG:41.351 Global 40.002
(encode speed: 3.44fps)
(final ratefactor: 22.90)

[CruNcher]

So it looks like the higher bias setting won, but only by a small margin.


But it costs something even if you don't see it compare power consumption @ decoding of both then you see what i mean is this worth it (Visual Diference) ? i doub't it ;)
if it would really use 16 B-frame it would be very decoding complex you can say that every additional b-frame costs you -3 fps and alone useing 1 b-frame = -10 fps
so imho you should chose your encoding settings wisely and not just add as much as you can sure it's the most easy thing to get a quality boost but also to make the end bitstream very complex without any gain in visible Visual Quality :P (but go on if you prefer faster encoding and slower decoding (most wavelet codecs style).

[Terranigma]

if it would really use 16 B-frame it would be very decoding complex you can say that every additional b-frame costs you -3 fps and alone useing 1 b-frame = -10 fps
(but go on if you prefer faster encoding and slower decoding (most wavelet codecs style).
-3 fps? Yea that's intense. I'll use just 3 bframes then, but you can rest assure i'll be using a higher biased setting to guarantee I get 3 b-frames, because 2-bframes and below can cause asynchronous issues with an interleaved audio stream. =P

[foxyshadis]

But it costs something even if you don't see it compare power consumption @ decoding of both then you see what i mean is this worth it (Visual Diference) ? i doub't it ;)
if it would really use 16 B-frame it would be very decoding complex you can say that every additional b-frame costs you -3 fps and alone useing 1 b-frame = -10 fps

That's only with hierarchical b-pyramid, isn't it? Changing 1% of the p-frames to b-frames, if that, because you went from 3 to 16 (adaptive) isn't going to seriously affect decoding speed.

[Terranigma]

Now i'm a bit confused. So it's ok to use 16 b-frames now or?
I use Adaptive b-frames like foxyshadis mentioned, but in the end, I do care about the cpu usage. :p

[Terranigma]

Well, I guess i'm on my own. I'll do quite a few tests with different settings other than just b-frames, then play them back on the modded xbox to see if there's a difference between the number of frame drops, if any. I'll update this post with the result.

[Sagekilla]

Now i'm a bit confused. So it's ok to use 16 b-frames now or?
I use Adaptive b-frames like foxyshadis mentioned, but in the end, I do care about the cpu usage. :p

You're perfectly fine using 16 B-Frames. Like someone told me in the past, (Don't remember who, sorry!) "Setting B-Frames to 16 basically means you're telling x264 to choose what it thinks is best." If a scene, such as a low motion one, demands numerous B-frames, x264 will use them and your encoding will benefit. Otherwise, it'll probably not use all 16 B-Frames, and maybe only 3 most of the time. From what I've seen, setting it to 16 just gives you the leverage for those "In case a scene with low motion occurs.. I get a drop in bit rate with no quality loss!"

And you should see no appreciable loss in encoding time by setting B-frames to 16, only in decoding time if the encoder decides to go crazy and use them frequently. Akupenguin said so himself, B-frames encode faster then P-Frames but they decode slower then P-Frames.

Hope that helped :)


Edit: Oh and if you wanna see, I may still have a few of the original .264 outputs from testing between B-Frames 4 and B-Frames 16 as well as the little chart I made. It pretty much proves what I just said in that there really is no appreciable loss or gain unless there's a really slow (or no) motion scene.

[Terranigma]

Ok, Time to chime in the results.
Tests were made using x264 rev. 669 from x264.nl (so no AQ) up to 2000 frames.

My commandline's for each test is as follows.
--bitrate 1425 --keyint 120 --min-keyint 12 --ref 5 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 16 --qpstep 3 --b-bias 40 --me umh --threads auto --thread-input --cqmfile "Prestige CQM.cfg" --progress --no-dct-decimate --output "C:\Testfile.mkv"

What's highlighted in blue are the settings I altered for each test (if not all, just some of the highlighted options).

Test 1:
--trellis 1 --bframes 3 --partitions p8x8,b8x8,i4x4,i8x8
SSIM Mean Y:09578213
PSNR Mean Y:38.914 U:41.756 V:42.602 AVG:39.733 Global 38.501 kb/s
(Final ratefactor: 24.07)
(Encode Speed: 3.44 fps)

Test 2:
--trellis 1 --bframes 16 --partitions p8x8,b8x8,i4x4,i8x8
SSIM Mean Y:09578236
PSNR Mean Y:38.914 U:41.756 V:42.604 AVG:39.734 Global 38.501 kb/s
(Final ratefactor: 24.07)
(Encode Speed: 3.51 fps)

Test 3:
--trellis 1 --bframes 16 --partitions all
SSIM Mean Y:09578077
PSNR Mean Y:38.906 U:41.752 V:42.602 AVG:39.727 Global 38.494 kb/s
(Final ratefactor: 24.07)
(Encode Speed: 3.52 fps)

Test 4:
--trellis 2 --bframes 16 --partitions p8x8,b8x8,i4x4,i8x8
SSIM Mean Y:09587019
PSNR Mean Y:39.026 U:41.885 V:42.745 AVG:39.850 Global 38.618 kb/s
(Final ratefactor: 23.87)
(Encode Speed: 2.65 fps)

Test 5:
--trellis 0 --bframes 16 --partitions p8x8,b8x8,i4x4,i8x8
SSIM Mean Y:09575796
PSNR Mean Y:38.773 U:41.746 V:42.598 AVG:39.616 Global 38.365 kb/s
(Final ratefactor: 24.13)
(Encode Speed: 3.65 fps)

What I found most interesting, was the results I got between the 2nd and 3rd encode. The 2nd encode had higher averages for all psnr values, and an overall ssim value. This is not using p4x4, so akupenguin's right, p4x4 is useless, and in the end, can hurt quality instead of helping :p

My main goal of doing my tests wasn't about trying to figure out what'd give me higher averages, it was about testing to see who was right between foxyshadis and CruNcher about the cpu usage, so I took these five samples using elupus's latest mplayer compile and put them on my modded xbox. There was not a bit of difference between the cpu usage of using 3 or 16 b-frames, so foxyshadis's correct, sorry CruNcher. :p

[CruNcher]

ehhh you didn't understood me correctly :P
sure you see no hit as the encoder doesn't use 16 b-frames but if it would you would see this cpu hit @ decoding add --no-badapt --b-bias 50 :)

[foxyshadis]

That's not a practical consideration though. From everything I've tested, in general the encoder will use more b-frames, and b-blocks within those frames, in the lower complexity areas, especially since the quantizer is a bit higher than a p-frame's would be. So the speed you lose, you make up for with the lower CABAC overhead. (In general. Strange things can always happen!)

On my tests of movie footage I couldn't even make it use more than 4 b-frames in a row without raising the bias.

[cestfait]

So how about with animated footage? In relatively static scenes, will a higher b-frame setting help?

[Adub]

If by animated you mean anime, then yes a higher bframe setting will help. Take a look at sharktooth's anime profiles.

I am not sure about Animated footage. Are you thinking Shrek animated or something else?

[cestfait]

Yep, I was thinking animé. :thanks:

[Adub]

No problem, glad to be of help.