[Ffmpeg-devel] [PATCH] fix (?) 2pass convergence errors

[Loren Merritt]

On Mon, 4 Sep 2006, Michael Niedermayer wrote:
> On Mon, Sep 04, 2006 at 12:35:21PM -0700, Corey Hickey wrote:
>>
>> I haven't figured out how to get the average qp. The attached code
>> * sums up rce->qscale for each rcc->entry[i]
>> * divides the result by rcc->num_entries and then by FF_QP2LAMBDA
>> * does the same thing for rce->new_qscale
>> * prints out both the results
>>
>> According to several tests, the average of qscale more or less matches
>> the average qp of the first pass and the average of new_qscale sort of
>> matches the average qp of the second pass. Both of them get thrown off
>> when lmin is below qmin. Is there a better way? I understand
>> approximately 5% of the ratecontrol code so far, so I'm probably
>> overlooking something easy.

for(...)
     qp_sum += clip(rcc->entry[i].new_qscale, qmin, qmax);
qp_sum /= num_entries * FF_QP2LAMBDA;

This is still not perfect, because having lambda<qp does increase bitrate 
a little.

>>> PS: the step_mult stuff from x264 ratecontrol.c should be ported assuming
>>> they (loren?) doesnt mind relicensing the few related lines under LGPL of
>>> course ...

sure

>> I hadn't realized how similar the two ratecontrol.c files were. :) Are
>> you talking about simply:
>>
>> 1. add this calculation:
>> step_mult = all_available_bits / expected_bits;
>>
>> 2. Use this for the corresponding loop control:
>> for(step = 1E4 * step_mult; step > 1E-7 * step_mult; step *= 0.5){
>>
>> 3. alter the if(toobig==40) you recommended because the for() will loop
>> a different number of times.
>>
>> Would I have to change anything else?
>
> yes, the (1pass qscale) expected_bits calculation, in x264 its:
>
>    expected_bits = 1;
>    for(i=0; i<rcc->num_entries; i++)
>        expected_bits += qscale2bits(&rcc->entry[i], get_qscale(h, &rcc->entry[i], 1.0, i));
>    step_mult = all_available_bits / expected_bits;

Note that x264's qscale2bits includes all contributions to a frame's size, 
whereas lavc's qp2bits is only the texture component and expects the 
caller to add the mv and header bits.

btw, the approximation that mv bits are independent of qp could also be 
improved. But you can't just take that from x264, since the heuristic 
would differ between h264 and mpeg4.

--Loren Merritt