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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".