Re: [FFmpeg-devel] Plugins architecture

[Nicolas George <george@nsup.org>]

Lynne (HE12025-08-11):
> Recently, the issue of plugins was raised.
> 
> Michael pushed a patch to enable out of tree branches to be freely added to
> FFmpeg. I did not very much like the option of having officially-endorsed
> source plugins, as to me, it moved all the burden of maintenance to FFmpeg
> maintainers.
> The commit was reverted, with the tentative agreement to open a discussion
> on the nature of plugins we would like to have.

Apparently, you have not noticed you only reverted the documentation.
The feature is still there.

> 
> To me, at least, I can imagine five options:
> 
> Option 1 - we have an official binary plugin interface, free for
>            everyone to use with no limitation.

> Option 2 - we have an official source plugin interface, free for
>            everyone to use with no limitations. This means that all
>            plugins are source-code based. External plugins would result
>            in a build with a different license - if one of the plugins
>            used was non-free, then the resulting build would be non
>            free.
>            Basically, the status quo now, only we would avoid breaking
>            interfaces like AVCodec.
>            The list of source plugins would not be maintained by us, but
>            could be a text file that users could share between.

Something needs to be emphasized: since we distribute as a source code,
except for the word “official”, we cannot prevent this. If somebody sets
up a GitHub project “Easy FFmpeg” with a build script that pulls all
sorts of extra components, including proprietary ones.

And this is something some downstream users have been asking for,
vocally. It is only a matter of luck that no such thing has gained
traction yet.

What we can do is get on top of it, slap the word “official” on it and
control what it does.

(It is kind of similar to banking: it is impossible to prevent banks
from emitting more credit than their reserves, but states can offer them
guarantees and at the same time regulate the shit out of them.)

> Option 3 - we have an official source plugin interface, free for
>            everyone to use, with license limitations. All source plugins
>            The list of source plugins would be maintained by us, and
>            policing of the list for violations (including using
>            dlopen() to workaround licensing) would be left to us.
>            The list of such plugins would be maintained by us.

Please, next time, save us reading the copy-paste and just says “same as
2 except”.

> Option 4 - we have an official source plugins interface for repositories
>            maintained by FFmpeg developers. This means that for
>            developers interested in developing features outside of the
>            scope of the project, there would exist an interface which
>            would allow developers to conveniently maintain and
>            distribute their work as an optional extension for the
>            project.
> Option 5 - we have an official source plugins interface for repositories
>            affiliated with the FFmpeg project. This means that rather
>            than just using it for libpostproc, we could use the plugins
>            interface to split up the project into individual
>            repositories for each library.
> 
> As a maintainer, I would like to avoid option 3 to the extent that I am more
> comfortable with fully liberalizing all plugins via option 1.

The difference between options 2-5 is just window dressing: the code is
the same, the only difference is whether the plugins are listed on the
static website, the wiki or nowhere under our control.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".