Reducing QComp

[simple_simon]

Every time I see someone suggesting settings they almost always raise qcomp from the default of 0.6. However lowering qcomp to 0.4 seems to increase compression significantly at same CRF level with minimal visual degradation. Are there any downsides to doing this?

[LoRd_MuldeR]

The basic idea of the quantizer curve compression algorithm is to raise the quantizers in "complex" frames, compared to simple constant quantizer mode, so that those "complex" frames won't occupy an excessive amount of bits. The bits that are "saved" in the more complex (fast) frames, at the cost of a relatively small quality loss there, can then better be used in the less complex (slow) frames, in order to improve the quality there.

By default, the bit allocation for the frames is controlled by the formula complexity ** 0.6, where "complexity" is the bit size of the frame at a constant quantizer, and 0.6 is the default "qcomp" parameter. In 2-Pass mode this will additionally be scaled by a so-called "rate factor", which is constantly adjusted, so that the target file size (average bitrate) will be hit. In CRF mode, everything is the essentially the same, except that the "rate factor" is a constant.

Consequently, if you adjust the "qcomp" parameter to a larger value, then you are weakening the effect of quantizer curve compression, effectively making the result more like pure constant quantizer mode. Conversely, if you adjust the "qcomp" parameter to a smaller value, then you are strengthening the effect of quantizer curve compression, effectively making the result more like pure constant bitrate mode.

Note that the whole purpose of quantizer curve compression is to improve the overall visual quality, at a certain file size (average bitrate), not to alter the file size (average bitrate). That you may end up witth a different file size (average bitrate) when changing the "qcomp" parameter, while using CRF mode with the same CRF value, is merely a "side effect" of how quantizer curve compression and CRF mode play together, I suppose...

Warning: All of the above only very roughly applies to contemporary x264, because... MB-Tree ;)

Source:
https://code.videolan.org/videolan/x264/-/raw/master/doc/ratecontrol.txt
https://huyunf.github.io/blogs/2017/12/06/x264_slice_type_decision/MBtree%20paper.pdf
________

Also, comparing files of different size (average bitrate) and different quality will not give you any insights! You either have to compare the size of files that have the same visual quality, or you have to compare the visual quality of files that have the same size (average bitrate). Because "same visual quality" is extremely difficult to establish, you are probably better off using the second method (i.e. visually compare files that have the same size).

Now, it is not much of a surprise that lowering the "qcomp" parameter results in a smaller file, in CRF mode, at the same CRF value, but you could have achieved that, just as well, by sticking with the default "qcomp" value and simply using a somewhat higher CRF value! You won't know which way is better, until you have assessed them both, by visually comparing files of the same size (average bitrate) :p

My preference is to pick the slowest "--preset" that you can afford, pick the suitable "--tune" for your kind of source, leave "qcomp" at default, and then simply adjust the CRF value to balance the quality/filesize trade-off as desired...