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 45BC047158 for ; Sat, 9 Sep 2023 14:31:11 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0291468C8A8; Sat, 9 Sep 2023 17:31:09 +0300 (EEST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 13B2568C6B5 for ; Sat, 9 Sep 2023 17:31:03 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 229C94000A for ; Sat, 9 Sep 2023 14:31:01 +0000 (UTC) Date: Sat, 9 Sep 2023 16:31:00 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230909143100.GC8640@pb2> References: <05e2d1c7-956b-4ce5-a1a2-69e83ae484ab@betaapp.fastmail.com> <20230908130949.GW8640@pb2> <2411389.1KpoTlJdGa@basile.remlab.net> MIME-Version: 1.0 In-Reply-To: <2411389.1KpoTlJdGa@basile.remlab.net> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023 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: multipart/mixed; boundary="===============6466618402283096298==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6466618402283096298== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G5yIW5EaChZ5gJdA" Content-Disposition: inline --G5yIW5EaChZ5gJdA Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 08, 2023 at 06:42:49PM +0300, R=E9mi Denis-Courmont wrote: > Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a =E9= crit : [...] > > Should decissions in FFmpeg be made to maximize benefit / be optimal for > > FFmpeg ? >=20 > How do you define benefit for FFmpeg? This is real life, not an RPG. We c= an't=20 > simply do linear optimisation to find out what the right choices are. Wit= h that=20 > said, everybody will agree with that vague phrasing to maximise benefit t= o=20 > FFmpeg, and yet nobody will agree what that means and this won't change= =20 > anything. I think i really only meant the part "everybody will agree with", i dont think the exact definition is that important. Because i think something "good" will be good under most definitions that optimize something tangible But for sake of academic argument, we could consider more specific definiti= ons like: "maximise the time and money people safe" so if you fork planet earth and one has one kind of FFmpeg and the other has another which side on aver= age safes people more money and time =66rom this, optimization follows, bit also bug freeness and also being mai= ntainable and clean and well structured because otherwise code just becomes shitty an= d so does user experience ... >=20 > You really need to make more concrete suggestions on this particular poin= t=20 > (and the rest of the email touches different issues, IMO). >=20 > > There has been a marked shift of project goals over the years. While lo= ng > > ago FFmpeg was "all of multimedia". With time the scope of the project = has > > shrunk. >=20 > AFAICT it is rather that FFmpeg failed to capture the bits of multimedia = that=20 > its reverse dependencies had already implemented decently well first - au= dio=20 > and video outputs, and user interfaces, being the obvious elephants in th= e=20 > room. I don't think FFmpeg should waste time trying to reinvent SDL and= =20 > Placebo at this point, even less a web browser. i do think libplacebo functionality belongs in and is needed inside FFmpeg. >=20 > Also FFmpeg *did* expand into filtering with some success. >=20 > And now would probably be a good time to expand into WASM platform suppor= t=20 > (especially SIMD). yes >=20 > > FFserver was removed not improved, not replaced. > > the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpe= g*, > > rv* and others and at the time was the best encoder available (not anym= ore > > now, no) but after mpeg4-asp, modern video encoders where no longer add= ed > > to ffmpeg. In one case a advanced encoder for a fringe format was rejec= ted. > > AI based filters are neglegted at a time everything is shifting to neur= al > > networks and AI. Clientside / "in browser" also has become very importa= nt > > but is absent from our documentation, our fate tests, and so on >=20 > This is more of a question of whether FFmpeg should have subpar=20 > implementations vs no implementations. I think theres not one awnser that fits all cases here. Having a simple and clean implementation thats good enough can be usefull e= specially for areas where the "goodness" doesnt matter much and things require no real maintaince OTOH an implementation thats not "good enough" is bad I mean if for a fringe game format we had an encoder thats 5 pages of C code and achives 95% of the compression of the best. And the 100% one would be 1000 pages of code in an external lib. Id say the 5 page encoder is good enough to include and support. OTOH 95% compression of the best for a major format like h264 i think is no= t good enough and we should not do that. All this of course is subjective thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. --G5yIW5EaChZ5gJdA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZPyBoQAKCRBhHseHBAsP q/RBAJ9KExQDhQGSb5m851cTPnbmuRVNogCdHXDkBuAJq+opYzA39X4p0obtnjg= =tsfU -----END PGP SIGNATURE----- --G5yIW5EaChZ5gJdA-- --===============6466618402283096298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============6466618402283096298==--