[FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Anton Khirnov
anton at khirnov.net
Mon Mar 11 08:03:15 EET 2024
Quoting Michael Niedermayer (2024-03-11 00:37:07)
> > > >>> 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.
>
> iam not sugesting to add API specific to mpeg4, rather that maybe
> it can be done as part of some more generic solution
What kind of a solution? As I said above, I don't know of any other
encoders that have similar constraints.
--
Anton Khirnov
More information about the ffmpeg-devel
mailing list