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

[Marc Giger]

Hi,

On Wed, 14 Jan 2015 10:49:23 +0100
wm4 <nfxjfg at googlemail.com> wrote:

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

Simply because I don't want to restrict users of what codecs
they have to use (I'm not the iXXX company and don't want to restrict
user wherever I can...). For example if they want use libfaac then
they should be able to do so without that much hassle a full compilation
inclusive all dependencies can be. On Linux/OpenSource OS's things are
easy, on proprietary platforms ...

In a perfect world, the user should be able to just click on the
download button and everything inclusive all codecs are magically
working. But since I don't live in a perfect world (e.g. Patent,
Licensing and License issues) I try to simplify things as much as I can
so that the user gets the best out of the box as possible. And if he
want's more he should be able to add that little piece without building
the whole thing.

I think it's a little bit comparable with the Linux Kernel.
Do you want to recompile the kernel and update the
bootloader everytime you plug-in a new device or need a firmware
update for a device? A good example is the nvidia driver. Because it
is proprietary it means it can't be redistributed with the Linux Kernel.
So when you need it you only need to compile the wrapper code and link
it against your kernel. No whole kernel rebuild needed not even a
reboot (maybe after you loaded the nvidia module ;-) ).

For example, I need about 10 to 15 minutes to compile and install a
new kernel, but it takes me 1 to 2 days to compile my whole project
inclusive ffmpeg and all libs on a windows system. And if I have to
setup the whole compiler toolchain, jdk and all other stuff that I
need it takes even a lot more time. If every user needs to do that just
because he needs codec xyz, good night... So dynamic loading would help
a lot.


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

I chose libva and libmp3lame at random. Yes, it was my intention to do
it for every external lib. If you ffmpeg-devs think that it is an
unnecessary feature and will result in a mess, then I'm absolutely fine
with this decision. All I wanted to know is how welcome such a
contribution is.

And if there is a chance that it will be accepted by you when it is
implemented properly, I'm willing to spend more time on it. Otherwise
we can stop the discussion here and I will use my time for other stuff.

Thanks again for your input!

Marc


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