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