[FFmpeg-devel] Status and Plans for Subtitle Filters

[Vittorio Giovara]

On Fri, Feb 28, 2020 at 6:58 AM Nicolas George <george at nsup.org> wrote:

> Anton Khirnov (12020-02-28):
> > avpriv is not a necessary result of having multiple libraries. It is a
> > bug caused by bad API design. There is no fundamental reason for having
> > private interfaces.
> >
> > In my view, no new private interfaces should be accepted and all of the
> > existing ones should be gradually removed.
>
> It's a nice view to hold in theory, it's another thing to apply it when
> in front of an actual issue. You should realize how disparaging an
> offhand comment like that can be of other people's efforts.
>
> > I can give you several:
> > - it allows callers to use a subset of functionality without depending
> >   on a giant monsterlibrary; you don't want to depend on the entire
> >   libavcodec if you just want to resample; you don't want to depend on
> >   the entire libavformat if you just want some handy IO wrappers
>
> There are many ways to "depend": static linking, dynamic linking, using
> system libraries, shipping the source code, etc. Each of these way offer
> better solutions to avoid unnecessary "monsterlibrary".
>

err a monsterlibrary is a monsterlibrary regardless of how it is linked,
and it's good that you mention static linking since that would be one of
the best reason to keep library separated


> Also, I suspect very few projects use the FFmpeg libraries without
> libavcodec itself.
>

err^2 wouldn't we want to change that? There are plenty of good APIs that
could be used in the wild, but aren't because ffmpeg is a huge dependency
in any project.


> > - related to the previous points, it would allow us to use that
> >   functionality more easily internally without having everything depend
> >   on everything; people already do IO in libavcodec, but they can't use
> >   avio for it; if the libraries were split - they could
>
> If the libraries were merged, we could too. Splitting the libraries is
> only a mediocre proxy for good code organization.
>
> > - having our interfaces public forces us to make them more strict and
> >   explicit and generally be more careful about their design; that is
> >   generally a good thing - lavc and lavf would greatly benefit from
> >   having more internal structure
>
> Again, splitting the libraries is not necessary to have better code
> organization.
>

There are plenty of example in which imposing constraints on the code or
language forces developers to write better code.
For example splitting the libraries would make sure that a private header
does not "leak" to a dependent library, like in a patch that was published
a few days ago.

Let me be clear: the organization in thematic sub-directories is fine.
> The terrible waste is to produce separate dynamic objects at the end.
>

Hard disagree on that one, but also quite off-topic, let's get back on
subtitles.
-- 
Vittorio