x264 : number of B frames and ref

[sirt]

Hello,

There is something that is still unclear to me. After reading various articles and advises, adjusting the number of B Frames (and ref) is still unclear to me. In fact I understand what will happen in theory if I set --bframes 3 and --ref 5 for example (in term of GOP structure) but, in practice, I don't know how to choose them.

From what I've read, I should never exceed 6 or 7 ref with SD content and 4 with HD. With SD, I have not a precise idea of how many ref I should use, 5,6 or even 7 or less ? Accordingly, should I use an hypothetical number of B Frames ? I read on the related Wiki AVIdemux page that I could set 16 B Frames without worrying about it in so far as the encoder would choose itself the suitable number to use.

I think some people will blame me for asking this : is there some method or maths to do that could indicate me which relevant number of ref and B Frames I should be prone to use ? I was thinking the length, the framerate and maybe another factors could help me refine my choices.

[Groucho2004]

I got 22,700 hits (http://www.google.co.uk/search?hl=en&as_q=x264+B-frames+ref&as_epq=&as_oq=&as_eq=&as_nlo=&as_nhi=&lr=&cr=&as_qdr=all&as_sitesearch=http%3A%2F%2Fforum.doom9.org&as_occt=any&safe=off&tbs=&as_filetype=&as_rights=) on Doom9 alone searching for "x264" + "B-frames" + "ref".

Not all are relevant but I know that this has been discussed here hundreds of times. Does Google not work where you live?

Edit:
From what I've read, I should never exceed 6 or 7 ref with SD content and 4 with HD.
I don't know what you read but this is not correct for the most part. Have a look at the info about levels (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels).

[sirt]

Of course it was discussed but it should not deter me from having my own thread. Then, if you don't plan to answer or at least redirect me to a suitable page likely to help me, it doesn't worth replying.

[Groucho2004]

Of course it was discussed but it should not deter me from having my own thread. Then, if you don't plan to answer or at least redirect me to a suitable page likely to help me, it doesn't worth replying.

Your own thread? What the hell is that supposed to mean? The information you seek already exists, you're just too lazy to look for it.

[sirt]

If it exists, then just redirect me to the related pages that precisely answer my questions. As you pointed out there are thousands of pages like this.

Else, please answer yourself if you know the answers.

[Groucho2004]

If it exists, then just redirect me to the related pages that precisely answer my questions.
Yes, that would be convenient.

[sirt]

It would be, but it would rather be convenient if you or someone else just answered !

[sneaker_ger]

Roughly:
More refs: better compression, lower speed, lower compatibility (see H.264 levels)
More b-frames: better compression, lower speed (mainly for --b-adapt 2), lower compatibility (mainly Blu-Ray spec, not "real" decoder limitation)

There is no formula, except the usual "use --preset x and --level y".

[SassBot]

is there some method or maths to do that could indicate me which relevant number of ref and B Frames I should be prone to use ? I was thinking the length, the framerate and maybe another factors could help me refine my choices.

No, there isn't. The only real factors limiting your choice is levels/hardware compatibility and encoding speed as bumping up b-frames and reference frames can increase encoding time. You're better off just using whatever your chosen preset and tune sets unless you have specific needs such as DXVA or Blu-Ray spec compatibility.

[poisondeathray]

If you have a device restriction, then use that .

Otherwise it's source dependent. There is no way in advance to know exactly what that source will use

Have a look at your log file to see if they are actually used for that particular source, for those particular settings (eg. if you enter 16 b-frames, it might be using only 3 consec. then it's a complete waste of time) . e.g Highly compressible content like simple animation with repeat frames will typically make more use of higher numbers of b-frames than live action content

The tradeoff is much longer encoding times (especially if you use --b-adapt 2) vs. better compression

But quality depends on the quantizer relative to content complexity (.e.g b-frames have lower quality, but if you are using high bitrates compared to complexity, then the quality might actually be lower than if you had used fewer or no b-frames , but if you are in the low bitrate range, higher compression usually results in "better visual quality")

[sirt]

Thanks for those detailed answers. I have no particular restriction.

poisondeathray you raised an interesting question : what do you mean by "high bitrates" ? Let's say I will encode a video at 2500 kbits/s in 2 pass (5000 frames for example). Somebody told me in the past I should never use more than 3 B Frames with such content and someting like 5 or 6 ref but I don't know if that is trustable either if setting 16 B Frames could (theorically) ruin the video. In fact, it is in contradiction with what I read on AVIdemux Wiki page regarding the choice of 16 B Frames. But it looks like according to you, even though I set 16 B and the encoder only use 3, it may be a waste but also affect the quality. Or am I wrong ?

[SassBot]

Thanks for those detailed answers. I have no particular restriction.

Then either keep them at what the preset/tune sets or set them to the max you are willing to do based on encoding time.

poisondeathray you raised an interesting question : what do you mean by "high bitrates" ? Let's say I will encode a video at 2500 kbits/s in 2 pass (5000 frames for example). Somebody told me in the past I should never use more than 3 B Frames with such content and someting like 5 or 6 ref but I don't know if that is trustable either if setting 16 B Frames could (theorically) ruin the video. In fact, it is in contradiction with what I read on AVIdemux Wiki page regarding the choice of 16 B Frames. But it looks like according to you, even though I set 16 B and the encoder only use 3, it may be a waste but also affect the quality. Or am I wrong ?

Setting 16 b-frames will not ruin the video and I'm sure what he refers to as 'high bitrate' is well more than 2.5 mbit/sec.

[poisondeathray]

poisondeathray you raised an interesting question : what do you mean by "high bitrates" ? Let's say I will encode a video at 2500 kbits/s in 2 pass (5000 frames for example). Somebody told me in the past I should never use more than 3 B Frames with such content and someting like 5 or 6 ref but I don't know if that is trustable either if setting 16 B Frames could (theorically) ruin the video. In fact, it is in contradiction with what I read on AVIdemux Wiki page regarding the choice of 16 B Frames. But it looks like according to you, even though I set 16 B and the encoder only use 3, it may be a waste but also affect the quality. Or am I wrong ?



high bitrates relative to content complexity

eg. 2500kbps will probably be too much for a 16x16 video of a black screen. It will probably be low for a 4k action movie.

I wouldn't say "never". Look at the log file for the answer on that particular source, with those particular settings. If you enter 16 but it only uses 4 , then it's a huge waste. It will probably take several times longer to encode with no difference in quality.

Sassbot already answered: quality not affected, just much longer encoding times for the same quality

[sirt]

Well but I can't do whatsoever : what if I set 1 ref and 16 B ? 16 ref 0 B ? or anything irrelevant like this.

I was looking at this : http://dev.gentoo.org/~beandog/x264_preset_reference.html and I don't find any real correlation between ref and B frames : with Placebo you have both 16 ref and B which, regarding our discussion is likely to considerably slow down the encoding process for nothing then both decrease and Ultrafast allows 1 ref and 0 B. As a matter of fact, I don't know if that is relevant to ask this but let's try my luck : how were the settings regarding ref and B frames chosen when establishing the presets ? Is there a good reason to have set such values ?

[SassBot]

Well but I can't do whatsoever : what if I set 1 ref and 16 B ? 16 ref 0 B ? or anything irrelevant like this.

You'll likely get subpar compression versus something more sane.

I was looking at this : http://dev.gentoo.org/~beandog/x264_preset_reference.html and I don't find any real correlation between ref and B frames : with Placebo you have both 16 ref and B which, regarding our discussion is likely to considerably slow down the encoding process for nothing then both decrease and Ultrafast allows 1 ref and 0 B. As a matter of fact, I don't know if that is relevant to ask this but let's try my luck : how were the settings regarding ref and B frames chosen when establishing the presets ? Is there a good reason to have set such values ?

Whoever said there was a correlation between b-frames and reference frames? They are not interrelated features. (http://doom10.org/index.php?PHPSESSID=82u5rkl8afvapa0tfug8deig73&topic=145.msg1035#msg1035) To your second question, those settings were chosen as what Dark Shikari thought was a good tradeoff between compression efficiency/quality and speed. He can obviously give you more insight.

[sirt]

Thanks SassBoot.

Dark Shikari you are needed then :D

[Dark Shikari]

You shouldn't generally be touching either of these settings. If you're worried about speed/compression tradeoff, use the presets. Otherwise, the only reason to mess with --ref is for level restrictions, which --level should do automatically.

There is no relationship between "SD and HD content" and the number of useful reference frames. You'll be better off not basing your encoding settings on weird urban legends.

[sirt]

Dark Shikari, thanks for your answer. But you didn't explain why you choosed such and such ref and B frames for such and such preset. Let's admit it is for obscure speed/compression tradeoff, but isn't there a brief explanation ? For example when you switch from veryslow to slower, ref is divided by two (8 instead of 16) but not B Frames (3 instead of 8) and I would like to understand why, if it is of course understandable.

[pandy]

Dark Shikari, thanks for your answer. But you didn't explain why you choosed such and such ref and B frames for such and such preset.

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Decoded_picture_buffering

[sirt]

Well thanks but as pointed out above, Groucho2004 already redirected me to this page. It is just spinning my wheels because it urges me to ask : how those levels were decided in that case ? I think asking this just accrues to more questions but...

[Atak_Snajpera]

Dark Shikari, thanks for your answer. But you didn't explain why you choosed such and such ref and B frames for such and such preset. Let's admit it is for obscure speed/compression tradeoff, but isn't there a brief explanation ? For example when you switch from veryslow to slower, ref is divided by two (8 instead of 16) but not B Frames (3 instead of 8) and I would like to understand why, if it is of course understandable.
Based on many many many real tests ?

[SassBot]

Well thanks but as pointed out above, Groucho2004 already redirected me to this page. It is just spinning my wheels because it urges me to ask : how those levels were decided in that case ? I think asking this just accrues to more questions but...

Levels were decided based on reasonable minimum hardware requirements needed for decoding.

[Dark Shikari]

The settings in presets were picked to be roughly optimal positions on the speed-compession curve based on testing.

[SassBot]

True, but I believe sirt made that comment about the wikipedia link about H.264 DPB which had a chart of levels and the MaxDPBMbs.

[pandy]

True, but I believe sirt made that comment about the wikipedia link about H.264 DPB which had a chart of levels and the MaxDPBMbs.

And this one is not clear - i think that He mixing levels, DPB, B frames and number of ref frames.

So only one think is arguable - number of B frames (max REF is 16 as specified by standard).

Or perhaps my English is poorer than i thought. :cool:

[sirt]

pandy, I don't understand what you are pointing out. What do you want to say ?

As SassBot said, I don't understand how H264 DPB has been conceived and also why there are so many profiles and levels.

[Groucho2004]

I don't understand how H264 DPB has been conceived and why there are so many profiles and levels.
It's part of the standard.

There is plenty of information about ISO/IEC 14496-10 on that Wikipedia page.

[SassBot]

As SassBot said, I don't understand how H264 DPB has been conceived and also why there are so many profiles and levels.

There are so many profiles and levels so to support that H.264 can run reasonably on a wide range of devices.

[pandy]

pandy, I don't understand what you are pointing out. What do you want to say ?


I'm simply not sure how to understand Your questions.
Some things are STANDARD same as traffic lights colors or wheels diameter - they are simply designed in that way.
Why so many? - as mentioned many times - to cover various situations.

[sirt]

It's part of the standard.

There is plenty of information about ISO/IEC 14496-10 on that Wikipedia page.

Then who has decided the standard and why ?

[SassBot]

Then who has decided the standard

The ISO and MPEG working groups.

and why ?

Read the standard and you might find out.

[sirt]

Okay, where can I find official h264 (and also HEVC) standards ? I just have a look on the Internet and it looks like it is not free.

[Dark Shikari]

It's free. (http://www.itu.int/rec/T-REC-H.264-201106-S)

[SassBot]

neuron2 has a link on his site to a library full of standards documents but it seems it needs a username/password to access now. :(

[sirt]

Thanks for your answer, then I will see if I am capable of understanding something but I guess not.

[john_z]

Roughly:
More refs: better compression, lower speed, lower compatibility (see H.264 levels)
More b-frames: better compression, lower speed (mainly for --b-adapt 2), lower compatibility (mainly Blu-Ray spec, not "real" decoder limitation)

There is no formula, except the usual "use --preset x and --level y".

I think this answer would be more understandable.

As what I know I frame has better quality than B frame. So my aim is to encode high quality 720P at bitrate 2500kpbs, I prefer to use high profile + level 4.1 + Placebo + --bframes 3 --ref 5, sometime will adjust --scenecut 60, others remain default,

Please some masters tell me if I was wrong.

[sirt]

john_z, why not using only I frames in this case even if the size will be huge ? Why do you adjust scenecut and how do you know it should be 60 sometimes ?

[nm]

I think this answer would be more understandable.

As what I know I frame has better quality than B frame. So my aim is to encode high quality 720P at bitrate 2500kpbs, I prefer to use high profile + level 4.1 + Placebo + --bframes 3 --ref 5, sometime will adjust --scenecut 60, others remain default,

"Better compression" means better quality at the same bitrate. You'd gain quality by letting x264 use more B-frames and refs. Leave scenecut at the default setting.

[Blue_MiSfit]

As what I know I frame has better quality than B frame


Nope. Not at equivalent frame sizes. In fact, it's quite the opposite. I-frames are much less compressible than B-frames, which translates to saying "I-frames are much lower quality than B-frames at a given size".

If you want good quality 720p video at 2.5 Mbps, you should just use 2 pass VBR, and the slowest preset you can stand (except Placebo, which is just plain silly). You're over complicating things.

In fact, this advice is basically true for anything. Don't manually set b-frames, scenecut, references, or any other setting you happen to think will improve quality. The presets are made by the developers, who understand the encoder and the H.264 standard better than you ever will.

The only extra settings you should use are those necessary for compliance with a particular hardware decoder. In other words, things like VBV, or maybe occasionally some picky things like limiting the number of references for non-compliant hardware. Seriously don't over-complicate things. Very clever people have tried to make this as easy as possible for us mere mortals :)

[sirt]

Nope. Not at equivalent frame sizes. In fact, it's quite the opposite. I-frames are much less compressible than B-frames, which translates to saying "I-frames are much lower quality than B-frames at a given size".

If you want good quality 720p video at 2.5 Mbps, you should just use 2 pass VBR, and the slowest preset you can stand (except Placebo, which is just plain silly). You're over complicating things.

In fact, this advice is basically true for anything. Don't manually set b-frames, scenecut, references, or any other setting you happen to think will improve quality. The presets are made by the developers, who understand the encoder and the H.264 standard better than you ever will.

The only extra settings you should use are those necessary for compliance with a particular hardware decoder. In other words, things like VBV, or maybe occasionally some picky things like limiting the number of references for non-compliant hardware. Seriously don't over-complicate things. Very clever people have tried to make this as easy as possible for us mere mortals :)

Well, Blue_MiSfit,all this is not about over-complicating things. It's about average people, like me, who want to understand and give a try to many settings. Personally, I am aware I should use one preset and not muck with any "forbidden" parameter ! Notwithstanding, I try unusual things to see what occurs. Dealing with B-frame and I-frames, I think I have understood that setting 16 B frame will never be bad in so far as the encoder will pick up the correct number to use according to such and such settings, but I don't think it is the same with I-frames : using 16 is perhaps "too much" as much as it will make the video hard to play and also slow down encoding for absolutely nothing, won't it ? And about your latest statement, why is nobody using --ref 1 --bframes 16 if B frames are of better quality than I frames ?

[bxyhxyh]

I think some posts of this thread can help. Especially LoRd_MuldeR's posts
http://forum.doom9.org/showthread.php?t=164919

[detmek]

I think this answer would be more understandable.

As what I know I frame has better quality than B frame. So my aim is to encode high quality 720P at bitrate 2500kpbs, I prefer to use high profile + level 4.1 + Placebo + --bframes 3 --ref 5, sometime will adjust --scenecut 60, others remain default,

Please some masters tell me if I was wrong.

I just did quick 2-pass test to compare --preset veryslow vs --preset placebo --bframes 3 --ref 5. I got 6,7% better quality (SSIM) with --preset veryslow which was also 8x faster on pass 1 and 2x faster on pass 2.

[detmek]

Well, Blue_MiSfit,all this is not about over-complicating things. It's about average people, like me, who want to understand and give a try to many settings. Personally, I am aware I should use one preset and not muck with any "forbidden" parameter ! Notwithstanding, I try unusual things to see what occurs. Dealing with B-frame and I-frames, I think I have understood that setting 16 B frame will never be bad in so far as the encoder will pick up the correct number to use according to such and such settings, but I don't think it is the same with I-frames : using 16 is perhaps "too much" as much as it will make the video hard to play and also slow down encoding for absolutely nothing, won't it ? And about your latest statement, why is nobody using --ref 1 --bframes 16 if B frames are of better quality than I frames ?
--ref 1 is not corelated with I frames so why would one use --ref 1 if one wants more I frames. If you want more I frames, change --keyint or --scenecut. But, that is not good idea if you use fixed bitrate as video will come out much worse with too much I frames.

[sirt]

I got 6,7% better quality (SSIM) with --preset veryslow which was also 8x faster on pass 1 and 2x faster on pass 2.

But does that mean anything subjectively ? I mean, a higher SSIM on a specifical encode won't systematicaly be synonym of a higher visual quality, won't it ? Moreover, how is that possible to have an higher SSIM with veryslow whereas, as from I know, placebo is said to have slower and "better" settings ? To sum up which one is better in term of quality ?

Then, about I frames, it seems I have still missed something : what the difference between --ref and I frames ? So, come back to my question : do you think it will be worse if I set --keyint 1 --bframes 16 in this case ? I can't understand why it would be if B-frames are said to be of better quality than I frames.

[detmek]

SSIM is not perfect metric but usually means that if SSIM is higher then visual quality is better, too.
Also, slower doesn't allways mean better. I changed placebo settings by lowering B-frames and Reference frames which are very efficient options. Placebo option --me tesa is extremly slow compared to --me umh in veryslow but in can not compensate for 5 B-frames and 11 Reference frames less in my command line.
Quality difference between slower presets is very small, a few % usually. When it comes placebo vs veryslow, usually there isn't any difference in quality. And who said thad placemo have slower and better settings? You need to learn how to test those teories for yourself.
If you set --keyint 1 --bframes 16 you won't have any B frames, or P frames. --keyint 1 will force encoder to use only I frames. As Blue_MiSfit said, at same frame size B-frame has far more quality then I frame or, vice versa, B frame will achive same quality as I frame with much smaller frame size. If you are limited by bitrate using a lot of I frames is bad idea. If you are not limited with bitrate/filesize using all I frames will improve quality but encoded video will likely be larger then original (unless original is lossless).

P.S. You might want to read at least first 6 pages of this article: H.264 encoding - CPU vs GPU: Nvidia CUDA, AMD Stream, Intel MediaSDK and x264 (http://www.behardware.com/articles/828-1/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html)