[FFmpeg-devel] [PATCH] Dynamic plugins loading

[Felipe Contreras]

On Sat, Nov 6, 2010 at 2:05 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Nov 06, 2010 at 01:56:30PM +0200, Felipe Contreras wrote:
>> On Sat, Nov 6, 2010 at 12:57 PM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> >> 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.
>
> So the packaging system can't handle a real-world situation and the solution
> is to change the world instead of the packaging system?

This applies to both apt and yum, so it's packaging systemS. Yes,
packaging systems are screwed because they don't work nicely with
FFmpeg. Other packages else works fine for strange reasons.

>> > 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.
>
> And you claim those manual steps are impossible to automate?
> Sorry, but I'll really want proof for _that_.

It might be possible, but it would be a hack, just for FFmpeg. No
point in doing that.

>> > 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.
>
> Gentoo does not even have that issue, wtf are you talking about?
> Or do you mean to say "well, we have to keep at least one reason
> around for Gentoo, it's not acceptable that binary distributions
> are suitable for everyone!".

Binary distributions build packages in only one way, trying to add as
many options as possible. git-no-opens-ssl, git-no-documentation,
git-no-python, etc. Is just not feasible. Not that this matters at all
because what is need is to selectively add the extra functionality the
user needs, which is typically done through plugins.

>> > 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.
>
> If anything below a separate "special-Fedora" source repository is not
> enough there's no point in discussing any further.

It's not about Fedora, but distributions that don't want to include
patent encumbered code.

-- 
Felipe Contreras