[FFmpeg-devel] [PATCH] Fix ratecontrol bug when time_base.num > 1
joseph at mirriad.com
Fri Nov 16 15:34:54 CET 2012
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
>> 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);
>> - 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
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.
Senior C++ Applications Developer
More information about the ffmpeg-devel