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 4210847635 for ; Sun, 15 Oct 2023 14:36:46 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B99A868C8EA; Sun, 15 Oct 2023 17:36:43 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 85D9368C5D0 for ; Sun, 15 Oct 2023 17:36:37 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 9526F20002 for ; Sun, 15 Oct 2023 14:36:36 +0000 (UTC) Date: Sun, 15 Oct 2023 16:36:35 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20231015143635.GX3543730@pb2> References: <20231013191934.GQ3543730@pb2> <20231014003409.GB5462@haasn.xyz> <22919b35-2f3a-494f-8f34-e40e628263f2@gmail.com> <20231014005457.GB123737@haasn.xyz> <8A960BE2-8364-4AF8-A9B5-E0551C19F9DF@cosmin.at> <0101018b2b540db8-9535df37-83d6-44fd-8a1e-a5fd99185315-000000@us-west-2.amazonses.com> <20231014170036.GV3543730@pb2> <20231014192451.GB62524@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20231014192451.GB62524@haasn.xyz> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion 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="===============2970150233766929171==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2970150233766929171== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fSLOEWDpqXiBB1zu" Content-Disposition: inline --fSLOEWDpqXiBB1zu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Sat, Oct 14, 2023 at 07:24:51PM +0200, Niklas Haas wrote: > On Sat, 14 Oct 2023 19:00:36 +0200 Michael Niedermayer wrote: > > Well there are 2 further aspects with that. > >=20 > > The first one is bluntly put. If you dont understand the old code, then > > you probably are not qualified to write better code. > > People tend not to successfully improve things they dont understand. >=20 > I have a deep understanding of colorspaces and the necessary conversion > steps between them, and am also in a good position to integrate > libplacebo as a possible backend. >=20 > However, I do not have a good understanding of CPU/SIMD code, nor the > various swscale internals, beyond the cursory investigation I needed for > some recent swscale bugs I encountered. So I'll definitely need some > help along the way to fully understand those swscale internals. iam happy to help., as far as i remember (and as far as i know) things. Also ronald probably knows quite a bit from the older parts. various people also added bits over the years, they can probably help within these bits. And we had some GSoC contributions from Pedro Arthur, he certainly is worth a try to ask if you have a question related to his code. >=20 > > The 2nd issue is, ATM, i maintain swscale. If iam involved in the new > > effort and understand it either because of that or because it has some > > similarity then i can continue to maintain swscale. If its totally > > different and i was totally not involded then i also will not maintain > > it obviously. >=20 > I think it would be possible to join forces to the extent needed to > arrive at a satisfactory result. At the very least, I have very limited > experience working with "irregular" packed formats. >=20 > Obviously, my intent is not to blanket discard the swscale internals. It > has years and years of optimized kernels for various platforms just > lying around, wanting to be used. Hence my proposal of redesigning the > high-level logic, rather than the low-level details. yes, i expect that my role in this will probably be limited to awnsering questions, reviewing code and maybe running some tests. Not sure i will have the motivation to do much heavy restructuring of things It might be that i suddenly see something i want to work on ;) but besides = this iam happy to leave it to you and others >=20 > > This is something to be especially aware of in case the cleanup/new > > code would be done by someone who comes, does it and leaves. you > > could end up with nicer code thats then unmaintained. > >=20 > > PS: whats the real issue with sws ? > > it evolved out of a piece yuv->rgb converter from a video player. > > It evolved from that and stuff was added into it. > > This is a similar situation to why ffmpeg.c needed cleanup >=20 > Yes, it amounts to the usual disentangling of various special cases and > branches into one top-down control flow that knows about all of these > special cases and fast/slow paths to begin with. >=20 > My goal is to arrive at a place where we have one single code flow that > looks something like: >=20 > 1. Settle the complete descriptions of the source and destination format/= csp > 2. Establish a list of operations to get from A to B, taking into > account user settings > 3. Determine and dispatch the best available functions for each operation I think this is the obvious logic way to design it, yes >=20 > With the necessary code separation and/or layers of abstraction in place > to make this design manageable. In particular, steps 1 and 2 should be > expanded to include things like conversion between primaries, conversion > between HDR and SDR, conversion between YUV/RGB, and so on. One thing that will be needed is to allow alternatives for seperation for example an optimized codepath might do vertical scaling and convertion to BGR16 in one piece. While both operations also should probably be availa= ble individually. This adds complexity but such combined operations are used in the current codepathes so if the existing optimizations are supported then the current way things are broken up into steps need to be supported >=20 > In particular, I also want to eventually add the ability to plug "Apply > a 3DLUT" in as a possible operation type for colorspace conversion, > probably by sharing the code that is already written for vf_lut3d. Speaking of this, the horizontal and vertical scaling is basically a FIR filter being applied. Which is also why swscale allows the user to provide such filters, they can be applied by just using the already needed codepathes with no extra complexity thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway --fSLOEWDpqXiBB1zu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZSv48AAKCRBhHseHBAsP q86xAJ46lc8ofIDJHiMNiP9V77xtGZjDqgCcCzmmWh8Ah0WywnIvlyY2TCC9IDM= =K5mE -----END PGP SIGNATURE----- --fSLOEWDpqXiBB1zu-- --===============2970150233766929171== 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". --===============2970150233766929171==--