Re: [FFmpeg-devel] Plugins architecture

[Lynne <dev@lynne.ee>]

On 11/08/2025 22:10, Michael Niedermayer wrote:
> 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"

Its a better option in that its a one-time affair, and also there's no
endorsement of such plugins by us.
Also, we had such an infrastructure in the past with users being able to 
give their own AVCodec structures to lavc, without us having guarantees 
that we wouldn't break this.
It wouldn't take much to revert that and implement support for this, 
along with freezing AVCodec longer-term than major bumps.

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

That's a rather eccentric and ineffective solution to a problem that 
shouldn't exist in the first place.

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

It would have fallen up to maintainers to check for this, which is one 
of my main objections to this option.

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

I included this option for your sake, as you were interested in SDR. 
This option would allow you to work on and distribute your SDR code.

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

If you feel that way about allowing plugins, I would be happy to have a 
free-for-all binary plugins interface if the rest of the developer 
community agrees. There is also some value from such an interface for 
ourselves, as it would allow us to test the actual guts of libav* 
libraries rather than having to use a real decoder and testing the 
decoder at the same time.
But personally, I am of the opinion that our project is well-developed 
enough to not need plugins. Rather than having codecs and filters live 
in separate repositories, we have room for more.

> 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
I am happy with this as well, as it would not constitute an endorsement 
from us.
_______________________________________________
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".