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.