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

[Anton Khirnov]

Quoting Martin Storsjö (2024-03-11 13:29:15)
> On Mon, 11 Mar 2024, Anton Khirnov wrote:
> 
> > Quoting Tobias Rapp (2024-03-11 11:12:38)
> >> On 10/03/2024 23:49, Anton Khirnov wrote:
> >>
> >>> Quoting James Almer (2024-03-10 23:29:27)
> >>>> On 3/10/2024 7:24 PM, Anton Khirnov wrote:
> >>>>> Quoting Michael Niedermayer (2024-03-10 20:21:47)
> >>>>>> On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote:
> >>>>>>> Quoting Michael Niedermayer (2024-03-10 04:36:29)
> >>>>>>>> why not automatically choose a supported timebase ?
> >>>>>>>> "[mpeg4 @ 0x55973c869f00] timebase 1/1000000 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535"
> >>>>>>> Because I don't want ffmpeg CLI to have codec-specific code for a codec
> >>>>>>> that's been obsolete for 15+ years. One could also potentially do it
> >>>>>>> inside the encoder itself, but it is nontrivial since the computations
> >>>>>>> are spread across a number of places in mpeg4videoenc.c and
> >>>>>>> mpegvideo_enc.c. And again, it seems like a waste of time - there is no
> >>>>>>> reason to encode mpeg4 today.
> >>>>>> This is not mpeg4 specific, its just a new additional case that fails
> >>>>> The case you reported is mpeg4 specific.
> >>>>>
> >>>>>> ./ffmpeg -i mm-small.mpg test.dv
> >>>>>> [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are:
> >>>>> There is no mechanism for an encoder to export supported time bases.
> >>>> Could it be added as an extension to AVProfile, or AVCodec?
> >>> The two cases are actually pretty different:
> >>> * mpeg4 has a constraint on the range of timebases, and actually does
> >>>    some perverted computations with the timestamps
> >>> * DV just needs your video to be CFR, with a list of supported
> >>>    framerates; dvenc should probably read AVCodecContext.framerate
> >>>    instead of time_base
> >>>
> >>> But most importantly, is there an actual current use case for either of
> >>> those encoders? They have both been obsolete for close to two decades.
> >>> It seems silly to add new API that won't actually be useful to anyone.
> >>
> >> Hardware doesn't get outdated as quickly as software. And there are
> >> people that do not switch their full environment to a new codec every
> >> decade just to be "in line".
> >
> > And your point is...?
> 
> 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.

> That said, I haven't followed the discussion closely enough about what to 
> do with the time bases.

The only change is that in some rare cases the automatically selected
timebase no longer fits into mpeg4 constraints, so the user has to
specify either the framerate or the timebase explicitly.

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.

-- 
Anton Khirnov