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