[FFmpeg-devel] [RFC] avpriv cleanup

[James Almer]

On 3/25/2018 1:58 PM, Nicolas George wrote:
> 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.

Considering most are pretty small but not small enough to be dumped into
a header, no, I'm not joking.
Maybe avpriv_dnxhd_get_frame_size() should stay as is since it requires
a huge table and duplicating it would be a waste of space, but
avpriv_dca_convert_bitstream() seems simple enough that i don't see the
benefits from having it like this, when it could be in both avcodec and
avformat and weight maybe 1kb on each of them.

> 
>> 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?

If they used distro packages then they wouldn't have any power over what
gets built or shipped. Distro packages are the "Enable everything" kind
of build, so I'm of course talking about projects shipping their own
builds of the libraries.

Steam, Foobar2000, Firefox, Chromium, only four examples of projects
where the av*.dll files they ship have long configure lines where they
manually disable all kinds of things beyond the standard
"--disable-everything --enable-decoder=foo" use case, including entire
libraries and frameworks, because they only need a handful of software
decoders.
And Chromium as I said even goes the extra mile by manually striping
libavutil of virtually everything except the core modules, something our
build system currently doesn't support.

Ronald i remember some time ago tried to remove a bunch of unnecessary
objects from libavutil in a minimalist build because he didn't need 1kb
of binary code for a duplicate asm function that would never see any
use. He also wondered why his VP9-only build of libavcodec needed to
compile Vorbis related objects.

Building a single monolithic library will force the presence of a lot of
public symbols that currently can be avoided by simply building ffmpeg
for one decoder and effectively require just avcodec and avutil.
The direction we should head towards is making the libraries even more
modular and independent, starting with libavutil.

> 
> 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.

Not the core framework and public API for each library. Those are
unconditional and would remain so in a monolithic library, but with the
added drawback that instead of only needing those from avcodec/avutil in
a single decoder build, you'd be forced to also compile and ship those
from avfilter/swscale/swresample/avdevice.

> 
> Regards,
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>