[FFmpeg-devel] Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[FFmpeg-devel] Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Nicolas George via ffmpeg-devel]

michaelni (HE12025-10-13):
> Also you would have to convince the community, that we want this. iam
> not sure how the community would think about it, but for example you
> could offer to donate a percentage of your profits from this to
> ffmpeg.

Hi. I procrastinated replying about soliciting sponsorships, but if it
looks like that I cannot anymore. Also, it must not be discussed in the
dark of an obscure pull request, it needs to be seen on the
mailing-list.

If this is how us soliciting sponsorships looks like, then we must
absolutely not do it.

“Pay us and we will consider ignoring the qualms we have about the
licensing issues of your contribution” is already very bad by itself. It
is even badder when we realize it is only one step from “pay us and we
will consider ignoring the qualms we have about the poor quality of your
code”.

Ideally, accepting contributions should be judged on the merits of the
contribution itself: is the code beautiful? does it bring practical
benefit to our users? Out of necessity we have to add: will this be
properly maintained? But no more.

We can solicit sponsorship, sure, but even the appearance that the money
is a tit-for-tat for getting one's code into the project, getting
excellent publicity and future maintenance work for cheap, would be
extremely detrimental.

> about the open source free libbungee, yeah, i think we do want support
> for that

I disagree. What would be the benefit for our users?

This library is not packaged by major distributions; the license is not
more permissive: no benefit in availability.

Multiple implementations for the same feature: users will have to
scratch their head to decide which one is suited for their needs, that
negates some benefits.

There is talk of medium speed improvement. That would need to be
confirmed, but that would count as a benefit. Though it is already a
very fast process, a drop in the bucked in comparison with video
encoding or waiting for real time.

There is talk of improvement in quality, but it is at best subjective
and very small, possibly imaginary.

On the whole, I would say the benefit for our users is not worth the
effort.

(A more intransigent version of this would be: If a contribution comes
with links to a proprietary version, the it is an immediate hard no. We
are not here to give exposure to your proprietary software.)

Also, if we considered accepting, it should not be as an extra filter
with its own set of options. It should be as a single filter with an
option to choose the implementation but common options for the shared
features.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Kieran Kunhya via ffmpeg-devel]

On Tue, Oct 14, 2025 at 11:32 AM Nicolas George via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> michaelni (HE12025-10-13):
> > Also you would have to convince the community, that we want this. iam
> > not sure how the community would think about it, but for example you
> > could offer to donate a percentage of your profits from this to
> > ffmpeg.
>
> Hi. I procrastinated replying about soliciting sponsorships, but if it
> looks like that I cannot anymore. Also, it must not be discussed in the
> dark of an obscure pull request, it needs to be seen on the
> mailing-list.
>
> If this is how us soliciting sponsorships looks like, then we must
> absolutely not do it.
>
> “Pay us and we will consider ignoring the qualms we have about the
> licensing issues of your contribution” is already very bad by itself. It
> is even badder when we realize it is only one step from “pay us and we
> will consider ignoring the qualms we have about the poor quality of your
> code”.
>
> Ideally, accepting contributions should be judged on the merits of the
> contribution itself: is the code beautiful? does it bring practical
> benefit to our users? Out of necessity we have to add: will this be
> properly maintained? But no more.
>
> We can solicit sponsorship, sure, but even the appearance that the money
> is a tit-for-tat for getting one's code into the project, getting
> excellent publicity and future maintenance work for cheap, would be
> extremely detrimental.
>

I agree.
There's is definitely a discussion to be had about the reasons FFmpeg
accepts a third-party lib. There are now many libs being proposed into
FFmpeg as marketing exercises.

I also think we should encourage people to maintain and more
importantly test their own repositories of FFmpeg with their open
source or proprietary libs (on Forgejo?).

Regards,
Kieran Kunhya
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Zhao Zhili via ffmpeg-devel]

> On Oct 14, 2025, at 18:53, Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> On Tue, Oct 14, 2025 at 11:32 AM Nicolas George via ffmpeg-devel
> <ffmpeg-devel@ffmpeg.org> wrote:
>> 
>> michaelni (HE12025-10-13):
>>> Also you would have to convince the community, that we want this. iam
>>> not sure how the community would think about it, but for example you
>>> could offer to donate a percentage of your profits from this to
>>> ffmpeg.
>> 
>> Hi. I procrastinated replying about soliciting sponsorships, but if it
>> looks like that I cannot anymore. Also, it must not be discussed in the
>> dark of an obscure pull request, it needs to be seen on the
>> mailing-list.
>> 
>> If this is how us soliciting sponsorships looks like, then we must
>> absolutely not do it.
>> 
>> “Pay us and we will consider ignoring the qualms we have about the
>> licensing issues of your contribution” is already very bad by itself. It
>> is even badder when we realize it is only one step from “pay us and we
>> will consider ignoring the qualms we have about the poor quality of your
>> code”.
>> 
>> Ideally, accepting contributions should be judged on the merits of the
>> contribution itself: is the code beautiful? does it bring practical
>> benefit to our users? Out of necessity we have to add: will this be
>> properly maintained? But no more.
>> 
>> We can solicit sponsorship, sure, but even the appearance that the money
>> is a tit-for-tat for getting one's code into the project, getting
>> excellent publicity and future maintenance work for cheap, would be
>> extremely detrimental.
>> 
> 
> I agree.
> There's is definitely a discussion to be had about the reasons FFmpeg
> accepts a third-party lib. There are now many libs being proposed into
> FFmpeg as marketing exercises.
> 
> I also think we should encourage people to maintain and more

Should or shouldn’t? I’m a little confused.

> importantly test their own repositories of FFmpeg with their open
> source or proprietary libs (on Forgejo?).
> 
> Regards,
> Kieran Kunhya
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Kieran Kunhya via ffmpeg-devel]

On Tue, Oct 14, 2025 at 12:39 PM Zhao Zhili <quinkblack@foxmail.com> wrote:
>
>
>
> > On Oct 14, 2025, at 18:53, Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> >
> > On Tue, Oct 14, 2025 at 11:32 AM Nicolas George via ffmpeg-devel
> > <ffmpeg-devel@ffmpeg.org> wrote:
> >>
> >> michaelni (HE12025-10-13):
> >>> Also you would have to convince the community, that we want this. iam
> >>> not sure how the community would think about it, but for example you
> >>> could offer to donate a percentage of your profits from this to
> >>> ffmpeg.
> >>
> >> Hi. I procrastinated replying about soliciting sponsorships, but if it
> >> looks like that I cannot anymore. Also, it must not be discussed in the
> >> dark of an obscure pull request, it needs to be seen on the
> >> mailing-list.
> >>
> >> If this is how us soliciting sponsorships looks like, then we must
> >> absolutely not do it.
> >>
> >> “Pay us and we will consider ignoring the qualms we have about the
> >> licensing issues of your contribution” is already very bad by itself. It
> >> is even badder when we realize it is only one step from “pay us and we
> >> will consider ignoring the qualms we have about the poor quality of your
> >> code”.
> >>
> >> Ideally, accepting contributions should be judged on the merits of the
> >> contribution itself: is the code beautiful? does it bring practical
> >> benefit to our users? Out of necessity we have to add: will this be
> >> properly maintained? But no more.
> >>
> >> We can solicit sponsorship, sure, but even the appearance that the money
> >> is a tit-for-tat for getting one's code into the project, getting
> >> excellent publicity and future maintenance work for cheap, would be
> >> extremely detrimental.
> >>
> >
> > I agree.
> > There's is definitely a discussion to be had about the reasons FFmpeg
> > accepts a third-party lib. There are now many libs being proposed into
> > FFmpeg as marketing exercises.
> >
> > I also think we should encourage people to maintain and more
>
> Should or shouldn’t? I’m a little confused.
>
> > importantly test their own repositories of FFmpeg with their open
> > source or proprietary libs (on Forgejo?).

We should just let people have their libXXX fork of FFmpeg on Forgejo
in my opinion if we don't want to upstream the code.

Kieran
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Nicolas George via ffmpeg-devel]

Kieran Kunhya via ffmpeg-devel (HE12025-10-14):
> We should just let people have their libXXX fork of FFmpeg on Forgejo
> in my opinion if we don't want to upstream the code.

This is precisely why Michael added the source plugin mechanism that you
criticized so much.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Michael Niedermayer via ffmpeg-devel]

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

Hi Nicolas

On Tue, Oct 14, 2025 at 12:32:00PM +0200, Nicolas George via ffmpeg-devel wrote:
> michaelni (HE12025-10-13):
> > Also you would have to convince the community, that we want this. iam
> > not sure how the community would think about it, but for example you
> > could offer to donate a percentage of your profits from this to
> > ffmpeg.

I had added "Still i belive its wrong and we should not support closed source code"
to this after writing.
I guess you are subscribed to this by mail and have not seen the edit.

But i think its important as it clarified my position here.
I showed the submitter a possible thing he can try. But clarifying that
i dont think this is something we should accept

ill reply to the rest seperately to keep this easier to read

Also you should not include your "code+....@ffmpeg.org" link because it leads to other
people being able to make posts in your name on forgejo (same thing happens with github)

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: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Michael Niedermayer via ffmpeg-devel]

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

Hi Nicolas

On Tue, Oct 14, 2025 at 12:32:00PM +0200, Nicolas George via ffmpeg-devel wrote:
[...]
> Hi. I procrastinated replying about soliciting sponsorships, but if it
> looks like that I cannot anymore. Also, it must not be discussed in the
> dark of an obscure pull request, it needs to be seen on the
> mailing-list.

Maybe forgejo should post more to the ML, i dont know, depends on what
people prefer


> Ideally, accepting contributions should be judged on the merits of the
> contribution itself: is the code beautiful? does it bring practical
> benefit to our users? Out of necessity we have to add: will this be
> properly maintained? But no more.

yes


> 
> We can solicit sponsorship, sure, but even the appearance that the money
> is a tit-for-tat for getting one's code into the project, getting
> excellent publicity and future maintenance work for cheap, would be
> extremely detrimental.

I dont think we will accept the patch depending on an external closed source
version. But thats up to the community.

Either way, obviously the submitter is expected to maintain his code,
if it is accepted


> 
> > about the open source free libbungee, yeah, i think we do want support
> > for that
> 
> I disagree. What would be the benefit for our users?
> 
> This library is not packaged by major distributions; the license is not
> more permissive: no benefit in availability.
> 
> Multiple implementations for the same feature: users will have to
> scratch their head to decide which one is suited for their needs, that
> negates some benefits.

We generally have features in one of these categories:
1. We support it natively and reject external dependancies for alternatives
2. We support all external open source solutions which someone maintains
3. We have a limited native implementation and support some external one
   with the plan to remove the external dependancy ASAP

Is there a native equivalent to libbungee ?

we support librubberband
on https://www.breakfastquay.com/rubberband/
i find:
"Rubber Band Library is open source software under the GNU General Public License. If you want to distribute it in a proprietary commercial application, you need to buy a licence."

So its GPL + commercial dual license
while
libbungee is MPL 2.0 and libbungee pro is closed source with better quality

like i said, i think closed source is not something we should intentionally support

but i dont see why we should allow one of the open source implementations
and reject the other


[...]
> 
> There is talk of improvement in quality, but it is at best subjective
> and very small, possibly imaginary.

I think someone posted a link to a table of sound files one can listen to
to hear the difference between the indivisual implementations


> 
> On the whole, I would say the benefit for our users is not worth the
> effort.

its really 0 effort for us no?
the author of this, must maintain it.


> Also, if we considered accepting, it should not be as an extra filter
> with its own set of options. It should be as a single filter with an
> option to choose the implementation but common options for the shared
> features.

This makes it harder to maintain. And not how we do it for other filters
Its also more difficult to assign "blame" if something goes wrong with
that one filter.

IMHO there should be seperate filters for libbungee and librubberband
so theres a clear connection of responsibility.
If af_libX has an issue its the responsibility of the maintainer of that af_libX

In a combined filter everything is more complex. multiple responsible parties
multiple competitors must agree on command line interface and options, ...

thx

PS: about closed source, I dont believe in closed source, i belive in ida pro and ghidra

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

No great genius has ever existed without some touch of madness. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Rémi Denis-Courmont via ffmpeg-devel]

Hi,

Le 14 octobre 2025 13:32:00 GMT+03:00, Nicolas George via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> a écrit :
>michaelni (HE12025-10-13):
>> Also you would have to convince the community, that we want this. iam
>> not sure how the community would think about it, but for example you
>> could offer to donate a percentage of your profits from this to
>> ffmpeg.
>
>Hi. I procrastinated replying about soliciting sponsorships, but if it
>looks like that I cannot anymore. Also, it must not be discussed in the
>dark of an obscure pull request, it needs to be seen on the
>mailing-list.

This indeed doesn't look like it belongs in a pull request review comment. This mailing list would be a more inappropriate venue but only in the sense that it is slightly less inappropriate.

I just don't think that sort of argument is appropriate at all, for the reasons that you have already outlined.

But anyway, thanks for bringing this to the list's attention.

Br,
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org