"CRF-max" support with VBV
authorJason Garrett-Glaser <darkshikari@gmail.com>
Fri, 19 Mar 2010 21:44:10 +0000 (14:44 -0700)
committerJason Garrett-Glaser <darkshikari@gmail.com>
Sat, 27 Mar 2010 19:47:03 +0000 (12:47 -0700)
commit81eee062a4ce9aae1eceb3befcae855c25e5ec52
tree664e6a2594184b30782733774b24f017c7259271
parentc6de86497cdd7b7f3cce7d8a95d723c7d0c9f505
"CRF-max" support with VBV
This is a rather curious feature that may have more use than is initially obvious.
In CRF mode with VBV enabled, CRF-max allows the user to specify a quality level which the encoder will never go below, even due to the effects of VBV.
This is not the same as qpmax, which is not aware of issues like scene complexity.
Setting this WILL cause VBV underflows in any situation where the encoder would have needed to exceed the relevant CRF to avoid underflow.

Why might one want to do this even if it would cause VBV underflows?
In the case of streaming, particularly ultra-low-latency streaming, it may be preferable to drop frames than to display frames that are of too low a quality.
Thus, in extremely complex scenes, rather than display completely awful video, the streaming server could simply drop to a lower framerate.
Scenecuts, which normally look terrible under situations like single-frame VBV, could be handled by just displaying them a bit later and dropping frames to compensate.
In other words, it's better to see the scenecut 150ms delayed than for it to look like a blocky mess for 150ms.

On the caller-side, this would be handled by detecting the output size of x264's frames and dropping future frames to compensate if necessary.

This can also be used in normal encoding simply to ensure that VBV does not hurt quality too much (at the cost of potentially causing underflows).
This can help quite a lot when using single-frame VBV and sliced threads, where VBV can often be somewhat unstable.
common/common.c
encoder/encoder.c
encoder/ratecontrol.c
x264.c
x264.h