[FFmpeg-devel] Status and Plans for Subtitle Filters

[Vittorio Giovara]

On Thu, Feb 27, 2020 at 10:41 AM Hendrik Leppkes <h.leppkes at gmail.com>
wrote:

> On Thu, Feb 27, 2020 at 12:35 PM Anton Khirnov <anton at khirnov.net> wrote:
> >
> > Quoting Hendrik Leppkes (2020-02-27 12:27:09)
> > > On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov <anton at khirnov.net>
> wrote:
> > > > Why does it need to be within AVFrame? I am still unconvinced that
> is a
> > > > good idea. What do we gain from storing them in the same struct?
> > > > It makes sense for audio and video, because they are similar in many
> > > > important aspects (and even then there are people saying that they
> > > > should be separate). Subtitles are even more different.
> > > >
> > >
> > > You gain a unified API, which we already have now, intead of a
> > > secondary API just for subtitles thats practically the same but
> > > accepts different structs.
> > > This makes everything a lot easier imho. You can decode whatever input
> > > data into an AVFrame, you can filter your AVFrame, still without
> > > needing special data paths, and only at the last step after all of
> > > that do you need to possibly care when it comes to output. If you're
> > > encoding again, you might not even have that.
> >
> > AFAIU one of the still-open questions for the subtitle redesign is what
> > does it mean to decode or encode a subtitle. And one of the options is
> > putting the AVPacket->"decoded subtitle" (whatever that is) and "decoded
> > subtitle"->AVPacket conversions into a separate library.
>
>
> FFmpeg really doesn't need *more* libraries.
>

libavio says hi

joking aside, i see nothing wrong in having a bit more granular libraries,
subtitle handling could be a good example usecase.
-- 
Vittorio