[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Niklas Haas]

On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer <michael at niedermayer.cc> wrote:
> A plugin system moves this patch-management to people who actually
> care, that is the authors of the codecs and (de)muxers.

A plugin system will only solve this insomuch as plugin authors will
just host their plugin code on GitHub instead of bothering with the
mailing list.

I think it runs a good risk of basically killing the project.

> Our productivity as is, is not good, many patches are ignored.
> The people caring about these patches are their Authors and yet they
> are powerless as they must sometimes wait many months for reviews

So, rather than all of the above, what I think we should do is contract
somebody to set up, manage, host and maintain a GitLab instance for us.

This would probably be the single most cost effective boost to both
community growth and innovation I can think of, as it will remove
several of the major grievances and barriers to entry with the
ML+pingspam model.

We can use a system like VLC's auto-merge bot, where any MR that has at
least one developer approval, no unresolved issues, and no activity for
N days gets *automatically* merged.

I'm sure that if we try, we can find an interested party willing to fund
this. (Maybe SPI?)

> Besides that, developers are leaving for various reasons and they
> are forced to setup full forks not being able to maintain their
> code in any other way.
> IMO A plugin system would improve productivity as everyone could work
> on their own terms.
> No week or month long delays and weekly pinging patches
> No risk about patches being rejected or ignored
> No need to read every other discussion on the ML. One can just
> simply work on their own plugin looking just at the API documentation
> ...
> 
> 
> 
> > 
> > > * ffchat
> > >     (expand into realtime chat / zoom) this would
> > >     bring in more users and developers, and we basically have almost
> > >     all parts for it already but some people where against it
> > 
> > This seems like a user application on top of FFmpeg, not something that
> > should be part of FFmpeg core. Can you explain what modifications in
> > FFmpeg would be necessary for something like this?
> 
> ffmpeg, ffplay, ffprobe are also user applications.
> 
> 
> > 
> > > * client side / in browser support
> > >     (expand towards webapps, webpages using ffmpeg client side in the browser)
> > >     bring in more users and developers, and it will be costly for us
> > >     if we let others take this area as its important and significant
> > 
> > I don't understand this point - don't all major browsers already vendor
> > FFmpeg for decoding?
> 
> FFmpeg does more than decoding.
> 
> 
> > 
> > > * AI / neural network filters and codecs
> > >     The future seems to be AI based. Future Filters and Codecs will use
> > >     neural networks. FFmpeg can be at the forefront, developing these
> > 
> > We already have TensorFlow support, no? (vf_sr etc.) What more is
> > needed?
> 
> more of that AND more convenience
> 
> lets pick a comparission
> to run fate
> you write "make fate"
> if you want to do it with the samples its
> make fate-rsync ; make fate
> 
> if you want to use vf_sr, its reading the docs, looking at some scripts reading their docs
> and i presume selecting a training set ? creating a model ? ....
> 
> how many people do that ?
> 
> thx
> 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".