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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".