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

Michael Niedermayer michaelni at gmx.at
Fri Nov 16 17:44:01 CET 2012


On Fri, Nov 16, 2012 at 04:24:30PM +0000, Joseph Artsimovich wrote:
> On 16/11/2012 16:11, Michael Niedermayer wrote:
> >On Fri, Nov 16, 2012 at 04:01:26PM +0000, Joseph Artsimovich wrote:
> >>On 16/11/2012 15:28, Kieran Kunhya wrote:
> >>>>I dont fully understand the problem, so its hard to suggest how to
> >>>>fix it.
> >>>The problem is his application doesn't like the timebase as a reduced
> >>>fraction, but would rather
> >>>have it as a reducible fraction.
> >>>
> >>Not quite. That's only part of the problem. The following line of
> >>code from ratecontrol.c:
> >>
> >>wanted_bits = (uint64_t)(s->bit_rate*(double)dts_pic->f.pts / fps);
> >>
> >>won't work correctly for any time_base where numerator is greater
> >>than 1, as it doesn't consider the scale of dts_pic. For instance,
> >>it will fail on your typical NTSC timing of 1001/30000. Now, the
> >>obvious fix is to include s->avctx->time_base.num into the
> >>denominator of the above line of code. That would fix the NTSC case,
> >>but not my case, which was 24/600, as s->avctx->time_base gets
> >>automatically reduced to 1/25. Therefore, I went with s->dts_delta
> >>instead of s->avctx->time_base.num. However, Michael explained it's
> >>not suited for that purpose.
> >fps is calculated as 1.0 / av_q2d(avctx->time_base) / FFMAX(avctx->ticks_per_frame, 1);
> >that is supposed to take the numerator already into account.
> >
> >also 24/600 or 1/25 the timestamps should be 1,2,3,4,...
> Note that we are talking about user-provided timestamps. I use
> libavcodec indirectly through libquicktime, which in my case sets:

> avctx->time_base.num = 24;
> avctx>time_base.denum = 600;
> avframe->pts = 0, 24, 48, ...

    /**
     * presentation timestamp in time_base units (time when frame should be shown to user)
     * If AV_NOPTS_VALUE then frame_rate = 1/time_base will be assumed.
     * - encoding: MUST be set by user.
     * - decoding: Set by libavcodec.
     */
    int64_t pts;

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121116/a1be87fb/attachment.asc>


More information about the ffmpeg-devel mailing list