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

[Tobias Rapp]

On 11/03/2024 14:28, Anton Khirnov wrote:

> 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.
>
> [...]


If this is just about having to add some extra parametersin rare 
use-cases then its fine. I got the impression that encoding into MPEG4 
or DV was considered deprecated (or unimportant of additional 
consideration) in general.

Regards, Tobias