Profile levels, maximum bitrate and crf

[akupenguin]

Is it necessary to specify --nal-hrd to comply with the VBV constraints specified by the H.264 standard for each Profile @ Level?

No.

--nal-hrd vbr just adds the aforementioned buffer fullness data, which is optional according to the H.264 standard but may be required by some other standards such as Blu-ray.

And --nal-hrd cbr is only for perverse applications where using less than the maximum allowed bitrate is a fatal error. Definitely not all of the things that you would normally call CBR. The only such case I can think of is if you're sending the stream directly over a wire; not a packet switched network, not a filesystem, not muxed into a container, just video bits directly over the fixed-speed physical layer.

When does the "cpbBrNalFactor" apply?

If you enable vbv, then x264 enforces both the Vcl and Nal parts of it, but for simplicity we take both sets of numbers from the same vbv-maxrate/vbv-bufsize options. And since we use the same values for both, those values are limited by the smaller of the level limits, i.e. cpbBrVclFactor.
cpbBrVclFactor applies to data before NAL encapsulation, cpbBrNalFactor applies after. But NAL encapsulation usually adds only a tiny amount of data, far less than the factor of 1.2 allowed by the higher value of cpbBrNalFactor.
If you have some perverse stream such that NAL encapsulation adds a significant amount of data, and your use-case is limited only by levels compliance and not by actual bandwidth, then you could sqeeze somewhat more bitrate into the same level by keeping track of Vcl and Nal separately.

[J_Darnley]

Then why are you against making x264 refuse to encode when --profile and --level have not been specified?

Simple, it prevents: x264 INPUT -o OUTPUT

A newbie is not expected to specify a profile and a valid level.

[Asmodian]

Then why are you against making x264 refuse to encode when --profile and --level have not been specified?

With that "--no-vbv" option you suggested, x264 could still be made to refuse to encode by default when --profile and --level have not been specified.

I do want to be able to encode completely unrestricted (not spec compliant) H.264 with x264.

[J_Darnley]

But a "newbie" should not be exposed to default options which might produce an output outside of the H.264 specifications, don't you think?

It seems that everyone (okay most people) but you is fine with the defaults because they'll be played just fine on many PCs. Only crazy people want to limit the quality of an encode just to comply with an arbitrary limit set in 2003.

[benwaggoner]

Only crazy people want to limit the quality of an encode just to comply with an arbitrary limit set in 2003.
Or people who make encodes that need to play on a large number of different players with different ASICs, and want full spec compliance to reduce the chance of problems. And of ASIC vendors being able to say it isn't their fault a file won't decode since it is out of spec.

Also, the max VBV and bitrates for H.264 Levels are really very generous, and way more than x264 would need in practical use. Has anyone actually seen a meaningful quality degradation caused by enforcing VBV? I strongly suspect that this is a mainly theoretical concern.

A totally free encode just shouldn't have a level specified in my opinion. A Level is a promise to meet certain technical requirements, and it's not a good idea to enforce some but not others.

[akupenguin]

A totally free encode just shouldn't have a level specified in my opinion.
Agreed. But it's syntactically impossible to not write a level in the bitstream. Do you think we could convince the standard committee to add an unrestricted level, or are you suggesting that we unilaterally invent one, or just talking about an ideal world?

[mandarinka]

The fact that the standard doesn't provide an unrestricted level is a failing of the standard, not a reason to apply restrictions that the user didn't ask for.

I fully agree with this. So please allow us to keep breaking the specifications :)

[benwaggoner]

Then, instead of talking about things which are impossible, let's talk about things which very well should be possible for you, namely:

Just make x264 comply to current H.264 specs by default by doing this:

1. Change --level to make it limit DPB and VBV according to choosen Profile @ Level

2. Change --level to make it override --ref / --vbv-bufsize / --vbv-maxrate if they are specified above the limits of choosen Profile @ Level

3. Change x264 to make it abort encoding if framesize and framerate are incompatible with the specified Level
These all seem very sensible to me.

4. Change x264 to make it refuse to encode when --level has not been specified

or, if you are not okay with making it refuse to encode, then:

4. Change x264 to make it default to --level 5.2 when --level has not been specified

I think a better default behavior for when level is not specified would be:

When level is not specified, the most restrictive level compatible with all specified parameters will be used. For example, for 720x576p25, Level 3.0 would be used, but 720x576p30 would use Level 3.1. If 720x576p25 was specified with 6 reference frames, Level 3.1 would also be used.

I remain skeptical that the VBV requirements by level are a significant practical source of real-world image degradation, and believe that defaulting to compatibility is preferable.

Looking at other encoders, the default VBV used is often a lot lower than the spec maximum (e.g. defaulting to one second at the peak bitrate). Unless someone can show me a compelling visual example where VBV meaningfully hurts quality, I don't have any reason to believe this is a significant tradeoff.

And if there is a quality issue, it could well just reveal somewhere that rate control needs more tuning. In the Leaky Bucket model, having a sufficiently big bucket acts like not having a bucket at all. The question isn't "are buckets bad?" but "is this bucket big enough?"

Is that so very difficult :rolleyes::p:D;)?
This is a significant change we're asking for other people to do for us for free. Let's not assume it's trivial, or doesn't have downsides.

[sneaker_ger]

When level is not specified, the most restrictive level compatible with all specified parameters will be used. For example, for 720x576p25, Level 3.0 would be used, but 720x576p30 would use Level 3.1. If 720x576p25 was specified with 6 reference frames, Level 3.1 would also be used.

x264cli already does level auto-guessing, so there's nothing to be re-invented.

Looking at other encoders, the default VBV used is often a lot lower than the spec maximum (e.g. defaulting to one second at the peak bitrate). Unless someone can show me a compelling visual example where VBV meaningfully hurts quality, I don't have any reason to believe this is a significant tradeoff.

I think I remember reading a complaint about vbv somewhere, can't find it right now. Maybe if you actually come close to the bitrate limits it will raise qp in e.g. a row really high, causing ugly artifacts. I'll try looking for the report again. (Unless an x264 dev can debunk this as nonsense in the mean time.)

/edit:
found post, wasn't vbv related

[sneaker_ger]

Yes, but this is irrelevant for the discussion at hand, because we are talking about potential auto forcing of vbv. So x264cli could guess the level like it always has and just force the corresponding vbv values on top of that.

[mandarinka]

Is it that hard for users that demand vbv to enable it on their own?

[IanB]

Geez, how to break existing stuff.

Yes, one can argue x264 doesn't implement --level the way they might like it to, but that doesn't get very far.

A more reasonable approach might be to say, okay --level works a certain way, users have an existing expectation, let it alone and move on to a more amiable solution.

Some example thoughts :-
a. add some declarative to the levels string like "3.2!", "#3.2" or "3.2full".
b. or add a new option like --hardlevel, --fulllevel, --h264level, --enforcelevel or --analretentivelevel.
c. or some other creative solution that doesn't break existing expectations.

[Nevilne]

You're in luck! x264 welcomes patches from everyone, nothing is stopping you from writing your own!

[Asmodian]

When no level has been specified manually, then it should not be possible to encode at 3840x2160p60 with 16 reference frames IMHO.

Also, IMHO, x264 should automatically abort encoding if someone tries to encode at 7680x4320p60 (just an example for a framesize/framerate combination not covered by H.264 specs), even if no level has been specified manually :o

Why not just throw a warning if the encode is outside defined levels? No need to abort the encode!

I am not sure why it didn't occur to me before but I agree with IanB, don't break anything. Sure, it makes more sense to me to have --level X set VBV but I am already very comfortable setting VBV and this isn't a big enough problem to mess with everyone who already has a working solution and is used to current behavior. A new setting like --enforcelevel would be better.

Of course if you are reading this thread you can just set it however you want it set, no need to change anything. ;)

[shon3i]

This is old and tricky problem, because we can use blu-ray compat option, and then why we have not same treatment but with BD rules to easily get bd compatible stream? That's why developers want --device option, which cover that all restrictions.

[benwaggoner]

Is it that hard for users that demand vbv to enable it on their own?
Yes.

Most users wouldn't know they need it.
If they did, they wouldn't know where to start in finding the correct value.
Even if there was a handy chart somewhere, the odds of getting it wrong are high. For example, using the value for High 3.0 instead of Main 3.0, or modifying an existing command line and forgetting to adjust VBV for Profile or Level changes,


Basically, in the current implementation only the people who know how to set vbv manually know to do it correctly. The vast majority of users don't, and thus may make non-compliant files.

[mandarinka]

Yes.
[LIST=1]
Most users wouldn't know they need it.


Most users wouldn't need it in the first place, imho, so the problem isn't nearly as big as you are thinking.

[Blue_MiSfit]

Basically, in the current implementation only the people who know how to set vbv manually know to do it correctly. The vast majority of users don't, and thus may make non-compliant files.

This.

[Asmodian]

Would a change to --level setting VBV as well break or damage anything? As a compromise, if the auto set level from "x264 -o out in" didn't enforce VBV but the --level setting did?

I have never noticed a quality drop when setting VBV for high profile level 4.1 encodes but my average bit rate is almost never over 10Mbit.

On the other hand what is wrong with the uninformed getting out of spec H.264 when using x264? :p

[Blue_MiSfit]

On the other hand what is wrong with the uninformed getting out of spec H.264 when using x264?


If you're Joe Sixpack, and you do some encoding, wouldn't you be totally pissed off if the file you encoded didn't play properly on a hardware device? Enforcing VBV by default makes this scenario much less likely.

Granted, the chances that the layperson will be using x264 directly are somewhat slim, but this still helps the newbies.

[picturebuffer]

Highly interesting thread! Thanks a lot, and sorry for going offtopic a bit.

But please let me get one last thing straight once and for all.
If i need to create a profile&level compliant file that actually uses up to the maximum of specified bitrates, I would set for baseline@3.0:
"--level 3.0 --profile baseline --bitrate 10000 --vbv_maxrate=10000 --vbv_bufsize=10000"
right?

Looking into the results with Bitrateviewer I get a maximum of 12080kbps. Is this file still level compliant (I would say, no since 10Mbit/s is exceeded). If I use the vbvchecker with said vbv information I get 10000000 Bit/s Bitrate (which looks okay to me at first glance).

So, is using said Buffer settings (and actually having over-limit peaks in sliding window of 1 second) enough to achieve compliancy, or with what tool am I able to verify that a maximum bitrate of flavour "Max video bit rate MaxBR" as per Spec is not violated?

[sneaker_ger]

If i need to create a profile&level compliant file that actually uses up to the maximum of specified bitrates, I would set for baseline@3.0:
"--level 3.0 --profile baseline --bitrate 10000 --vbv_maxrate=10000 --vbv_bufsize=10000"
right?

Correct.

Looking into the results with Bitrateviewer I get a maximum of 12080kbps. Is this file still level compliant?

Yes, the bitrate limitation works with the vbv model, which allows for short bitrate spikes exceeding the maxrate.

So, is using said Buffer settings enough to achieve compliancy

Yes.
x264 would throw a warning it it were to fail to achieve the correct bitrate limitations.

[paradoxical]

Probably not unless you or someone else is willing to code a patch.

[Guest]

The notion "instantaneous bitrate" is incoherent. What exactly do you mean by that?

[Blue_MiSfit]

I'm guessing the maximum frame size, but expressed unusually.

So, let's say you have a stream where the largest frame takes 9 megabits. I can see how you'd say 9 mbps is the peak instantaneous bitrate, even though that makes very little sense :)

[Asmodian]

It would be 9 megabits per (second/frame rate) though. ;)

Maximum frame size doesn't quite work because they all depend on the past and future bitrates. You cannot know it based on the VBV settings, only after you finished a particular encode. It only makes sense before doing a specific encode if you think about it as a buffer.

If you set --vbv-bufsize 78125 --vbv-maxrate 62500 the largest 1.25 seconds of video could be is 78125 kb but one second of video could be larger than 62500 kb. One second could even go up to almost 78125 kb if the other 0.25 seconds took almost no space.

EDIT: This is wrong! I forgot the buffer filling while playing.

[Guest]

dynaflash: 5000/5000 will allow 1 second spike of 10000 mbps Something happening over 1 second is not instantaneous. My point is that you have to refer a bitrate to the period it is measured over, just as Manao is doing in that chat log.

[paradoxical]

The formula that Manao used is pretty obvious from reading his comments. Apply it to your case and you have your answer.

<06/06/07 01:03pm> Manao | anyway, with 5000/2500, you get 1.5 * 5000 / 1 = 7500 kbps over 1 seconds
<06/06/07 01:05pm> rhester | OK, here's where my ignorance comes in...where did the 1.5 come from?
<06/06/07 01:05pm> Manao | T + buffer duration
<06/06/07 01:05pm> Manao | T = 1 second
<06/06/07 01:05pm> Manao | buffer duration = 0.5 second
<06/06/07 01:05pm> rhester | Right
<06/06/07 01:05pm> rhester | got it
<06/06/07 01:05pm> rhester | So going back to the damned-HBO-logo-on-iPod problem
<06/06/07 01:05pm> dynaflash | cause 2500 is half of 5000 ?
<06/06/07 01:06pm> rhester | dyna: Yes, that's the equation that shows the relationship of rate to bufsize that we were discussing on
<06/06/07 01:06pm> Manao | 2500 with a bitrate of 5000 means the vbv has a duration of half a second

So in your case it is ((1 + (bufsize / maxrate)) * maxrate) / 1 = your answer. Swap out the 1 for whatever duration you want to calculate over.

[paradoxical]

140625 Kbps?

If that's what you got from using the formula, yes.

[Asmodian]

Oh I see what I forgot. The buffer also fills by maxrate over that time period so you get that formula, or as solved for a 1 second time period:

bufsize+maxrate

But isn't that formula wrong? Isn't the formula to calculate the max size for any time period just:

bufsize + ( t * maxrate ) = size per t

There is no max rate out of the buffer right? You could empty the entire buffer in 0.25 seconds and it would fill an extra ( 0.25 seconds * maxrate ) over that quarter second.

edit: neither are wrong both our formulas are the same, mine gives size while paradoxical's gives bitrate. :)

[vivan]

if you don't know what vbv is, why are you even talking about it?

Which one is correct? 40 Mbps? Or 70 Mbps?This number ("maximum videobitrate") is meaningless without buffer size (that has been said several times even in this thread!), but what the point of saying that if you even don't want to understand what does this means?

[vivan]

What exactly is your point? The buffer size is defined in this case, namely: --vbv-bufsize 30000.And what is your point? vbv-maxrate is, by definition, "Maximum bitrate". Period.

How can you accuse someone not being willing to understand something even though he is asking questions?Because this questions have already been answered.

Your post already has been edited by neuron2. For whatever reason your attitude seems to be somewhat rude IMHO. Not sure what's your point.Because you're keep posting everywhere silly questions without willing to do something or even to understand something.

[vivan]

When encoding with --vbv-bufsize 78125 --vbv-maxrate 62500 for example, then the "Maximum bit rate" row in MediaInfo text output sometimes shows a (much) higher value than just 61.04 Mbps (62500 Kbps).That is exactly what I was talking about: you don't want to use search.
https://www.google.com/search?q=site%3Adoom9.org+mediainfo+maximum+bitrate+vbv Answer is not just on the first page, it's even the first result!

[IanB]

Perhaps if we look at this from a different perspective.

The --vbv-maxrate 40000 specifies the long term maximum rate of the source channel. i.e. how fast the BD, DVD, www. , etc can feed data to you.

The --vbv-bufsize 30000 specifies the maximum 1 time burst of data you can have in reserve.

So if for the previous period the stream average has been less than 40000Kb/s the buffer will be filling towards 30000Kb. With the buffer full a short group of frames or even a single frame may take in a single hit up to 30000Kb plus the amount the stream can provide in that period. Of course the buffer is now empty so the subsequent frames may only take data at or less than the source channel rate.

For example, a 25fps stream has each frame duration of 40ms, so in each 40ms period the stream can deliver 1600Kb. Whenever the frames are less than 1600Kb the excess data can be used to fill the buffer. And whenever the frames are greater than 1600Kb they will drain the buffer by the short fall. So if the frames are 1000kb each that leave 600kb each 40ms to fill the buffer and so an initially empty buffer will be full after 2 seconds (30000/600*40ms) of such frames.

At that point 1 frame could take up to 30000kb+1600kb in a single 40ms period. This would represent a 40ms average data rate of 790000kb/s.

Alternatively a 25 frame burst could take up to 30000kb+40000kb in a 1 second period. This would represent a 1 second average data rate of 70000kb/s.

Similarly a 50 frame burst could take up to 30000kb+2*40000kb in a 2 second period. This would represent a 2 second average data rate of 55000kb/s.

You can do the same analysis for any frame rate, eg 60fps, frame duration 16.6ms, average 666.Kb available per frame. One frame burst rate 1840000Kb/s.

Of course mpeg type encoding have B frames, which means out of order decoding to consider as well.

[Soukyuu]

Who would have known that my noob question would spark a 7 page long thread O_O
Which explains while I only came back here now.

Soukyuu, just for fun I gave your sample a spin. Of course it doesn't help you in any way, but.... my 8600GT video card got through it, albeit while stuttering quite a lot. The E6750 CPU managed without stuttering, but CPU usage got dangerously close to 100%.
Believe it or not, my Motorola Razr cell phone plays it fairly well, maybe a little "jittery" in one spot but smoothly for 95% of it as best as I can tell on the little screen. Seems kind of odd..... my phone's better at decoding video that my PC's video card.....Maybe it has something to do with the hardware decoder? The laptop happens to have a (now fried) 8600m GT too and it stuttered just as much as the CPU did. The 260GTX stuttered horribly too, but my quadcore didn't. The Razr (new or old?) decoding it well is kinda surprised, considering I saw it stutter at much lower resolution videos. My Nexus7 does not have any problems with the clip either, which is kinda silly considering my 260GTX should be much more powerful than that...

If you're Joe Sixpack, and you do some encoding, wouldn't you be totally pissed off if the file you encoded didn't play properly on a hardware device? Enforcing VBV by default makes this scenario much less likely.

Granted, the chances that the layperson will be using x264 directly are somewhat slim, but this still helps the newbies.Yes, one Joe Sixpack right here! (though it's a sixpack of beer *cough*)

[vivan]

Maybe it has something to do with the hardware decoder?Yes.

The 260GTX stuttered horribly too, but my quadcore didn't.GeForce GTX 260 is VP2 (http://en.wikipedia.org/wiki/Nvidia_PureVideo) and it's quite slow.

My Nexus7 does not have any problems with the clip either, which is kinda silly considering my 260GTX should be much more powerful than that...It's not about GPU power, it's about h/w decoder power ;)
E.g. I have ati 5870 and it can't handle decoding of 50 fps video, while QS in intel HD 3000 can decode that video much, much faster - at 200-300 fps.
So no surprise that modern mobile h/w decoders are fast too :)

[kotuwa]

guys a question :)
I want to compress a video. Smaller file size is a main requirement.

The video has some scenes with extremely high details. Waterfalls, water flowing. rapid movements... But those detailed are not that needed...
No problem if they are encoded with low quality....

I did encode once and it gave a little big size.... CRF=24 was used...
Mediainfo says "Maximum bit rate : 24.0 Mbps" is it "--vbv-maxrate" that showed as 24.0 Mbps, or anything else?

The average/normal bitrate is about 1000 Kbps...
Is it ok putting ---vbv-maxrate 3000 !? to avoid unnecessary bits being applied to those ugly waterfalls?
How would this affect other scenes, the scense that does not require 3000 kbps !?

Using a higher CRF value would reduce the quality of other parts... :(
Zones would be good but they appear in several places, making using zones is harder...

[huhn]

---vbv-maxrate 3000


this should only harm scene with the need for more than 3 mbit so the scene with 24 mbit will look terrible