[FFmpeg-devel] [RFC] avpriv cleanup

[James Almer]

On 3/25/2018 12:56 PM, wm4 wrote:
> 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.

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.