[FFmpeg-devel] Status and Plans for Subtitle Filters
Anton Khirnov
anton at khirnov.net
Fri Feb 28 07:38:42 EET 2020
Quoting Nicolas George (2020-02-27 19:44:39)
> Vittorio Giovara (12020-02-27):
> > joking aside, i see nothing wrong in having a bit more granular libraries,
> > subtitle handling could be a good example usecase.
>
> Seriously?
>
> $ git grep avpriv | wc -l
> 1648
>
> This is how much "nothing wrong" we already have because the libraries
> are split. And having to maintain ABI stability for private APIs is only
> one cause of problems among others.
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.
>
> On the other side, would you be able to quote only one actual, practical
> benefit of having several libraries instead of one that could not be
> achieved more simply with configure options? I suspect not, because I
> have looked for them and not found.
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
- 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
- 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
--
Anton Khirnov
More information about the ffmpeg-devel
mailing list