Qcomp, in a quite literal sense,
is a form of Bitrate Variability--actually, it was simply renamed in the VFW and multiplied by 100 for integer simplicity.
The "ratetol" parameter, as you mentioned, controls the amount of bitrate explicitly awarded to the video, in turn effecting the quantizers used on it. It does so as part of a
bitrate regulation -- to ensure that the content reaches a certain bitrate without fluxuation.
Quote:
Originally Posted by hitbit
raising ratetol allows greater fluctuations in bitrate (thus it would be more similar to 2-pass) at the expense of precision in aiming the target bitrate
|
It therefore defaults to a 1, a low value, in order to more accurately hit a given bitrate in ABR (1-pass variable bitrate) mode.
For this "fluxuation insurance," high-motion scenes would obviously require a higher quantizer than do still scenes in order to maintain a certain steady bitrate. However,
qcomp directly controls these quantizers (A quantizer curve compression, or
quantizer regulation), which in turn impacts the bitrate, serving either to give it absolute stability (0) or allow infinite fluxuation (1) based on what quantizers are used on each frame in the video.
Control diagram:
<> qcomp -> quantizers -> bitrate variability
<> ratetol -> bitrate variability -> quantizers
Quote:
Originally Posted by TheBashar
I think ratetol is an additional constraint on how much you allow qcomp to do its job.
|
Yes, I would assume so.
It is therefore safe to assume that with Qcomp in play, ratetol serves as a sort of "peak cutoff," allowing the video to conform to the quantizer specifications in qcomp so long as they don't exceed the bounds specified in ratetol. Yes, ratetol would be an excellent parameter to set when encoding streaming content (if using the cli, of course), because of these solid bounds.
Their purposes seem to check and balance one another and provide more explicit control.