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 D2BD34A8F0 for ; Sat, 22 Jun 2024 19:52:54 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C6B4668D265; Sat, 22 Jun 2024 22:52:51 +0300 (EEST) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2305768C446 for ; Sat, 22 Jun 2024 22:52:44 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id D9E751BF203 for ; Sat, 22 Jun 2024 19:52:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1719085964; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cZtOAcbs0KN5fyUvO9ofexAAyiuj6TnQ1bVmLRuiN0Y=; b=pMxsEXhND+ATmpzTvS8c61o7f9z2s3lJhlbM6jzL11EhQ6oEr3digVn36QmtnRNNLjMmQ5 FX63wQE8iKnyBqHGIsPEn1vbdJuCLDWnY1Sb5YN3hjk4vVa6e+PETbDerqB+Iqtcbm6dT0 FX7UJON6Nczkg+ppS7Mt1rztQSMwayW6selMCui8t3who82K6y2mhj6q8m9oHGRZuGkcH/ hhDRCQ10hCbGbh2//B4mohJ1rOMuMGL1UIE7Ke5A1xFSwi7tbCgUEfgXJrXj/nde86lqPo JedsYYMkZDf7kCnE3zr3wVwS4W23ySPce+7WUMoIuygF1rg+VdBb3oAntaja+Q== Date: Sat, 22 Jun 2024 21:52:42 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240622195242.GX4991@pb2> References: <20240622151334.GD14140@haasn.xyz> <20240622171028.GB45562@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20240622171028.GB45562@haasn.xyz> X-GND-Sasl: michael@niedermayer.cc 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: multipart/mixed; boundary="===============5635455506483135278==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============5635455506483135278== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D+UG5SQJKkIYNVx0" Content-Disposition: inline --D+UG5SQJKkIYNVx0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 22, 2024 at 05:10:28PM +0200, Niklas Haas wrote: > 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: > > [...] > > >=20 > > > ## Comments / feedback? > > >=20 > > > Does the above approach seem reasonable? How do people feel about int= roducing > > > a new API vs. trying to hammer the existing API into the shape I want= it to be? > > >=20 > > > I've attached an example of what could end up looking lik= e. If > > > there is broad agreement on this design, I will move on to an impleme= ntation. > >=20 > > 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. > >=20 > > What's the plan to bring them along? >=20 > 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. >=20 > 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. >=20 > 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. I agree we should keep using the same swscale.h header. It matches the libr= ary name thats installed (thats also what the user expects and what (s)he is us= ed to), and its what users #include today. Also its not a audio? scaler so the A is confusing. And sws_scale_frame() should be used obviously if thats as you say does "maximize the transition comfort" Maybe simply adding an option for the library user to set the behavior (favour AVFrame properties vs initial properties) And then eventually deprecate and phase out the initial ones The big advantage here is that we capture all users, noone stays on the old API. And the transition is also simpler, if its just a flag to flip for som= eone to try the new fully stateless system. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact --D+UG5SQJKkIYNVx0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZncrhwAKCRBhHseHBAsP q7r/AJ9A+x3rM3ZYbR0jY0bQ7M9sF0XNSwCeL9gmEQWlUrUgf1bO/d9o1KxMiFk= =dPhc -----END PGP SIGNATURE----- --D+UG5SQJKkIYNVx0-- --===============5635455506483135278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============5635455506483135278==--