[FFmpeg-devel] A change in r_frame_rate values after upgrade to FFmpeg 6.1

Anton Khirnov anton at khirnov.net
Mon Sep 23 22:56:52 EEST 2024


Quoting Kieran Kunhya via ffmpeg-devel (2024-09-23 21:30:09)
> > On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel <ffmpeg-devel at ffmpeg.org> wrote:
> >>
> >> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov <anton at khirnov.net> wrote:
> >> >
> >> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
> >> > > I understand that the r_frame_rate is the lowest framerate with which
> >> > > all timestamps can be represented accurately. And I know it is just a
> >> > > guess. But why did the logic behind the calculation change?
> >> >
> >> > Because you're most likely using a codec like H.264 or MPEG-2 that
> >> > allows individually coded fields. In that case the timebase must be
> >> > accurate enough to represent the field rate (i.e. double the frame
> >> > rate), but the code doing this was previously unreliable, so you'd
> >> > sometimes get r_frame_rate equal to the frame rate rather than field
> >> > rate. That is not the case anymore.
> >>
> >> This is bizarre and kafkaesque to say the least.
> >
> >
> > Should we schedule deprecation for one of the two fields? I agree it's confusing for end users to check in two fields.
> 
> avg_frame_rate implies it's not precise in some way.

You might have heard of certain cases where inter-frame intervals are
not constant, then there is no precisely defined frame rate. When the
stream is CFR, avg_frame_rate should be precise.

> I think the OP is correct here that the behaviour makes no sense. If
> something says frame_rate it's the rate of frames, not the rate of
> fields or anything else.

As I said previously in this thread, r_frame_rate is NOT a frame rate.
Yes, it is horribly named. It is also unknowable without analysing the
entire stream, and of (to put it very mildly) extremely questionable
utility, which is why I've argued for removing it since forever. But
this is how it has always worked. The only thing that's changed is that
now its behaviour is consistent across different files.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list