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

Marc Giger gigerstyle at gmx.ch
Tue Jan 13 19:45:01 CET 2015


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

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

Many thanks for your feedback!

Marc



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




More information about the ffmpeg-devel mailing list