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 02E1447C54 for ; Sat, 14 Oct 2023 17:26:54 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0497B68C6DE; Sat, 14 Oct 2023 20:26:52 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 875346800AC for ; Sat, 14 Oct 2023 20:26:45 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 29116240498; Sat, 14 Oct 2023 19:26:45 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id peYzGqm7PCXM; Sat, 14 Oct 2023 19:26:44 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 760222400FF; Sat, 14 Oct 2023 19:26:44 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 11AAB1601B9; Sat, 14 Oct 2023 19:26:37 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: 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> Mail-Followup-To: FFmpeg development discussions and patches , Cosmin Stejerean Date: Sat, 14 Oct 2023 19:26:37 +0200 Message-ID: <169730439704.32606.15686810952593488392@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 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 Cc: Cosmin Stejerean 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: Quoting Kieran Kunhya (2023-10-14 16:19:49) > On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara < > > vittorio.giovara@gmail.com> wrote: > > > > > > TBF this is in part why i was suggesting a new library - I feel like sws > > is > > > affected by bad brading because of these caching issues and imprecise > > > conversion, and a new clean api in a new library would make a lot of > > sense > > > in my opinion. > > > > I think the branding issue would solve itself in short order if the actual > > implementation of swscale started to be good. My concern with adding a new > > library is that we'd end up in a situation where we have both swscale and a > > new library side by side for some extended period of time. > > > > By comparison adding cleaner APIs to swscale and then slowly strangling > > the old APIs (along the lines of Niklas' proposal) would allow for a more > > gradual transition that has a higher likelihood of success compared to a > > full rewrite IMO. > > > > The issue is not the API, the issue is that swscale is astonishingly > complex and difficult to understand internally, there are lots of different > codepaths and randomly you'll end up with a buggy or slow one and have no > idea how to fix it. > > It's probably easier to start from scratch than to try and understand and > then fix swscale (years of work). I've seen more than one attempt to do that over the years, all failed. While I do agree that sws code is atrociously bad, I think that * an attempt to reinvent it from scratch is quite likely to fail and produce nothing of value * sws can be incrementally improved -- Anton Khirnov _______________________________________________ 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".