[FFmpeg-devel] [RFC] avpriv cleanup

[James Almer]

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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>