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 78F6647C33 for ; Fri, 13 Oct 2023 22:34:19 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 399BE68C733; Sat, 14 Oct 2023 01:34:17 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4D3B868C3D6 for ; Sat, 14 Oct 2023 01:34:10 +0300 (EEST) Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id E1FB348EEC for ; Sat, 14 Oct 2023 00:34:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1697236450; bh=MppxbR3XmGsQOBPPreOmhTMqdRmni5yHLxNiU0i5bY8=; h=Date:From:To:Subject:In-Reply-To:References:From; b=bDWKUfWZ+9wcmlxroHCL1vjWvhv5+gZeLuM7V7zzJFWi9xBjIg8ogKtG1HSywMjZQ OPTI0i1drYB/hRLnZOCVmiEaV+RPCe+E6q3Xv6zXznkAiZ62NYjlxu0thcsDafCvZd YnCI2qfz5TvkDaFpaaNha8xiCwcyIKrY1xFzELPk= Date: Sat, 14 Oct 2023 00:34:09 +0200 Message-ID: <20231014003409.GB5462@haasn.xyz> From: Niklas Haas To: FFmpeg development discussions and patches In-Reply-To: <20231013191934.GQ3543730@pb2> References: <20231013191934.GQ3543730@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 Fri, 13 Oct 2023 21:19:34 +0200 Michael Niedermayer wrote: > Hi everyone > > I propose using 15k$ from SPI for funding sws cleanup work. > this is substantially less than what people belive this needs (see IRC logs from yesterday or so) > So it really is more a small price for a good deed and not proper payment. > This of course is only available to competent developers. (exact rules or how thats determined > would still need to be decided unless its a clear case) > Also the exact outcome and goal would need to be discussed by the community and whoever > does the work. > But some goals would probably be to make sws > * pleasent to work with > * similar speed or faster > * proper multithreading > * proper full colorspace convertion not ignoring gamma, primaries, ... > * clean / understandable modular design (maybe everything can be a "Filter" inside sws > that get build into a chain) > > Proper payment (50k$ maybe) would be too much in relation to what SPI has ATM (150k$) > > Above all, this is just my oppinion, the actual SPI funding also would need to > be approved by the community. This can happen after a specific volunteer comes forth > or before, whichever way the community prefers. > > thx My gut instinct is that the correct path forwards is to first create a new API which can internally dispatch to swscale, libplacebo or zimg based on what's compiled/available/preferred (e.g. using GPU filters for hwframes, CPU filters for swframes, zimg (or vf_colorspace's primitives) for colorspace conversions ...). Much of the pain points of my own recent experience with swscale revolves around libswscale's very low level API, complete lack of understanding of most AVFrame metadata, and relatively complex configuration requirements. (vf_scale's comments even acknowledge that libswscale should handle this stuff internally, so users just need to point an AVFrame at both ends and let it do the right thing automatically) The second pain point of extending libswscale itself is that the high-level configuration and low-level "scaling" primitives are deeply entangled, reconfigured in various places, and hard to touch without fear of breaking edge cases. A new API would solve both problems. It would allow us to write new, AVFrame-based, high-level "business logic", which could continue to call into the low-level swscale implementation details and kernels for the time being, and also tap into GPU filters (a la libplacebo) where possible. As time moves on we could replace those underlying primitives by cleaned up rewrites where necessary, until the dependency on libswscale itself is null. Simultaneously, vf_scale can be rewritten on top of this API, which would allow e.g. auto-scale filters to start doing scaling on GPU when conversion between two hwformats is needed. _______________________________________________ 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".