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 discussion. > 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 necessary. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
