[FFmpeg-devel] Is rate control/frame rate tied to AVCodecContext.time_base?

Robert Krüger krueger at lesspain.software
Fri Jul 13 14:36:30 EEST 2018


Hi,

I recently changed code that uses libavcodec for encoding to use timebases
with a higher granularity because there were cases where certain
conversions resulted in timestamp clashes which I could fix that way.

Now I realized that this totally screwed up rate control, e.g. for
mpeg2video. Bitrate is down by a large factor and I get lots of messages
like these

rc buffer underflow
max bitrate possibly too small or try trellis with large lmax or increase
qmax

when everything I changed was merely the time_base of the encoder. All
other settings, which have worked fine for ages, identical.

I doublechecked if all timestamps and durations we pass the encoder are
correct and they seem consistent, e.g. in a case where earlier we would
pass an AVFrame with a PTS of 1 and a duration of 1 for a codec timebase of
1/25 we were now passing 1000 and a duration of 1000 for a timebase of
1/25000.

Is rate control somehow assuming that timebase is anything but just the
maximum granularity of timestamps, which my understanding was before?

Looking at the code in ratecontrol.c I see for example this:

static double get_fps(AVCodecContext *avctx)
{
    return 1.0 / av_q2d(avctx->time_base) / FFMAX(avctx->ticks_per_frame,
1);
}

Which at least seems like there are assumptions regarding time_base and its
relationship with fps.

I know the documentation says this for AVCodecContext.time_base:

"This is the fundamental unit of time (in seconds) in terms of which frame
timestamps are represented.

For fixed-fps content, timebase should be 1/framerate and timestamp
increments should be identically 1. "

But in usual spec language "should" does not mean must. My question is
really, does it have to be set this way or otherwise rate control is
broken? I was assuming the encoder could work with anything provided the
timestamps and durations I pass in are correct.

Thanks in advance for any insights in this,

Robert


More information about the ffmpeg-devel mailing list