[FFmpeg-devel] Plugins architecture

[FFmpeg-devel] Plugins architecture

[Lynne]

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.

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

I would like to hear other options or suggestions that developers may 
have, and ultimately, if there's a consensus on the amount of options 
that that the project would benefit from having a plugins interface, a 
vote on the type of interface(s) we would maintain.
_______________________________________________
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".

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1592 bytes --]

Hi Lynne

On Mon, Aug 11, 2025 at 09:22:26PM +0900, Lynne wrote:
> 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.

You force pushed the revert with standing objections 12 minutes
after a "binary choice" you created.
And without warning that you would push something

<michaelni> We can discuss, that was my suggestion, theres no plugin from a non ffmpeg developer, not one so also not one with dlopen and none hiding dlopen and none breaking contract
<Lynne> okay, so option 1?
[13:48] <Lynne> its a binary choice.
[14:00] <fjlogger> [FFmpeg/FFmpeg:master] 1 new commit (https://code.ffmpeg.org/FFmpeg/FFmpeg/compare/67320e0627a3b0210794c8f58e3e6acceb074b5c...85e8e590015e918462031cac21c9c5862a1776b8) pushed by L⁠ynne
<fjlogger> [FFmpeg/FFmpeg] Pull request #20213 merged: WIP: Revert "doc/developer: Basic documentation for Source Plugins" (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20213) by L⁠ynne

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3555 bytes --]

Hi Lynne

On Mon, Aug 11, 2025 at 09:22:26PM +0900, Lynne wrote:
[...]
> 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.

That requires someone to create that "binary plugin interface",
that person seems not existing, so i dont think its an "option"


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


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

Id like to point out that testing for dlopen() is a matter of
"git grep dlopen" after the "git merge" of teh plugins
Similarly we can require any specific license or contract text in a
plugin and can verify that automatically. (similar to fate-source)
Thus turning a non compliant plugin into a contract violation

Iam not sure we want or need any of that, just saying that if we want
then its a automated thing


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

These options do not seem exclusive
we can make a list of GPL/LGPL plugins maintained by ffmpeg developers

and a seperate list of GPL/LGPL plugins maintained by other developers


> 
> 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.
> 
> I would like to hear other options or suggestions that developers may have,
> and ultimately, if there's a consensus on the amount of options that that
> the project would benefit from having a plugins interface, a vote on the
> type of interface(s) we would maintain.

IIUC your intend is to avoid closed source / non free plugins.
I do think, what you push for here, will open the door primarly for
closed source / non free plugins.
So it seems to do the exact opposite of what you try to achieve.

Because if we dont have a reasonable complete list of plugins in
our repository, it will be outside and will contain all the non free,
corporate and closed source ones

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] Plugins architecture

[Jacob Lifshay]

On August 11, 2025 5:22:26 AM PDT, Lynne <dev@lynne.ee> wrote:
> I would like to hear other options or suggestions that developers may have, and ultimately, if there's a consensus on the amount of options that that the project would benefit from having a plugins interface, a vote on the type of interface(s) we would maintain.

I think it would be good to have some sort of plugin architecture that doesn't require the version of ffmpeg you're using to contain a reference to your source code, this allows you to more easily backport new formats/codecs/etc. to older ffmpeg releases. I'd be fine with having ffmpeg maintain a repository of plugins (could be in ffmpeg's repo, or separate) as long as you can point ffmpeg to a later version of the repository than the version of ffmpeg you're currently building. you'd also want to be able to use a local checkout of that repository of plugins so you can test a new plugin that isn't in ffmpeg's repository yet.

Jacob
_______________________________________________
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".

Re: [FFmpeg-devel] Plugins architecture

[Jacob Lifshay]

On August 11, 2025 6:10:52 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
> On Mon, Aug 11, 2025 at 09:22:26PM +0900, Lynne wrote:
> > 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.
> 
> Id like to point out that testing for dlopen() is a matter of
> "git grep dlopen" after the "git merge" of teh plugins
> Similarly we can require any specific license or contract text in a
> plugin and can verify that automatically. (similar to fate-source)
> Thus turning a non compliant plugin into a contract violation

If we were to forbid dlopen-ing proprietary code we have several plugins we'd therefore have to remove: decklink, anything using cuda, almost any windows stuff (but we could use the excuse that it's part of the OS or that it works with Wine), probably more

Jacob
_______________________________________________
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".