[FFmpeg-devel] Plugins architecture

[Lynne <dev@lynne.ee>]

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