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

["Zhao Zhili" <quinkblack@foxmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Niklas Haas
> Sent: 2024年4月19日 22:50
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> 
> On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer <michael@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.

VLC is plugin based, gstreamer is plugin based too (which went toooo far 😝),
I don't think plugin is that dangerous.

Firstly, we can enable plugin interface only with enable-gpl.

Secondly, we can have a less stable plugin interface than public API, for our
development convenience, and encourage plugin authors to contribute to
upstream.

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

+1.

I can't remember how many patches I have ping. It's really frustration.
I ask for permission to commit mostly due to this.

Now I can keep track of my own patches, but it's still not easy to filter out
patches I'm interested to review (I can blame the email client, but blame it
doesn't help). I'm sure I can review more patches with a new workflow.

> 
> 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@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> _______________________________________________
> 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".

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