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-requ...@ffmpeg.org with subject "unsubscribe".
