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 ECF1247C57 for ; Sat, 14 Oct 2023 17:42:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3F33068C6AB; Sat, 14 Oct 2023 20:41:58 +0300 (EEST) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AE836680072 for ; Sat, 14 Oct 2023 20:41:51 +0300 (EEST) Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-66cfd0b2d58so19667766d6.2 for ; Sat, 14 Oct 2023 10:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ob-encoder-com.20230601.gappssmtp.com; s=20230601; t=1697305310; x=1697910110; darn=ffmpeg.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=FaWfL4yi2E7zT//8m8XdJOn8ASws7cp+ijvWf4mZUYw=; b=N6QuWBnZgGF8at3ro6NUJdF8l1Fw01hP3dedlsy+n25hPUitewX/dfNqNijs3oZvxg GsUICPeMo1dsXb3g0gNC08gU2is5u0McgHKq+OjPxKge5Ty58k/iW02wWV2o8CGzQeCM 2BSad6T+6H9/b1xiVdw1wb9h49bgMh8iGE4K9pdu8CQ2XVx3yjDXIARqcbU6YIETVo56 VlQKUnFoJgypHi9BnloAu04TumwzSZnTMGume6XZWHqv/Fuwb3kH7vyYQnOxbRB5PLF5 FBIMk8XLROEuju1riAY3oObOROQomnj7yNI0IEyIxlTyngA4FsbGKOUtqDn6zNt60j9q YPfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697305310; x=1697910110; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FaWfL4yi2E7zT//8m8XdJOn8ASws7cp+ijvWf4mZUYw=; b=AtghR+6+KGBVBV+cEtF/sTQOSmNdEuX60AdOI7bgCkzZ+afUkX9MzMvXYx+XM6Rd68 JL0qW+m6ZLA6UVZymyY5WgfUW5uA3s+VXLCYsYHxbQFSfzmQZd5uzjq27uztHyEgSWIW UXzOaQfKwdn2JGAMMXBxivV5DYbHCdg1MyTs50ja/rYTUzX74rstQ1H1xkJPzF0SBh9n 6ZGUPBYbsfkigs9mAniH+UXNiUut04meKXybmAj5VN0Yw0r3Jn9hGNgG+WK4Njl8Wfdh G8uFdOK1PPU/FmIwZc7Wi/1RUGSbht385edlj6faPZkfAEIIHquCVffqY2b8dDdrwuv/ m/1Q== X-Gm-Message-State: AOJu0YyDdTtlQaCdwK7NbzdGkBiDM5nt+YPb5Vswv9UUphV3CoUPOPw3 Y4vkijLWc7eCN8aU2F5+crqIjKgC1Phzic5kjcq9rbHsI2SwfdvkASc= X-Google-Smtp-Source: AGHT+IHfywT3+F9fkrGzEf/8qvPoT18VngGPjkP1BY7NpehFY9HcmZmm6F8+dfD0ogjzWCCDSj/cYG3Nxn0AbQkvMoY= X-Received: by 2002:a05:6214:f09:b0:66d:3a89:8133 with SMTP id gw9-20020a0562140f0900b0066d3a898133mr2313768qvb.64.1697305309825; Sat, 14 Oct 2023 10:41:49 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20231014170036.GV3543730@pb2> From: Kieran Kunhya Date: Sat, 14 Oct 2023 18:41:37 +0100 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 18:00 Michael Niedermayer, wrote: > On Sat, Oct 14, 2023 at 03:19:49PM +0100, Kieran Kunhya wrote: > > 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 > > randomly ? > code in general doesnt give you randomly something very different. > Come on, there's no need to be facetious. Change the PIX_FMT to a the same sampling but a different packing and you a get totally different codepath, sometimes just decides to use C. Likewise with any of the lightly documented flags, you can have drastic changes in speed and quality unless you pre-test all the code paths. > So, why do i complain? because swscale has real issues and needs > to be improved. And these comments point in the wrong direction > > > > and have no > > idea how to fix it. > > If you dont know how to fix it yourself, sending me a bug report is > probably a good start. > Covered in here: https://trac.ffmpeg.org/wiki/swscale Yuv422p10 to yuv420p10 has forced and useless and CPU costly scaling of the luma channel with 32 bit intermediates last time I looked. All to be shifted back to the original values. > > > > > > It's probably easier to start from scratch than to try and understand and > > then fix swscale (years of work). > > 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'm pretty sure you don't need to understand self-modifying code to write a scaler. The rest is covered here: https://trac.ffmpeg.org/wiki/swscale > 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. > 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. > Nicer code can be understood by more than one person. Let's be honest you would block any attempt to even start removing cruft in swscale like mmx, self-modifying code etc. > 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 > Hmmm, building a simple thing for something and then "stuff being added", that sounds like the arguments a few of us have been making in another thread. Regards, Kieran Kunhya > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Dictatorship: All citizens are under surveillance, all their steps and > actions recorded, for the politicians to enforce control. > Democracy: All politicians are under surveillance, all their steps and > actions recorded, for the citizens to enforce control. > _______________________________________________ > 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".