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. > > Regards, > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
