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

this is a little "TLDR"

May i shorten this to:
Option 1: Binary plugin API which doesnt exist and noone will maintain
Option 2: Plugin List is maintained outside ffmpeg thus outside our control
Option 3: Plugin List is maintained in ffmpeg repository, we can control whats on it
Option 4: like option 3 but we forbid Non FFmpeg developers which makes this pointless
Option 5: We turn our libs into plugins (cool idea but unrelated)

option 4 is a subset of option 3. We can have a list and still add nothing but us to it

So really the question remaining is

Do we maintain a list of plugins or do we delegate this to outside FFmpeg ?

If we do choose to have this list on ffmpeg.org then we can decide what we
put on it like "no closed source". OTOH if we dont put it on ffmpeg.org then
there is nothing further to discuss here

thx


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier