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