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 D7013475E6 for ; Sat, 14 Oct 2023 17:24:58 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D191D68C733; Sat, 14 Oct 2023 20:24:57 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 05A0668C490 for ; Sat, 14 Oct 2023 20:24:51 +0300 (EEST) Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 8DE6641EC3 for ; Sat, 14 Oct 2023 19:24:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1697304291; bh=tQ+TPkskFwn7WdiHjbTpTKu8wSnqyFfAW2aGxwEHQZ4=; h=Date:From:To:Subject:In-Reply-To:References:From; b=TCrckVAUgSy+7NyYrLp4d6w56HqiqwnKOQCXXODd+0B3oJPTvR1Y63gvCCTdTqSo3 FMYCqGJlyZUg4KIqHjQ5pwguoOBI6DK6GH5VUdPpxKnTzCgiZB8GkRh3hn8bDdljst 8xo7e95LYPvDOD2IVieBOirqidbP5k9z0QJ1onHg= Date: Sat, 14 Oct 2023 19:24:51 +0200 Message-ID: <20231014192451.GB62524@haasn.xyz> From: Niklas Haas To: FFmpeg development discussions and patches In-Reply-To: <20231014170036.GV3543730@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> MIME-Version: 1.0 Content-Disposition: inline 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: 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 Sat, 14 Oct 2023 19:00:36 +0200 Michael Niedermayer wrote: > Well there are 2 further aspects with that. > > 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. 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. 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. > 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. 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. 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. > 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. > > 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 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. My goal is to arrive at a place where we have one single code flow that looks something like: 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 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. 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. _______________________________________________ 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".