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

[Corey Hickey]

Loren Merritt wrote:
> 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;

Ahh. I get your meaning, I think. I changed my patch to use your
suggestion, with the modification that I divide rcc->entry[i] by
FF_QP2LAMBDA before clipping it.

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

Yes, the result seems somewhat low; for instance, it reports 2.something
when the eventual average qp is 4.something (unless I did something wrong).

If it's not feasible to calculate at this point, I'm not averse to
dropping that part of my patch. I only tried it because Michael
mentioned it, but it's not required.

>>>> 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

Thanks.

> 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.

Hmm. I'll refer back to this when I get to that point. Thanks again.

-Corey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bitrate_check4.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060904/5e8c6aa8/attachment.asc>