> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Michael Niedermayer > Sent: Tuesday, January 21, 2025 1:41 AM > To: FFmpeg development discussions and patches <ffmpeg- > de...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
