[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