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-requ...@ffmpeg.org with subject "unsubscribe".
