[Ffmpeg-devel] [BUG] Error: 2pass curve failed to converge

Corey Hickey bugfood-ml
Sat Sep 2 19:39:16 CEST 2006

Loren Merritt wrote:
> On Mon, 17 Jul 2006, Corey Hickey wrote:
>> This bug is a bit elusive; it only happens with some source videos with
>> some parameters, and is not always the same between amd64 and i386. In
>> each case, the second pass fails immediately with the error:
>> [mpeg4 @ 0xc840d0]Error: 2pass curve failed to converge
> The bug turns out to be unrelated to my earlier suggestion.
> Uncomment the printf at ratecontrol.c:908 to see what's going on:
> predicted_size target_size rate_factor
> 23365008.042328 24398207 65536.000000
> 23365008.042328 24398207 98304.000000
> 23365008.042328 24398207 114688.000000
> ...
> So the error message is triggering as intended. It's telling you that it 
> can't spend that many bits subject to lmin=2.
> But pass1 ended up being vqscale=2 at 828 kbit/s, while you're only asking 
> for 817 kbit/s on pass2, and the predicted size for pass2 at vqscale=2 is 
> 782 kbit/s. So the bug is that even if the 2nd pass's quantizer is the 
> same as the 1st pass, it does not predict the size to be exactly what was 
> observed in the 1st pass.

I went back and looked at this again. It looks more simple than I
thought; either that or I'm thinking too simplistically.

When I encode the file in mencoder with default lavc options, the
average video bitrate is 676.373 kbit/s. When I use vqscale=2, the
bitrate is 723.906 kbit/s. So, it appears to me that lavc has no way at
all to reach the requested 817 kbit/s (subject to the minimum quantizer
of 2).

I was under the impression earlier that the problem was lavc incorrectly
 predicting that it couldn't encode at such a high bitrate when in fact
it could. That doesn't seem to be the case.

If that's really what's happening, then it seems changing the error to a
warning would actually be the right course of action. I'm going to go
run some errands and fix cars; when I get back, if nobody has dissuaded
me, I'm going to make a patch (possibly) based on the changes Sven Over


More information about the ffmpeg-devel mailing list