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

Anton Khirnov anton at khirnov.net
Mon Mar 11 14:23:52 EET 2024


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...?

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list