On Sun, 25 Mar 2018 12:47:41 -0300 James Almer <jamr...@gmail.com> wrote:
> On 3/25/2018 12:19 PM, Nicolas George wrote: > > Michael Niedermayer (2018-03-25): > >> looking at what we have as avprivs, in the tree, i think some of these > >> could be indeed usefull as public APIs. And we need to already keep them > >> compatible as they are exported as avpriv too, so making such changes does > >> indeed in some cases look like a good idea to me > >> > >> There are some avprivs we have currently though that are quite specific > >> to format intgernals, i dont think that its always a flaw to use avpriv > >> functions thus > > > > The reason some functions are avpriv instead of public is quite simple: > > it was considered too much effort to keep them stable enough to make > > them public. > > > > For these cases, we have the ff_ prefix, it works perfectly. But for > > some reason, somebody decided to make several separate libraries for > > this single project. Hence the avpriv prefix, which is exported but not > > public, with functions that are supposed to be... we don't know how > > stable. There is an implicit policy that shared lav* must all have the > > same version, but nothing ensures that technically. > > Most avpriv_ functions exist solely to avoid code duplication. If it's > so much of an issue we could effectively duplicate them all on each > library as required by the different modules. > > > > > The whole mess stems from a huge core flaw: having separate libraries. > > It does not bring any benefit (at least, any benefit that could not be > > achieved otherwise without the drawbacks) and makes everything more > > complicated. > > > > So could we please stop beating around the bush and possibly address the > > actual issue? > > No, because a *lot* of people only want a decoder or two, and don't want > to deal with a lot of non optional filter/device/format/resample/scale > framework they don't need bloating their applications. > Even the most minimalist build today still builds a lot of non optional > stuff in libavcodec that was made public for the purpose of getting rid > of avpriv_ symbols, like all those vorbis and aac header parsing > functions that i doubt anyone or anything outside of libav* ever uses. > > Hell, many downstream projects even add custom changes to remove all the > crap they don't need from libavutil because we still haven't made it a > modular library like the rest. See Chromium stripping everything but > md5, mem, buffer, pixfmt and such core functionality. Could be solved with --disable-everything -.-enable-codec=whatyouwant. In addition we could add a flag to disable entire unneeded sub libraries. E.g. using only a decoder -> disable build of libswscale etc. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
