Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase - Martin Storsjö via ffmpeg-devel

From: "Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>,
	 FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>
Cc: "Martin Storsjö" <martin@martin.st>
Subject: Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Date: Mon, 11 Mar 2024 16:03:15 +0200 (EET)
Message-ID: <9140cb3e-af72-8a9a-c4-366bf7ae27a0@martin.st> (raw)
In-Reply-To: <171016369568.662.8737080358093163641@lain.khirnov.net>

On Mon, 11 Mar 2024, Anton Khirnov wrote:

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

Ok, good. The generally dismissive arguments about mpeg4 encoding being 
obsolete and something that nobody should be doing, could be interpreted 
in such a way.

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

Right, I see.

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

Right, I would agree with this. (If someone else would volunteer to add 
said API I would consider accepting it though.)

Is this a usecase that currently works, but would be go away by getting 
rid of codec specific code in the tools, or is it a nice-to-have new extra 
feature that is being requested?

// Martin

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".