[FFmpeg-devel] [PATCH] Dynamic plugins loading

Stefano Sabatini stefano.sabatini-lala
Mon Nov 1 15:30:19 CET 2010

On date Monday 2010-11-01 13:46:35 +0100, Michael Niedermayer encoded:
> On Sun, Oct 31, 2010 at 08:52:52PM -0400, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Sun, Oct 31, 2010 at 9:42 AM, Nicolas George
> > <nicolas.george at normalesup.org> wrote:
> > > There is probably much to discuss, but at the very least, it works to simply
> > > add support for a new format in lavf by just dropping a file in a directory.
> > > Codecs and filters should work just the same.
> > 
> > Let's just go over the big phat elephant in the room. Is this an advantage?
> i was starting to be scared and surprised that noone was bringing the "why"
> up already.
> > 
> > I used to think this kind of stuff was good. But is there really an
> > advantage to all this? I can think of disadvantages:
> > - no strong license enforcement because you can separate shipping of
> > software pieces that have strictly incompatible licenses
> > - security becomes worthless, any plugin can exploit a system
> > - stability becomes a nightmare as soon as you start thinking about
> > possibly updating ABI/API
> > - dynamic plugins won't share code with the main source tree, which
> > means that the best point of FFmpeg - fast and lean - no longer
> > applies
> > - companies can suddenly get away with releasing a binary plus FFmpeg
> > wrapper code. This is _bad_. We don't want to promote this kind of
> > silliness in any way
> > 
> > If people want a massive, slow, insecure licensing headache that has
> > something to do with multimedia, they can install one of the many
> > "multimedia frameworks" that were created to """solve""" this problem.
> > Right?
> It also reminds me of firefox, huge numbers of plugins, the basic browser
> lacks huge amounts of basic functionality (resuming downloads, enabling
> cookies & scripts per site & blocking well known addvertisement/spy sites)
> what should be is firefox should include all that is usefull and that should
> be properly checked for being securely implemented.
> I agree with ronald that a plugin architecture wont do us nor our users any
> good.

Sometimes I fancied with the idea of a plugin system, for example you
could have a set of plugin filters which are too specific or are
simply not worth to be committed to the main repo. Having a plugin
system would simplify the use of those plugins (no need to
patch+compile FFmpeg).

Anyway I'm also concerned with licensing, stability, and maintanance
issues so I tend to prefer to avoid to open that can of worms (and for
filters people can still use frei0r/ladspa plugins).

It is also interesting to note that FFmpeg as a community shines
another time for its diversity, indeed most software projects consider
plugins just "a good thing (TM)" (on the other hand most software
projects are bug-ridden and bloated, so there is not much to learn
from them...).
FFmpeg = Free and Forgiving Monstrous Peaceless Enhancing Generator

More information about the ffmpeg-devel mailing list