From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 3FF3848838 for ; Fri, 19 Apr 2024 14:50:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2F64168D33D; Fri, 19 Apr 2024 17:50:33 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E107F68CA42 for ; Fri, 19 Apr 2024 17:50:26 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1713538226; bh=MluA9TBOioKkFltNvVf31KpJNKN/fowrM2+poGgrXgM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=t93yRUM0/XYTzD3Ol09UirjbwLawYzGE6thP+aqtSaH+HC4XmvsFyQj/Q8v5g2+Pf lpB8ouLCn+5UWPKwAwjptWvlaUBodYxOquV0yJTwMK2On/bCv+eDlb6v8E5+BAQAUy BdQQdpPfqt3sg128JztdgEOE6TaiWnaDCtKQei+c= Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 0E2DB40D2C for ; Fri, 19 Apr 2024 16:50:26 +0200 (CEST) Date: Fri, 19 Apr 2024 16:50:25 +0200 Message-ID: <20240419165025.GB21094@haasn.xyz> From: Niklas Haas To: FFmpeg development discussions and patches In-Reply-To: <20240418205351.GS6420@pb2> References: <20240417135832.GJ6420@pb2> <20240418160207.GB45500@haasn.xyz> <20240418205351.GS6420@pb2> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer 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@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".