[FFmpeg-devel] [PATCH v16 08/16] fftools/ffmpeg: Replace sub2video with subtitle frame filtering

Soft Works softworkz at hotmail.com
Sat Nov 27 11:36:28 EET 2021



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Andreas
> Rheinhardt
> Sent: Saturday, November 27, 2021 10:29 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v16 08/16] fftools/ffmpeg: Replace
> sub2video with subtitle frame filtering
> 
> Soft Works:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Anton
> >> Khirnov
> >> Sent: Saturday, November 27, 2021 10:04 AM
> >> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH v16 08/16] fftools/ffmpeg: Replace
> >> sub2video with subtitle frame filtering
> >>
> >> Quoting Soft Works (2021-11-27 08:18:37)
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Andreas
> >>>> Rheinhardt
> >>>> Sent: Friday, November 26, 2021 2:02 PM
> >>>> To: ffmpeg-devel at ffmpeg.org
> >>>> Subject: Re: [FFmpeg-devel] [PATCH v16 08/16] fftools/ffmpeg: Replace
> >>>> sub2video with subtitle frame filtering
> >>>
> >>>> Furthermore, missing check.
> >>>> (Maybe ass subtitle based codecs should set AVCodecContext.width and
> >>>> height based upon this play_res_x/y?
> >>>
> >>> Breaks the decoder API.
> >>
> >> Why? I'd think width/height are currently unused for subtitles, so you
> >> can repurpose them without breaking anything.
> >
> > It breaks the API because every decoder would be required to do this, and
> > would need to be changed.
> >
> 
> 1. If by "every decoder" you mean every decoder in lavc, then this does
> not mean that this would be an API break; it just means that it would be
> more work.
> 2. Why would "every decoder" need to be changed? We do not need to
> promise to set these fields all the time; we should not even set these
> fields all the time, but only if there is really something meaningful to
> report (e.g. I don't consider this default value (where does this number
> even come from?) meaningful).

It's a moot discussion anyway. Anton's idea was to do this to get right
of the avpriv_ass... functions, as he had seen that it's mostly used to get
the PlayResX/Y values. But it won't work out. Those functions are needed, 
because ASS is the internal text subtitle format. Filters read and manipulate
that ass data => those functions are needed outside of libavcodec.

softworkz





More information about the ffmpeg-devel mailing list