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 D5C2F4A17D for ; Sat, 22 Jun 2024 15:10:38 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3995D68D3E6; Sat, 22 Jun 2024 18:10:36 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7B84E68D154 for ; Sat, 22 Jun 2024 18:10:29 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1719069029; bh=FXCITdmPf1+HHyh5MdpE5QCdadWeXSw/GKCpKei4GhQ=; h=Date:From:To:Subject:In-Reply-To:References:From; b=g7uWOx1qDOhGS9wa1DUgKxzrAeehy0ZzIMXSQW3h487h/tGvxaKqAozYnoOUTvjgc u8kRbCjaoN9Q+WZOOSqQNBQbMKyUS6hR6SHl+NTYdmHifmPUGUAiXIkI7Sq/ur8CjK 4fn1c4X6IW6V0hsahFDFpnlmu7FAyxAtUNldhAR8= Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 2FB5A41EC3 for ; Sat, 22 Jun 2024 17:10:29 +0200 (CEST) Date: Sat, 22 Jun 2024 17:10:28 +0200 Message-ID: <20240622171028.GB45562@haasn.xyz> From: Niklas Haas To: FFmpeg development discussions and patches In-Reply-To: References: <20240622151334.GD14140@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] [RFC]] swscale modernization proposal 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, 22 Jun 2024 15:23:22 +0100 Andrew Sayers wrote: > On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote: > [...] > > > > ## Comments / feedback? > > > > Does the above approach seem reasonable? How do people feel about introducing > > a new API vs. trying to hammer the existing API into the shape I want it to be? > > > > I've attached an example of what could end up looking like. If > > there is broad agreement on this design, I will move on to an implementation. > > API users seem to have difficulty with this type of big change[[1], > and doing the interface before the implementation means there's less > reason for developers to switch while you're still looking for feedback. > > What's the plan to bring them along? Since SwsContext is entirely internal, we can continue providing the current API on top of whatever internal abstractions we arrive at. As a trivial example, sws_scale() can construct a temporary AVFrame based on the provided information, and simply pass that to avscale_frame(). So I don't think legacy API users are at risk, or pressure to switch, unless they want access to *new* functionality. For that, the harder step is moving from sws_scale() to sws_scale_frame(). This is something API users can *already* do. By contrast, moving from sws_scale_frame() to avscale_frame() should hopefully be simple, since it just requires making sure the AVFrame is correctly tagged. Usually, the flow is in the opposite direction - users receive a correctly tagged AVFrame and manually forward this information to the SwsContext. So, most of the time, moving to a fully AVFrame-based API will result in deleting code, rather than adding it. If we wanted to maximize the transition comfort, we should consider re-using the sws_scale_frame() entrypoint directly. The main reason I am hesitant to do this is because sws_scale_frame() is currently tied to the stateful configuration of SwsContext, and mostly ignores the AVFrame metadata. While changing that is possible, it possibly presents a bigger API break than simply introducing a new function. > > [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/328852.html > _______________________________________________ > 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".