[FFmpeg-devel] Plugins architecture

[FFmpeg-devel] Plugins architecture

[Lynne]

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

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1592 bytes --]

Hi Lynne

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.

You force pushed the revert with standing objections 12 minutes
after a "binary choice" you created.
And without warning that you would push something

<michaelni> We can discuss, that was my suggestion, theres no plugin from a non ffmpeg developer, not one so also not one with dlopen and none hiding dlopen and none breaking contract
<Lynne> okay, so option 1?
[13:48] <Lynne> its a binary choice.
[14:00] <fjlogger> [FFmpeg/FFmpeg:master] 1 new commit (https://code.ffmpeg.org/FFmpeg/FFmpeg/compare/67320e0627a3b0210794c8f58e3e6acceb074b5c...85e8e590015e918462031cac21c9c5862a1776b8) pushed by L⁠ynne
<fjlogger> [FFmpeg/FFmpeg] Pull request #20213 merged: WIP: Revert "doc/developer: Basic documentation for Source Plugins" (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20213) by L⁠ynne

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras

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

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3555 bytes --]

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"


> 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

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


> 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


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

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

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

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

Re: [FFmpeg-devel] Plugins architecture

[Jacob Lifshay]

On August 11, 2025 5:22:26 AM PDT, Lynne <dev@lynne.ee> wrote:
> 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.

I think it would be good to have some sort of plugin architecture that doesn't require the version of ffmpeg you're using to contain a reference to your source code, this allows you to more easily backport new formats/codecs/etc. to older ffmpeg releases. I'd be fine with having ffmpeg maintain a repository of plugins (could be in ffmpeg's repo, or separate) as long as you can point ffmpeg to a later version of the repository than the version of ffmpeg you're currently building. you'd also want to be able to use a local checkout of that repository of plugins so you can test a new plugin that isn't in ffmpeg's repository yet.

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

Re: [FFmpeg-devel] Plugins architecture

[Jacob Lifshay]

On August 11, 2025 6:10:52 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
> On Mon, Aug 11, 2025 at 09:22:26PM +0900, Lynne wrote:
> > 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

If we were to forbid dlopen-ing proprietary code we have several plugins we'd therefore have to remove: decklink, anything using cuda, almost any windows stuff (but we could use the excuse that it's part of the OS or that it works with Wine), probably more

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

Re: [FFmpeg-devel] Plugins architecture

[Lynne]

On 11/08/2025 21:43, Michael Niedermayer wrote:
> Hi Lynne
> 
> 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.
> 
> You force pushed the revert with standing objections 12 minutes
> after a "binary choice" you created.
> And without warning that you would push something

I think I was being very clear.
Your motive for pushing a huge project policy change that affected all 
maintainers after hardly a day of review was less clear.

 > <Lynne> for a third time, I am really not comfortable with this
 > mechanism being open, nor being merged after barely a day. I would
 > like to know whether you want to approve this temporary revert, after
 > which we can discuss this on the mailing list, or would like to accept
 > my addition of this being only available for official repositories.> 
<michaelni> We can discuss, that was my suggestion, theres no plugin 
from a non ffmpeg developer, not one so also not one with dlopen and 
none hiding dlopen and none breaking contract
> <Lynne> okay, so option 1?
> [13:48] <Lynne> its a binary choice.You said you wanted a discussion, which I took as agreement to my 
response, and now you have an actual discussion on this project-wide 
policy change.

We are all very busy volunteers. Asking us to periodically inspect all 
projects included as source plugins for LGPL/GPL violations after an 
unreviewed policy change by a single maintainer is overtly wrong.
I know you have a position that's more favorable towards plugins, and 
that this was a step towards that. But to me, this was by far the worst 
type of compromise.
_______________________________________________
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".

Re: [FFmpeg-devel] Plugins architecture

[Lynne]

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

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 780 bytes --]

Hi Lynne

On Tue, Aug 12, 2025 at 03:25:13PM +0900, Lynne wrote:
[...]
> We are all very busy volunteers. Asking us to periodically inspect all
> projects included as source plugins for LGPL/GPL violations after an
> unreviewed policy change by a single maintainer is overtly wrong.

Noone is asking you (or anyone) to do anything in relation to teh plugins.

you seem obsessed by wanting to "monitor" and "inspect" this.

Thats like the github CEO periodically inspecting every github project,
and because he cannot rather closing github down.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato

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

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1793 bytes --]

Hi Lynne

On Tue, Aug 12, 2025 at 03:38:31PM +0900, Lynne wrote:
> 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.

noone has endorsed anything

and supporting binary plugins is not a "one time affair" its the very
opposit, its ongoing continous work to maintain a compatible and working
API and ABI


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

thats just talk, you wont maintain any of this.

and i doubt the community will freeze the whole API and ABI for it nor
should we.
And if its not frozen then a API needs to be designed for these binary plugins

But you are welcome to create a functioing API for binary plugins and
maintain it long term.
Iam certainly not going to stop you. This of course has nothing to do with
source pligins. They are entirely separate things.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

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

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

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

Re: [FFmpeg-devel] Plugins architecture

[Nicolas George]

Lynne (HE12025-08-11):
> 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.

Apparently, you have not noticed you only reverted the documentation.
The feature is still there.

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

Something needs to be emphasized: since we distribute as a source code,
except for the word “official”, we cannot prevent this. If somebody sets
up a GitHub project “Easy FFmpeg” with a build script that pulls all
sorts of extra components, including proprietary ones.

And this is something some downstream users have been asking for,
vocally. It is only a matter of luck that no such thing has gained
traction yet.

What we can do is get on top of it, slap the word “official” on it and
control what it does.

(It is kind of similar to banking: it is impossible to prevent banks
from emitting more credit than their reserves, but states can offer them
guarantees and at the same time regulate the shit out of them.)

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

Please, next time, save us reading the copy-paste and just says “same as
2 except”.

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

The difference between options 2-5 is just window dressing: the code is
the same, the only difference is whether the plugins are listed on the
static website, the wiki or nowhere under our control.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 671 bytes --]

Hi Lynne

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

please look at this before you freak out and insta revert things again:
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20225

its just a bugfix and spliting the list into a seperat file, i think you wont disagree
but hey i also thought the documentation would not offend anyone

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

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

[FFmpeg-devel] Global state and mutable component lists (was: Plugins architecture)

[Nicolas George]

Lynne (HE12025-08-12):
> > 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.

An official binary plugin API requires stabilizing a lot of our internal
APIs, that would be a lot of work and a tremendous drag on development.
I am pretty sure there is a wide consensus against it.

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

This is partly true but rather inaccurate. We never had an
“infrastructure” to add components. What we had is mutable components
lists and the symbols to manipulate them public. Applications could
abuse that to insert custom components into the lists. I know it worked
because for a long time I used LD_PRELOAD to inject a demuxer of my own
into mplayer.

But to implement the custom components, applications had to include
uninstalled headers, they have to take them from our source tree. That
made it very clear that they were doing something unsupported.

> It wouldn't take much to revert that and implement support for this, along
> with freezing AVCodec longer-term than major bumps.

I very much oppose freezing AVCodec, especially because it would not be
enough: a lot of internal APIs would need to be frozen as well.

On the other hand, I would like to see mutable components lists back,
but for a completely different reason: to replace our terrible and
unreliable implementation of components whitelists.

And it goes well hand-in-hand with another worthy project of turning our
global state into multiple-allocatable structures.

Here is the idea:

- Applications that use our API need to allocate an instance of an
  AVLibrary object.

  (FreeType does that: “error = FT_Init_FreeType( &library );”
  <https://freetype.org/freetype2/docs/tutorial/step1.html>)

- AVLibrary contains all that is currently global state in our
  libraries: log callback, log level, lock manager, pools, etc., and of
  course component lists.

  (I have a solution that is compatible with having separate libraries.)

- AVLibrary is referenced (refcounted) from contexts, so that it is
  readily available from most of our code base.

- We have to create new versions of the entry points APIs,
  (avcodec_find_decoder_by_name(), etc.) that take an AVLibrary as first
  argument.

- A compatibility layer, quickly deprecated, allocates a global
  AVLibrary once and for all.

With this system, we would implement whitelists by adding only trusted
components to the AVLibrary instance. And people can add custom
components because the lists are mutable.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] Plugins architecture

[Kieran Kunhya via ffmpeg-devel]

On Tue, 12 Aug 2025, 04:11 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Hi Lynne
>
> 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
>
> please look at this before you freak out and insta revert things again:
> https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20225
>
> its just a bugfix and spliting the list into a seperat file, i think you
> wont disagree
> but hey i also thought the documentation would not offend anyone
>
> thx
>

How do plugins manage FATE tests?

Kieran

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