[FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase

[Anton Khirnov]

Quoting Martin Storsjö via ffmpeg-devel (2024-03-11 15:03:15)
> On Mon, 11 Mar 2024, Anton Khirnov wrote:
> 
> >> I think the point is, that one can't just dismiss that anybody would want 
> >> to encode mpeg4 video any longer, even if it is obsolete. I also would 
> >> like to keep being able to do that.
> >
> > That capability is not going away though, and I'm not arguing that it
> > should.
> 
> Ok, good. The generally dismissive arguments about mpeg4 encoding being 
> obsolete and something that nobody should be doing, could be interpreted 
> in such a way.

Well it IS obsolete. AFAIK it was never a particularly popular codec,
and was only really used by the anime and ripping scenes in early 2000s,
and even they dropped it very quickly once x264 appeared. While hardware
"divx players" did exist, I don't think they'd still be used today in
nontrivial numbers. So I don't see any reason to encode it today,
besides testing and academic/historic interest. And again - that does
not mean the capability should be removed, but it does mean that we
shouldn't insist on tuning it for the smoothest user experience, since
this time is then NOT spent doing something actually useful.

> > Specifically, the commandline used by Michael involves the extremely
> > obscure case of converting subtitles to video (NOT harsubbing, but
> > really 1 sub -> 1 video). Since subtitle encoding API is hardcoded to
> > AV_TIME_BASE_Q, that timebase gets used for encoding, and the mpeg4
> > encoder rejects it. If it was hardsubbing (i.e. 1 video + 1 sub -> 1
> > video), the input video timebase should be used, which would probably
> > work.
> >
> > I don't think it's that big of a deal to require users to specify the
> > timebase or framerate explicitly in such a sitation.
> > Inventing new APIs to cover it automagically seems like a waste of time,
> > unless somebody has actual (not potential) uses for this.
> 
> Right, I would agree with this. (If someone else would volunteer to add 
> said API I would consider accepting it though.)
> 
> Is this a usecase that currently works, but would be go away by getting 
> rid of codec specific code in the tools, or is it a nice-to-have new extra 
> feature that is being requested?

The patch is not removing codec-specific code, rather it is changing the
filtering timebase from the demuxer one to the decoder one (which is
needed in this set to avoid the assumption that a filter is necessarily
fed by a demuxer). The two should be the same in most cases, except
* sub2video, where the subtitle decoding API fixes the timebase to
  AV_TIME_BASE_Q
* there is a post-demuxing bsf that changes the timebase, such as setts

-- 
Anton Khirnov