Advanced feature request-- x264, x265 additional parameters

musicvid

Member
Danr.
Having not paid much attention to vbv-bufsize in the past, I had to do a little digging.
Yes, I believe HRD compliance is implicit, for controlling VBV overflow and underflow.

In ffmpeg, vbv-bufsize serves a special purpose when used with vbv-maxrate, in that it determines how often the encoder bitrate snapshot is updated. If bufsize=maxrate, it updates every second. If bufsize is double the maxrate, it updates every two seconds. The buffer input bitrate is always changing; vbv-maxrate doesn't work without specifying a bufsize.

Here's a very basic explanation from ffmpeg regarding ABR that I can relate to:
Be sure to expand the quote.
What does -bufsize do?
Based on the -bufsize option, ffmpeg will calculate and correct the average bit rate produced. If we didn't specify -bufsize, these intervals could be significantly longer than we would want. This would cause the current bit rate to frequently jump a lot over and below the specified average bit rate and would cause an unsteady output bit rate.

If we specify a smaller -bufsize, ffmpeg will more frequently check for the output bit rate and constrain it to the specified average bit rate from the command line. Hence, lowering -bufsize lowers the bitrate variation that the encoder can produce.

Specifying too small -bufsize would cause ffmpeg to degrade the output image quality, because it would have to (frequently) conform to the limitations and would not have enough of a free space to use some optimizations (for example, optimizations based on the frame repetitions and similar), because the buffer would not contain enough frames for the optimizations to be effective.

The suggestion is to play around with the combinations of -bufsize, starting from the same value like the one specified for the -b:v option (or even half of it) and increasing it until your output bit rate starts jumping too much above/below the specified average bit rate. Then you know you've reached the limit and should lower the -bufsize value a little bit in order to get back on the safe side.
This works the same with CRF, except the bitrate "target" is a constantly moving one, putting the complexity of that inquiry a little above my pay scale. Here's what ffmpeg says about that:
-maxrate
Anytime you are encoding video with bandwidth as a limiting factor you should be using VBV (Video Buffer Verifier) with the -maxrate and -bufsize options:

  • Assuming your upload rate is 1024kbit/s (1 megabit/s), and assuming you can reliably utilize 80% of that = 820 kbit/s. Audio will consume 128 kbit/s (64k/channel for stereo, but you can of course use a different audio bitrate) leaving ~692 kbit/s for video: this is your -maxrate value.
  • If you have a sane upload rate, or do not know what to choose then a -maxrate value of up to 3000k-4000k will probably be fine if your upload rate can handle it (depending on your input complexity and -video_size). Refer to your streaming service for any limitations that may apply.
  • Note that the claimed data rate pay your ISP for may not actually be what you get. You can use a site like speedtest.net to test.
-bufsize
-bufsize sets the buffer size, and can be 1-2 seconds for most gaming screencasts, and up to 5 seconds for more static content. If you use -maxrate 960k then use a -bufsize of 960k-1920k. You will have to experiment to see what looks best for your content. Refer to your streaming service for the recommended buffer size (it may be shown in seconds or bits).
So family video might be just fine with bufsize at 200% of maxrate, while a gaming video might stream better at 125% with all the sudden starts and stops. The first quote above also explains why my maxrate test illustrated above was more precise with bufsize at 120% than at 200%. Handbrake presets all appear to be bufsize=1.25 x maxrate.

So, in practice, it doesn't make a lot of difference, with such a wide range of acceptable values. In your interface, you could leave bufsize at Profile maximum, or you could calculate it silently as a factor of user-input maxrate (b=1.25m). Too much user control of vbv-bufsize might cause anomalies, because most won't have a clue
 
Last edited:

musicvid

Member
Duplicates edited out, forum is acting really screwy, deleting everything then reinstating multiple duplicat posts??
Sorry for duplicates in your Inbox, DanR. It was unintentional.
 
Last edited:

Danr

Administrator
Staff member
It's funny that they didn't discuss how the vbv-bufsize affects transport stream muxing and decoding. That's probably because the ffmpeg TS muxing has near 0% compliance with proper TS buffer management. Anyway, your posts are really useful, and helps rationalize the bufsize setting.
 

musicvid

Member
It's funny that they didn't discuss how the vbv-bufsize affects transport stream muxing and decoding.
Probably because they're avoiding the issue; as you well know, Transport broadcast streams can contain so many errors. ffmpeg can mux and wrap, but not sanitize stream and GOP errors the way VRD does. Many have found out the hard way that just rewrapping TS as a program stream is a little like putting mascara on a pig.
I've gotten in the habit of QSFing all transport streams to PS before editing in VRD or Vegas.

Thanks for the kind words, glad to help where I can. I'm more of a producer with good math instincts, rather than an engineer
 
Last edited:

musicvid

Member
Here's a useful bandwidth compression technique using maxrate and ABR, that enhances detail and reduces blocking in shadows, fades, and transitions.

Background: In the early days of DVD production with VBR, encoders such as Mainconcept had target values specified for Min, Max, and Avg bitrates. The purpose of Minimum bitrate control was to boost suboptimal rendering of low-complexity areas, specifically shadows, fades, and transitions, to prevent large, blocky artifacts from ruining the encode. For instance, 1Mbps Min was usually blocky, while 2Mbps was always clean and free of visible artifacts. It was the one parameter over which bandwidth-centric encoders had a big advantage, perhaps the only one ...​
Unfortunately, with CQ / CRF encoding came the end of Minimum bitrate control. There is no such setting in x264; instead, just a --deblock setting which actually blurs the shadows rather than adding much-needed bits to the mix.​

So, here is a technique that achieves some minimum bitrate control in x264, although indirectly. If we set ABR, maxrate, and bufsize near the same value, both min and max are compressed, removing low-pass blockiness, as well as managing peaks as we discussed earlier. In this example, Minimum bitrate has been raised a whopping 4,700 Kbps, or 35%! This effectively eliminating any possibility of encoder-mediated shadow blocking, as well as capping spikes and maintaing desired ABR This doesn't work with CRF, unfortunately.

maxrate copy.png
 
Last edited:

Danr

Administrator
Staff member
What happens in VRD if you set a tight range for the maxrate and avg rate, do you get similar results? From what I can tell the bufsize is mostly used to determine the number of lookahead frames and doesn't impact the bit rate directly
 

musicvid

Member
What happens in VRD if you set a tight range for the maxrate and avg rate, do you get similar results?
I was just about to mention that, and the answer is YES! It's already achievable in VRD.
From what I can tell the bufsize is mostly used to determine the number of lookahead frames and doesn't impact the bit rate directly
If we set bufsize higher, the control or "tightness" of the bandwidth outliers is looser as you see, because of fewer snapshot updates. "Lookahead" is a reasonable descriptor.
Interesting stuff.
loosebufsize.png
 
Last edited:
Top Bottom