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 E26DC48D23 for ; Sun, 23 Jun 2024 17:27:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9E3FF68D432; Sun, 23 Jun 2024 20:27:51 +0300 (EEST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D972D68D1CA for ; Sun, 23 Jun 2024 20:27:44 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id F38DF1C0004 for ; Sun, 23 Jun 2024 17:27:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1719163664; 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=aajvMQiySQeFy1XWvJPjuHJmDAQgjVx7hrHnbOdLK3c=; b=VDAFs83Ty7wzu/ZBUVDsp6Ta0GTfrtHFEssIHHJw/NrQEEiXTqqjzAOGWVTT0nBA9/WRKk HA1ckn8/I8AVz3bCNF1x4C+xFQkUSCrMhIjYUaskD5IEcFFzoDQ3T4rxrhaCVQz1VXKtc6 /8/ScmFC7kVUukBfu5R5db40n1JRmJjE9onL/F8usLcSN170hXMPdSQkMdJqfKj7vdygfm +Hyv2PVYccd17ptKr4WyQTQtYG5NIYbzVAFL1kAg9cgL1Fb5kX6kkjZfkt2G42l/Htsgbw pTpanlAdQ5VV6j7a8Qea/Ay8xKDL05VJcAcaLsmbFkDbIdfRAzlR+BCBkkd/lg== Date: Sun, 23 Jun 2024 19:27:43 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240623172743.GZ4991@pb2> References: <20240622151334.GD14140@haasn.xyz> <20240622171028.GB45562@haasn.xyz> <20240622195242.GX4991@pb2> <20240623002457.GB4285@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20240623002457.GB4285@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="===============3340080018852718617==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============3340080018852718617== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xd76R9tHJzDpbIo0" Content-Disposition: inline --xd76R9tHJzDpbIo0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 23, 2024 at 12:24:57AM +0200, Niklas Haas wrote: > On Sat, 22 Jun 2024 21:52:42 +0200 Michael Niedermayer wrote: > > 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= introducing > > > > > 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= like. If > > > > > there is broad agreement on this design, I will move on to an imp= lementation. > > > >=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 feed= back. > > > >=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 - us= ers > > > receive a correctly tagged AVFrame and manually forward this informat= ion > > > to the SwsContext. So, most of the time, moving to a fully AVFrame-ba= sed > > > 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 AVFr= ame > > > metadata. While changing that is possible, it possibly presents a big= ger > > > API break than simply introducing a new function. > >=20 > > I agree we should keep using the same swscale.h header. It matches the = library > > name thats installed (thats also what the user expects and what (s)he i= s used to), > > and its what users #include today. > > Also its not a audio? scaler so the A is confusing. > >=20 > > And sws_scale_frame() should be used obviously if thats as you say does > > "maximize the transition comfort" > >=20 > > 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 > >=20 > > 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= someone > > to try the new fully stateless system. >=20 > This could definitely work. We could then also eventually flip the > condition to where the new behavior becomes the default, and you need to > set a flag to *disable* it. >=20 > And eventually deprecate sws_init_context(), sws_setCoefficients() etc. > altogether and just have sws_alloc_context() + sws_scale_frame() be the > preferred front-ends. >=20 > I expect the actual amount of work to be similar; rather than taking > SwsContext and pulling everything high-level out into AVScaleContext, we > start with SwsContext and pull everything low-level out into separate > sub-contexts (e.g. one SwsScaleContext for each individual scaling > step). Yes, i prefer this thanks alot [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott --xd76R9tHJzDpbIo0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZnhbCwAKCRBhHseHBAsP q9riAKCS72+jdKKUCBdJOj8rkinzajy98QCeNuYeZlqqHgHfO0RMI6gNo/FyhP8= =HxDZ -----END PGP SIGNATURE----- --xd76R9tHJzDpbIo0-- --===============3340080018852718617== 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". --===============3340080018852718617==--