[FFmpeg-devel] Status and Plans for Subtitle Filters

Nicolas George george at nsup.org
Fri Feb 28 13:58:40 EET 2020


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".

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

> - 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.

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

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200228/a5290149/attachment.sig>


More information about the ffmpeg-devel mailing list