[FFmpeg-devel] [PATCH] Dynamic plugins loading

[Felipe Contreras]

On Sat, Nov 6, 2010 at 12:57 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Nov 06, 2010 at 12:30:36PM +0200, Felipe Contreras wrote:
>> On Sat, Nov 6, 2010 at 11:47 AM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> > On Sat, Nov 06, 2010 at 11:18:54AM +0200, Felipe Contreras wrote:
>> >> FFmpeg's lack of dynamic plugin loading prevents it from getting into
>> >> the Fedora distribution. Period.
>> >
>> >> So we come again to the same: you don't care about Fedora. Fedora has
>> >> a philosophy, and that's that.
>> >>
>> >> Basically what you are saying is that Fedora needs to change their
>> >> philosophy in order to conform to FFmpeg.
>> >
>> > Well, I think we are still trying to figure out the philosophy,
>> > sometimes it is claimed to be "no patents" then it seems to be more
>> > like "no patents unless those we for some reason considered safe" or
>> > possibly "let's better not look, we might find a patent issue" and
>> > now according to you it's not related to patents but it's just
>> > that "dynamic plugin loading" is an absolute requirement.
>>
>> You are mixing everything. It's very simple; FFmpeg has code with
>> patents claimed by MPEG LA and other parties... that can't go into
>> Fedora, but people should be able to install that support from a third
>> party (rpmfusion.org).
>>
>> The only solution provided so far that is transparent to the end-user
>> is dynamic plug-in loading.
>
> No, that is no solution. Packages from different source that depend
> on internal APIs for which we guarantee no compatibility is a horror
> that Debian users have experienced enough, and here the involved
> dynamic libs were only different libav* versions and MPlayer.
> I see no reason why this wouldn't be far worse for plug-ins.

But at least it's better than the current situation: no FFmpeg at all.
So many packages have to go to rpmfusion.org, just because they rely
on it.

But I do agree that it looks like in order for dynamic plugin loading
to be useful for packages an internal ABI would be needed. Otherwise
packaging would remain messy.

>> However, I just heard in fedora-devel that
>> it might be possible to use a SONAME trick which seems to be used for
>> nvidia-libGL.so. A hack, but there's no better option for some
>> libraries.
>
> I do not know about better, but there are sure other options.
> First, you say that FFmpeg is not in Fedora at all, which needs
> to be "solved" first, otherwise we might just waste our time,
> related to this:
>
>> libvpx contains a _single_ codec that is claimed to be public domain,
>> there's no need for plugins.
>
> What is the difference to FFmpeg only compiled with VP8 decoder support,
> which according to you is not in Fedora either?

The difference is that a different (more useful) version of FFmpeg is
in rpmfusion.org, so there would be conflicts.

> Next, apt at least provides a way to select a certain package from a certain
> source, so e.g. if someone has rpmfusion enabled they'd get the "full" FFmpeg,
> otherwise the "basic". This has some issues, but sure is possible.

Yes, it's _possible_ both in apt and yum. But it requires _manual_
extra steps from the user. Currently, the user doesn't even need to
know what packages are needed to play certain clip; they are
automatically found for him.

> Then there's the option of adding proper support for this. I mean a lot of
> programs and even libraries can be built with very different configurations
> (e.g. I think libSDL can be built with framebuffer-only or X support, if your
> packaging system does not support these kinds of alternatives everyone needs
> to install X even if they only want to use a framebuffer SDL program).

That only flies for non-binary distributions: i.e. Gentoo.

> So it seems really questionable to me that FFmpeg is the place that needs fixing.

It certainly does. Even if the SONAME trick is used, and there are two
packages in Fedora, one would need to strip out all the
patent-encumbered source code.

-- 
Felipe Contreras