On Fri, Feb 28, 2020 at 6:58 AM Nicolas George <geo...@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 _______________________________________________ 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".
