Profile levels, maximum bitrate and crf

[Soukyuu]

Hello,

I'm quite new to encoding, especially with x264 so I'm kinda poking in the dark at the moment.

So far I've been using CRF as my bitrate/quality setting without problems, until I hit this scene (https://dl.dropbox.com/u/19330332/test.mp4) (114Mb). According to this post (http://forum.doom9.org/showthread.php?p=1586087#post1586087), the scene peaks at 97Mbps, making decoding extremely hard. I am still able to play it back using software decoding, but my 260GTX stutters horribly and my Core2Duo laptop dies with an accusing whimper.

The settings I used were the following: --crf 24 --b-adapt 2 --qpmax 51 --me umh --subme 10 --trellis 2
AVC Level was set to unrestricted/autoguess in MeGUI, so I thought this was the cause.
After checking wikipedia about the avc levels, I decided to go with Level 4, which should have limited maximum allowed bitrate to 25Mbps... but it didn't work. The resulting file stutters just as the unrestricted one.

Can anyone suggest me an option to use to reduce the insane bitrate at that scene without noticeably losing quality?

[Blue_MiSfit]

This is one of the purposes of the VBV buffer :)

For 1080p, I'd suggest adding the following to your command line. This will make the video compliant with High Profile @ Level 4.1, which allows for up to 62.5 mbps.


--level 41 --vbv-bufsize 62000 --vbv-maxrate 62000


Derek

[Soukyuu]

Thanks, that seems to have fixed the stuttering.

I'm still a bit confused about the level setting though, why is simply specifying it not restricting the bitrate?
It kind of feels like a "I am a level x compliant file! i lied :D" setting that way...

[Blue_MiSfit]

The --level flag does limit the number of reference frames used... but I think that's it.

I believe the idea was that you shouldn't force users to use VBV when they don't need it. Note that if you use VBV, but set maxrate higher than supported for your chosen level, x264 will throw a warning.

When encoding for home, I basically always use CRF + VBV at 62mbps. When encoding professionally, it's usually CBR, and usually with very harsh constraints on buffer sizes (and other restrictions like short GOPs etc).

Derek

[Soukyuu]

I see. Are there any drawbacks using VBV, except for the obvious bitrate constraints?

[JEEB]

I see. Are there any drawbacks using VBV, except for the obvious bitrate constraints?
It's non-deterministic with multithreading, in order to use all of the information it can use to not go over the constraints you have set.

[Dark Shikari]

There are some cases where a device checks the level for compatibility, but nevertheless can handle higher bitrate than the level max. Some people didn't want x264 to force their bitrate down when they didn't want it to, so they whined when I suggested doing things the way you suggest.

[Atak_Snajpera]

Maybe they should switch to ripbot264 where --vbv-bufsize xxxxx and --vbv-maxrate xxxxx are automatically added to command line according to selected avc profile and level ...

http://i.imgur.com/Z3ser.png

[Blue_MiSfit]

Regarding 62.5 vs 62, that's just me being a bit paranoid. I always undershoot bitrates a tiny bit :)

I personally would like x264 to follow level constraints to the best of its ability, as I think this behavior would make sense and be desirable to the majority of users. The minority that wants to create streams flagged as level X, but actually violate level X could probably find another solution. I remember using an old MPEG-2 tool that could patch the header to change these sorts of things. I believe something similar exists for H.264 as well.

There's also an argument to be made that x264 shouldn't enforce limits like these, it should be up to the GUI or application using libx264 to get these things right.

The decision on which behavior to implement is up to me :)!

Like I said.. most of the encoding I do requires VBV settings much lower than the profile / level limits, so I always manually specify these values anyway.

Derek

[ajp_anton]

There are some cases where a device checks the level for compatibility, but nevertheless can handle higher bitrate than the level max. Some people didn't want x264 to force their bitrate down when they didn't want it to, so they whined when I suggested doing things the way you suggest.What's wrong with
--level 41 --vbv-bufsize 0 --vbv-maxrate 0

[Blue_MiSfit]

You have to specify both bufsize and maxrate.

If you only supply maxrate:

x264 [warning]: VBV maxrate specified, but no bufsize, ignored


If you only supply bufsize:

x264 [warning]: VBV maxrate unspecified, assuming CBR


I usually set bufsize equal to maxrate, unless a specification dictates otherwise.

Derek

[Sharc]

But Blu-ray compliance has its own rules and restrictions regarding VBV settings, right?
https://sites.google.com/site/x264bluray/
http://forum.doom9.org/showthread.php?t=154533

[Atak_Snajpera]

But Blu-ray compliance has its own rules and restrictions regarding VBV settings, right?
and so what?

if --vbv-bufsize and --vbv-maxrate are not specified then x264 should use default max values according to chosen level . Simple.

[Sharc]

Yes, but how about --bluray-compat --level 4.1 ?
Shouldn't --bluray-compat overwrite --level 4.1 buffer values in this case?

[detmek]

Yes, but how about --bluray-compat --level 4.1 ?
Shouldn't --bluray-compat overwrite --level 4.1 buffer values in this case?
AFAIK, --bluray-compat does not set --vbv-maxrate and --vbv-bufsize.

[Dark Shikari]

Bluray-compat doesn't set them because there is no single VBV for all Blu-ray profiles.

[shon3i]

it will be nice to x264 fully respect avc spec, that will facilitate for people that who don't know much about encoding, and for sure help more with compatibility with standalones or other devices. I know that earlier state of developers that x264 will not force anything and will be unrestricted as much as possible, but in other way there is no point flaging stream with some level when that level is not followed completly. Frst step has been limiting references (since almost all decoders prety much follow specs), but why not complete level specification? btw this is just my opinion, for me current state of x264 that vbv show warning (if something wrong) is completly fine.

Bluray-compat doesn't set them because there is no single VBV for all Blu-ray profiles. it seem just easy to get values based on resolution/fps, i don't think is that hard to implement some checker that will set everything before coding frames.

[hello_hello]

In theory, I guess it sounds more ideal for x264 to automatically enforce VBV values for each profile but......
In the real world, has anyone has problems playing their encodes because it doesn't? Is there an epidemic of x264 Level 4.1 encodes which won't play correctly on devices which support Level 4.1? I'm just wondering if it'd be a case of only fixing a theoretical problem.

Generally GUIs which support encoding for a target device will also add appropriate VBV settings if the device requires them.

--bluray-compat?? Is it really necessary these days? Are there many Bluray players which won't play anything which steps outside the official Bluray spec? I just encode using Level 4.1 these days and pretty much every device I'd be likely to use will play it. Even the oldest Bluray player in the house (maybe 5 years old). Even the hardware decoder in my Android smartphone happily decodes Level 4.1 up to 1080p, yet there's still standalone players which need --bluray-compat? Really??

As Soukyuu sounds like he's playing the video using a laptop CPU, which I don't believe are rated to play video using any particular AVC Level, would enforcing VBV restrictions according to level be forcing restrictions which generally aren't necessary, and which he can add manually?

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.....

[detmek]

You should use --bluray-compat only when you encode and author you own Blu-Ray Video. It should not be used for regular encodes.
Anyway, I found a custom x264 build marked as tmod which has switch "--level-force". I didn't test it yet but I think that it is good compromise between just flagging stream (as --level does) and forcing level restrictions with additional command --level-force.
"--level-force" should restrict reference frames, set VBV or abort encoding process if FPS or resolution are beyond values allowed by selected level.

[Blue_MiSfit]

Try playing BluRay level encodes over 802.11g WiFi :) Even 720p encodes at typical levels (16-24) will drop frames occasionally if you don't use VBV, especially if your connection is sub-optimal, as is my laptop's from my bedroom. I personally always use VBV.

[benwaggoner]

You should use --bluray-compat only when you encode and author you own Blu-Ray Video. It should not be used for regular encodes.
Anyway, I found a custom x264 build marked as tmod which has switch "--level-force". I didn't test it yet but I think that it is good compromise between just flagging stream (as --level does) and forcing level restrictions with additional command --level-force.
"--level-force" should restrict reference frames, set VBV or abort encoding process if FPS or resolution are beyond values allowed by selected level.
I think a flag is the way to handle it, but it think this is backwards.

If a profile@level is specified, x264 should always make a legal bitstream by default. Making it easy for a casual user to accidentally make files that won't decode well or at all on some decoders is just asking for trouble.

I've had real-world trouble with x264 files caused by this. It's easy to make a "Level 3.0" file that works fine on an iPhone 4, but try it on a 3G and it just doesn't play back. In my day job I need to make content that plays on dozens of different decoder chipsets, with more coming, and manually setting all the compliance parameters for each target is a total pain. And plenty of parameters rely on other parameters, like max reference frames and frame size, or max bitrate and Profile.

The enforced compliance of bitstreams encoded by major commercial tools is one thing that makes bigger shops wary of using x264. Targeting Flash, no problem. Targeting "it's gotta work on any Android 3.0 or higher device" is a whole different story.

Instead, for the weird times where someone wants to make a non-compliant bitstream. something like --level-override with would allow non-compliant parameters to be used: opt-in only. And then I can check the parameter string for files that have it set and reject them.

[detmek]

I think a flag is the way to handle it, but it think this is backwards.

If a profile@level is specified, x264 should always make a legal bitstream by default. Making it easy for a casual user to accidentally make files that won't decode well or at all on some decoders is just asking for trouble.

I've had real-world trouble with x264 files caused by this. It's easy to make a "Level 3.0" file that works fine on an iPhone 4, but try it on a 3G and it just doesn't play back. In my day job I need to make content that plays on dozens of different decoder chipsets, with more coming, and manually setting all the compliance parameters for each target is a total pain. And plenty of parameters rely on other parameters, like max reference frames and frame size, or max bitrate and Profile.

The enforced compliance of bitstreams encoded by major commercial tools is one thing that makes bigger shops wary of using x264. Targeting Flash, no problem. Targeting "it's gotta work on any Android 3.0 or higher device" is a whole different story.

Instead, for the weird times where someone wants to make a non-compliant bitstream. something like --level-override with would allow non-compliant parameters to be used: opt-in only. And then I can check the parameter string for files that have it set and reject them.

I agree. Setting level should always produce level complied stream. But I proposed an compromized solution because of this:

There are some cases where a device checks the level for compatibility, but nevertheless can handle higher bitrate than the level max. Some people didn't want x264 to force their bitrate down when they didn't want it to, so they whined when I suggested doing things the way you suggest.

[benwaggoner]

it rather looks like as if AVC specs would always require VBV (maximum bitrate) for every scenario/profile/level/etc., doesn't it?

There apparently is no such thing as "unrestricted" in AVC specs/levels/profiles, or is there?

So why isn't x264 complying to that at the moment?
Correct. Every H.264 bitstream is going to have a VBV. In practice, a given encode might not ever actually fill the maximum VBV allowed to the encoder.

And every Profile@Level is going to have a maximum VBV. It's only a fully unrestricted encode that could have it totally unbound (although there are going to be practical maximums even in that case).

It would be appreciated if "Dark Shikari" could reply as well :);).
Well, just because he's weighed in on this thread doesn't mean we have to hold him personally responsible for this :).

[vivan]

Hi444PP@L5.2 would be the current maximum, wouldn't it?

And even in that case it would not be unrestricted, wouldn't it? There would still be a maximum bitrate of 300 Mbps and nothing above for example, wouldn't there?Actually for Hi444PP it would be 960 Mbps.
And as for HiP - uncompressed 1920x1080@24 fps is 600 Mbps and 50% compression for x264 is a joke. So it is unrestricted for 1080p@24fps, unless you are compressing random noise.

Anyway, level doesn't specify buffer size.

[mandarinka]

In my day job I need to make content that plays on dozens of different decoder chipsets, with more coming, and manually setting all the compliance parameters for each target is a total pain.

The device patch, developed a year ago during Google Code In was explicitly targeted at this scenario (making videos compliant with a set of specified devices). However it didn't get finalised and merged. IIRC, the reason it didn't get included was just lack of developer resources, so with some sponsoring, it shouldn't be too hard to get the functionality in. (Hint...)

Correct. Every H.264 bitstream is going to have a VBV.
No thanks. I'm perfectly fine with the way it is now. Apparently most of the world doesn't care about VBV at all, so it's imho better to not force it on them.

[vivan]

According to the spreadsheet above it would still be limited to 300 Mpbs for HiP@L5.1/L5.2 and not 600 Mbps, wouldn't it?so what?

There is no such thing as "unrestricted" in AVC specs, or is there?There is no such thing as "restricted" either. Levels are part of AVC spec, but you can just igonre them, than it would be your problem.
E.g. what level software decoders support? Any.

And, currently, there also is no such thing as Level 5.3, or is there?But what about tomorrow?

As you already wrote, even for Hi444PP@L5.1/L5.2 there apparently is a limit at 960 Mbps, isn't there?And so what? Are there any h/w decoders that support that profile and level? And software decoders support any level.
more than 99.999% video will meet such requirements. And nobody really cares about the rest.

At least by looking at the spreadsheet above, it rather looks like as if everything above 960 Mbps would not comply to any current AVC spec?And what it would be? Not AVC? Or your computer should exlpode when decoding such video?

[smok3]

And what it would be? Not AVC? Or your computer should exlpode when decoding such video?

Its necessary that rules of the game are clear, so if my phone claims that it supports automatic beer ordering from local stores and fails to do that i will return it to the provider/seller.

[vivan]

Actually, at least by looking at that spreadsheet above, it at least would not be fully AVC compliant, wouldn't it ;)?Actually nobody cares about it.

So why is x264 not automatically setting bitrate limits accordingly by default if they are actually required by AVC specs?1) VBV slows encoding
2) Almost any device can do much more that it claims it can. E.g. my ps vita supports only High@L3.1 profile (even checks it before copying video). However it can play video with 40+ Mbit peak bitrate (which is almost 3 times more than 3.1 limit) and with 11 reference frames (3.1 limits it to 5).
3) VBV encoding is not deterministic.
So in real world automatic settings for VBV are worthless.

Also you're ignoring this part:Anyway, level doesn't specify buffer size.aren't you?

[mp3dom]

The output should follow 100% the AVC specs/profiles/levels...and by default. THEN you can think of allow a user to completely change the parameters, and output even a messy or faulty stream at all.
This is how it is supposed to be.
The fact that a device *may* support more than what is advertised for, doesn't count anything here.
The "standard" take precedence over the "not-standard" even if the "not-standard" is better quality-wise (unless, in this case, the encoder is advertised to 'not strictly follow' the specs by default).

[mandarinka]

Why? The people that care about it (business users) should know what they are doing and not use defaults in the first place.

[fields_g]

The confusion is coming from the --level switch setting some things, but not all things to the published spec. It is inconsistant. It should be rewritten as either:
a) --levelflag and does no restricting, leaving all user to set features to meet level compliance <Not Recommended>
b) --level that implements all restrictions (and if you are nice, also --levelflag, so advanced users specify all the encoder restrictions and can have x264 lie for them, ... or keep x264 honest and make this an outside utility)

It is not our problem that some players insists on looking for a certain level, but has the capability for much more. Talk to you vendor for different firmware/software that more realistically checks its inputs. This reminds me of overclocking a processor. I'd much prefer to have the processor work to spec when installed in a motherboard, but then the motherboard allowed the user to enhance their experience/destroy stability by choices the user intentionally made.

[benwaggoner]

No thanks. I'm perfectly fine with the way it is now. Apparently most of the world doesn't care about VBV at all, so it's imho better to not force it on them.
But this is one reason why "most of the world" doesn't use H.264 more. Sure, x264 has great features, but if you want to be 100% sure that you're going to make a Profile@Level compliant file without having to do tweaking, testing, and referring to documentation, something like ProMedia Carbon is way more reliable. It won't even let you set parameters to anything incompatible with the specified Profile@Level. Type too high a frame rate, frame size, VBV, peak bitrate, etcetera,and it'll reset the input to the maximum supported value.

I note that MeGUI and other front ends automatically apply correct enforcement here, so there's definitely a need for it for consumers as well.

Even though plenty of devices can do more than the specified Profile@Level, they don't all do the "same" more. It's device by device, and I don't want a device specific output unless I explicitly specify one.

[Guest]

But this is one reason why "most of the world" doesn't use H.264 more. Did you mean x264?

[benwaggoner]

Did you mean x264?
Yes, of course :).

[akupenguin]

@all:
I have no objection to --level setting vbv. In fact, I endorsed to that behavior a couple years ago when we were deciding how --device should work, and I just didn't notice that that part got dropped along with the rest of --device.

Otoh, there will still not be any vbv by default if the user didn't ask for a --level. 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.

[akupenguin]

And does anyone know where all the values in that table on the Wikipedia page are originating from?
The H.264 Standard (http://www.itu.int/rec/T-REC-H.264-201201-I/en), Table A-1.
Which includes some values, including bufsize, that were not pasted into wikipedia.

So does anyone know if setting bufsize equal to maxrate, like "Blue_MiSfit" mentioned", would comply to AVC specs?
Yes. It so happens that max bufsize >= max maxrate for all levels.

[Asmodian]

"Max decoded picture buffer size MaxDpbMbs (MBs)" is not what is set by --vbv-bufsize.

[sneaker_ger]

Page 292

[sneaker_ger]

Oh, you meant those factors:
Table A-2, page 295

[SassBot]

vbv-bufsize = MaxCPB and vbv-maxrate is MaxBR.

[Blue_MiSfit]

Right. The distinction is coded versus decoded picture buffer.

Think about it... x264 is modeling buffering coded pictures. :)

[JEEB]

Hello,

any news from the x264 developers?

Have you already decided if you are going to make "--level" automatically limit bitrate (VBV) accordingly?
As far as I can see the developers aren't against it, but no-one hasn't taken the old device patch, and taken the autovbv part of it.

If you want to see it ASAP, I recommend you take a look at the old device patch and rip out the autovbv functionality from it. I might even think that the autovbv thing by itself might be a separate patch somewhere by now, so if that could be updated to match current code tree and posted to the developers on IRC for review that'd probably take it further down the line.

[Asmodian]

I think that is just everyone being cautious. And it doesn't hurt quality (much?).

If I understand the pdf linked above (which is not guaranteed) the max vbv-bufsize can be 1.2 times the max vbv-maxrate.

Of course HandBrakeCLI seems to be using 1.25 instead of 1.2?

Hmm, after looking over that document some more I have to admit I am more confused. I don't know what we are setting with vbv, do we care about cpbBrVclFactor or cpbBrNalFactor? It does look like vbv-bufsize is 1.25 times vbv-maxrate. The problem is that it is usually recommended to set vbv-maxrate to "Max CPB size" instead of "Max video bit rate" and "Max CPB size" is 1.25 times "Max video bit rate" so going 1.25 times again doesn't make sense? This makes me think there has been some confusion on my part.

I think Table A-1 states, for level 4.1:
if we are setting cpbBrVclFactor:
vbv-maxrate 50000, vbv-bufsize 62500

if we are setting cpbBrNalFactor:
vbv-maxrate 60000, vbv-bufsize 75000

Of course the real values being set by vbv might be from one of the many paragraphs like this:In bitstreams conforming to the High, Progressive High, or Constrained High profiles, the sum of the
NumBytesInNALunit variables for access unit 0 is less than or equal to
384 * ( Max( PicSizeInMbs, fR * MaxMBPS ) + MaxMBPS * ( tr( 0 ) − tr,n( 0 ) ) ) ÷ MinCR, where MaxMBPS
and MinCR are the values specified in Table A-1 that apply to picture 0 and PicSizeInMbs is the number of
macroblocks in picture 0.
NOTE 3 – Such a limit involving MinCR is not imposed for bitstream conformance to the High 10, High 4:2:2,
High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra, and CAVLC 4:4:4 Intra profiles.

Which I don't have the will to decode. :o

Not sure what to make of this.

[akupenguin]

@jq963152
High profile raises all of the allowed vbv values by 25%. Yes, that's just as weird as it sounds, if you thought levels were supposed to be orthogonal to profiles. (And they were supposed to be, in the first versions of the standard.)
The maximum for Main Profile Level 4.1 is vbv-maxrate 50000, vbv-bufsize 62500.
The maximum for High Profile Level 4.1 is vbv-maxrate 62500, vbv-bufsize 78125.

@Asmodian
There is no fixed ratio between the limits on maxrate and bufsize. Levels 1.1 through 1.3 have a ratio of 2.6. Levels 2.0 through 3.2 and 5.0+ have a ratio of 1. Levels 4.0 through 4.2 have a ratio of 1.25. And that's only if you're maxing out both; you're always allowed to decrease one of the vbv params without proportionally changing the other.

There is no recommended ratio either. The optimal thing to do is set both as high as your use-case constraints allow. There isn't and can't be any recommendation for what to set them to in the absence of constraints imposed by your use-case, because you shouldn't use vbv at all if you don't have any such constraints.

We care about cpbBrVclFactor.

[Asmodian]

Ah, thank you very much! So much clearer now.

Yes my post was only thinking about level 4.1 though I didn't state that. Did you get the difference between main and high profiles from Table A-2?

So for level 4.1:
Main: 50000, 62500
High: 62500, 78125
High10: 150000, 187500
High 4:2:2 & High 4:4:4: 200000, 250000

Tricky, two places with 1.25x for my test level 4.1. I never guessed Table A-2 was changing the values in A-1 but now it makes perfect sense. Not sure how I feel about changing the "units" instead of just specifying different values for different profiles but they obviously didn't want the specs to be easy to read.

High 4:2:2 level 5.1 is quite crazy at 960000, 960000 :)

There is no recommended ratio either. The optimal thing to do is set both as high as your use-case constraints allow. There isn't and can't be any recommendation for what to set them to in the absence of constraints imposed by your use-case, because you shouldn't use vbv at all if you don't have any such constraints.

Ah but the use-case is "compliant with level X" so, if I understand, a device which supports high profile level 4.1 must allow a vbv-bufsize of up to 78125 or a device which supports high profile level 3.0 must allow a vbv-bufsize of up to 12500. By setting them lower we effectively lower the max instantaneous bit rate, albeit in a different way than lowering maxrate would.

Is there a use-case where setting vbv-bufsize lower than the level allows would be useful? vbv-maxrate for media/network speeds but vbv-bufsize?

An advantage I can see is lower startup times when streaming but I understand streaming systems usually do not follow vbv settings (they don't wait for vbv-bufsize to be full before starting playback) but use their own buffering system? Or maybe as a way to clip bit rate spikes?

[sneaker_ger]

As already mentioned, there are several posts that can be found here on the Doom9 forums, where users seem to suggest that vbv-bufsize should be equal or smaller than vbv-maxrate, see for example:

http://forum.doom9.org/showpost.php?p=1586642&postcount=10
http://forum.doom9.org/showpost.php?p=1339915&postcount=5
http://forum.doom9.org/showpost.php?p=1586400&postcount=2
http://forum.doom9.org/showpost.php?p=1586646&postcount=11

And so on...

Why is that?

Is it because they didn't know better :p:D;)?

Or is there any advantage to it?

Either people don't know any better or they are talking about Blu-Ray, where bufsize must not be greater than maxrate. (Disregarding units...)

[Blue_MiSfit]

Indeed, I wasn't aware that the spec defined that the max bufsize was larger than the max maxrate.

Most applications use much smaller values for both, but my comment (the last one) was meant to be a conservative estimate. The settings I suggested would still be compliant to HP@4.1.

However, as akupenguin clearly stated, the correct values for both depend on the application. If there's no requirement for VBV, then you shouldn't use it :)

Derek

[akupenguin]

Did you get the difference between main and high profiles from Table A-2?
Yes.

Is there a use-case where setting vbv-bufsize lower than the level allows would be useful? vbv-maxrate for media/network speeds but vbv-bufsize?


You could be targeting some particular device. While hardware manufacturers can take the levels as a suggestion, their speed and memory don't have to exactly equal one of the levels. Blu-ray is an example of this.

Yes, vbv-maxrate could be limited by network bandwidth. vbv-bufsize could be limited by desired latency; videoconferencing sets it really small.

An advantage I can see is lower startup times when streaming but I understand streaming systems usually do not follow vbv settings (they don't wait for vbv-bufsize to be full before starting playback) but use their own buffering system?

At any given point in the stream, there is some amount of data that is supposed to be in the decoder's vbv buffer. This value is usually not "completely full". And if you enable --nal-hrd, then it's written to the bitstream at keyframes, so that a decoder knows exactly how soon it can start playing. Or a streaming server could analyze a movie, recalculate these values, and transmit them out of band.

Thus, bufsize/maxrate is the total network latency for a realtime broadcast. It's also an upper bound on the seeking or channel-change latency; the exact value for any given seek being buffer_fullness/actual_bandwidth.

If you want to minimize startup latency but don't care about steady-state latency or people joining the stream in the middle, i.e. "progressive download", you could use a huge bufsize with small initial fullness.

Or maybe as a way to clip bit rate spikes?
Limited throughput of a cabac parser is one of the things that can go into the determination of what maxrate a device officially supports; this is probably where dxva's bitrate limits come from. But vbv is a good model of network buffering, and poor model of cabac. Any device that publishes its cabac limits in the form of vbv parameters should be able to handle vbvs significantly larger than that, if you had an encoder mode that was calibrated for the actual bottleneck. Either that or they're not actually worst-case limits, and the device would stutter on some streams that comply with its nominal capabilities. Equivalently, if you're using vbv to deal with limited cpu speed, then you're restricting ratecontrol more than necessary (though I haven't implemented what you should use instead).

[Asmodian]

And then, on top of that, make x264 refuse to encode when --profile and --level have not been specified.

Ack! not this! I love that x264 can do "I don't care I have an i7" encoding, vbv does slow down encoding and it changes the results. I agree --level X should also specify vbv but I would still want "--level X --no-vbv" or something.

[benwaggoner]

So why are you recommending not to use VBV if there are no VBV constraints, although the H.264 specifications always define VBV constraints?
Well, there are always VBV constraints whenver a Level is specified.

I feel strongly that when a level is specified, the requirements of that level need to be followed precisely. People who want to do "free" encode can just not specify a level, and they'll get whatever they get for output.

Those of us who need to have a single bitstream that can work on a wide variety of different current and future decoders want all streams to be as spec compliant as possible.

[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