[FFmpeg-devel] [RFC] Support dynamic loading of third-party libs

[wm4]

On Tue, 13 Jan 2015 19:45:01 +0100
Marc Giger <gigerstyle at gmx.ch> wrote:

> Hi,
> 
> On Tue, 13 Jan 2015 14:54:33 +0100
> wm4 <nfxjfg at googlemail.com> wrote:
> 
> > On Mon, 12 Jan 2015 18:59:33 +0100
> > Marc Giger <gigerstyle at gmx.ch> wrote:
> > 
> > > Hi,
> > > 
> > > Attached is a preliminary patch that enables runtime loading of
> > > external libraries via dlopen and friends. Dynamic loading is a
> > > build time option (--enable-dynamic-loading) and if it is not
> > > activated the libs are linked as usual (still no dependency to
> > > dlopen required).
> > > 
> > > The patch is intended as a basis for a discussion and therefore the
> > > following applies:
> > > 
> > > - only libmp3lame and libva will by dynamically loaded atm
> > > - only tested on linux atm
> > > - deregistering not implemented (dlclose)
> > > - versioning (which version of a lib should be loaded?)
> > > - library usage counter missing
> > > - ...?
> > > 
> > > What do you think?
> > 
> > What's the point?
> > 
> > Linux distros link everything anyway, they don't need to care.
> 
> Gigix is not released yet ;-) and therefore I don't build a Linux
> distro myself but do still have interest in this feature...
> 
> > 
> > Other projects (distributing executables on windows etc.) restrict
> > themselves to what they need anyway.
> 
> That's my category and still have a demand for it...

OK, but for what reason exactly?

> > 
> > It also adds more global mutable state, which is not nice IMHO,
> > although that's an implementation detail as used in your patch. A
> 
> I'm open for better solutions. Please advice.
> 
> > library usage counter is maintained by dlopen/dlclose already, by the
> > way.
> 
> Yep, I'm aware of it. But look for example at the vaapi code then you
> will notice that the code is shared between multiple vaapi hwaccel's.
> If a deregister_hwaccel function will be implemented (makes most
> probably sense to be able to release the loaded lib) we need to take
> care that the function pointers are still valid as long as hwaccels
> are registered that uses the vaapi code. My intention was to memset to
> zero the function pointer struct when deregistering to prevent
> undeterministic behavior. Maybe a bad idea?

You have two choices: 1. use a global table, and protect it with a
mutex, plus your own usage counter if you want to use dlclose(), or 2.
store the function table in each codec context (or whereever it's
used), no need for a mutex or refcounting then.

But still I wonder what's the purpose of this. libva and libmp3lame are
not that big, and the mess resulting from having to duplicate much of
the libs' headers makes maintenance harder. Is this going to be done
for all external libs? Even a bigger mess.