[FFmpeg-devel] [PATCH] Fix ratecontrol bug when time_base.num > 1

[Joseph Artsimovich]

On 16/11/2012 13:59, Michael Niedermayer wrote:
> On Fri, Nov 16, 2012 at 12:01:11PM +0000, Joseph Artsimovich wrote:
>> When encoding long-GOP MPEG2 with time_base of 24/600 (with reduces
>> to 1/25, but I need it for compatibility with some proprietary
>> software) I noticed blow up of encoded frame size and "rc buffer
>> underflow" errors. I traced it back to the following line in
>> ratecontrol.c:
>>
>> wanted_bits = (uint64_t)(s->bit_rate*(double)dts_pic->f.pts / fps);
>>
>> which doesn't take pts units into account.
>> A patch is attached.
> [...]
>> @@ -708,7 +708,7 @@ float ff_rate_estimate_qscale(MpegEncContext *s, int dry_run)
>>           if (!dts_pic || dts_pic->f.pts == AV_NOPTS_VALUE)
>>               wanted_bits= (uint64_t)(s->bit_rate*(double)picture_number/fps);
>>           else
>> -            wanted_bits = (uint64_t)(s->bit_rate*(double)dts_pic->f.pts / fps);
>> +            wanted_bits = (uint64_t)(s->bit_rate*(double)dts_pic->f.pts / (fps*(double)s->dts_delta));
>>       }
> dts_delta is only set in some cases and only based
> on the first frames.
> The durations of later frames can be entirely different from the
> first frames.
>
What's the proper way of doing it then? I initially tried to use 
s->avctx->time_base.num, but found that my 24/600 time_base was reduced 
to 1/25.
Because the proprietary software I am trying to be compatible with only 
cares about timing ratio in QuickTime headers and (hopefully) not in 
MPEG stream, I could resort to patching libquicktime to take that 
reduction into account, but that would be working around the problem 
rather than fixing it.

-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd