[FFmpeg-devel] [RFC] avpriv cleanup
george at nsup.org
Sun Mar 25 19:58:27 EEST 2018
James Almer (2018-03-25):
> Most avpriv_ functions exist solely to avoid code duplication. If it's
Most functions exist solely to avoid code duplication. Functions,
unqualified, all of them: static, ff_, etc. The avpriv_ prefix only
exists because of library boundaries.
> so much of an issue we could effectively duplicate them all on each
> library as required by the different modules.
I hope this was a joke.
> 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.
FINALLY! Somebody giving the beginning of actual arguments.
Now we can discuss. Can you tell us more about these many people who
want only a decoder or two? Do they use static linking or dynamic
linking? Do they ship their own lav* or do they use distros?
These are very important questions, because different cases warrant
different responses, and only a few cases are actually relevant for this
> 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.
I think you are missing a very important fact here: all that
non-optional stuff exists precisely because it cannot be made really
internal due to the library boundaries. If the project built into a
single library, then it would be much easier to ensure that
--disable-everything --enable=a,few,things actually builds only the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-devel