[FFmpeg-devel] [RFC] avpriv cleanup

wm4 nfxjfg at googlemail.com
Sun Mar 25 18:56:58 EEST 2018

On Sun, 25 Mar 2018 12:47:41 -0300
James Almer <jamrial at 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.

More information about the ffmpeg-devel mailing list