From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Plugins architecture
Date: Tue, 12 Aug 2025 14:34:20 +0200
Message-ID: <20250812123420.GJ29660@pb2> (raw)
In-Reply-To: <6e208946-690c-4cbb-9539-bd85df02430c@lynne.ee>
[-- Attachment #1.1: Type: text/plain, Size: 3682 bytes --]
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
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
next prev parent reply other threads:[~2025-08-12 12:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 12:22 Lynne
2025-08-11 12:43 ` Michael Niedermayer
2025-08-12 6:25 ` Lynne
2025-08-12 11:35 ` Michael Niedermayer
2025-08-11 13:10 ` Michael Niedermayer
2025-08-11 17:48 ` Jacob Lifshay
2025-08-12 6:38 ` Lynne
2025-08-12 11:59 ` Michael Niedermayer
2025-08-12 14:13 ` [FFmpeg-devel] Global state and mutable component lists (was: Plugins architecture) Nicolas George
2025-08-11 17:38 ` [FFmpeg-devel] Plugins architecture Jacob Lifshay
2025-08-12 12:34 ` Michael Niedermayer [this message]
2025-08-12 13:44 ` Nicolas George
2025-08-12 14:10 ` Michael Niedermayer
2025-08-12 23:08 ` Kieran Kunhya via ffmpeg-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250812123420.GJ29660@pb2 \
--to=michael@niedermayer.cc \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git