[FFmpeg-devel] Democratization

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Tuesday, January 21, 2025 1:41 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Democratization
> 
> Hi Gyan
> 
> On Mon, Jan 20, 2025 at 11:44:41PM +0530, Gyan Doshi wrote:
> >
> >
> > On 2025-01-20 11:14 pm, Soft Works wrote:
> > > - An indication that the aim and direction of the contribution is
> > >    generally acceptable
> >
> > This the crux of the matter. There appear to be two camps at odds
> with one
> > another:
> >
> > 1) a conservative camp which wants to avoid features or changes
> which don't
> > neatly fit within a conventional pure architecture with clear
> separation of
> > roles and duties, or features which are of use only to some users
> >
> > and,
> >
> > 2) a broadband camp which accepts features which are niche or which
> require
> > some hybrid accommodation in its implementation.
> >
> > For most of ffmpeg history, the latter has been the dominant camp.
> But not
> > in recent history.
> > Tweaking the structures or procedures of governance can't
> ultimately bridge
> > this chasm. It's almost like these camps should be part of
> different
> > projects.

Well, as long as ffmpeg remains to be camp (2)... ;-)

George's suggestion sounds much better to me, if that would give everybody what they want, keeping both camps under a single hood.

> 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
- 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, that I wonder whether this couldn't be leveraged for controversial cases - to achieve some middle ground between both "camps"?

Like:

- Old or niche-audience codecs and formats could be declared "unsupported", moved to an 'unsupported' subfolder and excluded from the ./configure default
- New contributions where there is doubt about the size of audience or whether the contributor/maintainer will stay on track over time, could be added on a trial basis, declared as "experimental" and not be included in the default compile config for a certain amount of time.

(play the maintenance card? >> use modern tools for refactoring where it doesn't matter if it's 100 or 1000 codecs to make a change to) 

sw