[FFmpeg-devel] Status and Plans for Subtitle Filters

[Hendrik Leppkes]

On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov <anton at khirnov.net> wrote:
>
> Quoting Clément Bœsch (2020-02-25 18:40:13)
> > On Sun, Feb 23, 2020 at 09:59:59PM +0100, Michael Niedermayer wrote:
> > [...]
> > > > The subtitles refactor requires to see the big picture and all the problems at
> > > > once.
> > >
> > > really ?
> > > just hypothetically, and playing the devils advocat here.
> > > what would happen if one problem or set of problems is solved at a time ?
> >
> > The first requirement of everything following is to define a new
> > structure/API for holding the subtitles within the AVFrame (which has to
> > live in lavu and not lavc like current API). So you have to address all
> > the current limitations in that new API first, unless you're ready to
> > change that new API 10x in the near future. And even if you keep most of
> > the current design, you still have to at least come up with ways to remove
> > all the current hacks that would go away while moving to the new design.
>
> 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.

- Hendrik

- Hendrik