On 3/25/2018 12:56 PM, wm4 wrote: > 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.
That's what i called a minimalist build, and it still builds the entire libavutil library plus a lot of unconditional objects in libavcodec because of pointless public API that used to be avpriv_. And that's what Chromium and such manually get rid of. > > 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
