Re: [FFmpeg-devel] Democratization

[Michael Niedermayer <michael@niedermayer.cc>]

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

Hi Soft Works

On Tue, Jan 21, 2025 at 06:52:27AM +0000, Soft Works wrote:
[...]
> > We need plugins
> > please lobby for a plugin architecture
> 
> I'd love to see an extensibility model, I have one or two things for which there's clearly no place in the ffmpeg codebase.
> But this can't be a remedy for those problems above:
> 

> - Plugins cannot change the behavior of existing components

existing components could have callbacks (like a log callback or
a call to motion estimation) but yes you are correct in general


> - Many changes/additions cannot be applied via an extensibility model
> - Eventually it would create even more room for rejecting contributions
>   by saying it should be done as a plugin
> - Nothing is won for anybody when you end up having dozens of plugins which you need to compile for another dozen of platforms
> 
> A plugin model should serve as a way for serving very specific individual use cases, but not as a means for rejecting contributions which provide common value for many users.
> 

> Anyway we already have a kind of plugin model - at compile time at least
> ./configure allows fine grained control of what to include and what not,

yes, we really just need to allow each to be taken from external repositories

its also then not "more" compiling

That would then maybe be the simplest solution to plugins


> that I wonder whether this couldn't be leveraged for controversial cases - to achieve some middle ground between both "camps"?

The problem is a social one not a technical one.
Of course you are correct and that would work on a technical level but i think not a social one

People dont reject code saying "iam ok because it can be disabled at compile time"
They try to block it with some "argument" and the need to go through this is what kills
these projects. A contributor cannot say "i dont care what your oppinon is, ill apply this
ill maintain this, you wont maintain this, you wont use this, let me just work on my code."

If one simplfifies this down to the absolute minimum, whats needed is that the
contributor/maintainer has write access and others do not. Then the problem is solved.
I dont see how anything less than this solves it

Maybe we could just have 2 repositories but the conservative/restrictive one
would always die.
We could try this though if people want.
Just to make it clear i will make releases from the repository with all features
and thats the repository i will maintain security fixes for.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact

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