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 E609A4A997 for ; Fri, 5 Jul 2024 21:34:18 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4672B68D95A; Sat, 6 Jul 2024 00:34:15 +0300 (EEST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5950968D7B1 for ; Sat, 6 Jul 2024 00:34:08 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 839FFE0002 for ; Fri, 5 Jul 2024 21:34:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1720215247; 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=FeJC1kLiPf3YBuwSlpSpm2UW8xGY8+/tOkFXM6EgYgs=; b=JpeNTUAHpAoH9HHTXWeF+Zpiul7myO8J6Vr6+xfKFtkeFaMZ1PBKDoETorZVCy1octwb/F nDcKBkhb4ALnsS87h5uNeBKhyhuj9TkF9Nrhhw+RA3pSTqJThWF1emmNW1SuKqZI00DEJ1 RogrK8RsqeVD4AxSd/MrXssMYS/2ob41UxTKSusrsLXe1l+Jk0yPvpa7+O7fTHnoeIDhil ppBJsuNcxkRoKbmYBmA8eTiFfubYazteMZCA3m5CVkgVlYCF0SwTaXSglICiSoYjK1T+RE 9oBN5pcEl62aZ2eA2eJ5j5NUnjjade0IaxQUi18Kda/6BrqYvFhGWWAm42tXtg== Date: Fri, 5 Jul 2024 23:34:06 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240705213406.GE4991@pb2> References: <20240622151334.GD14140@haasn.xyz> <20240702152700.GC15496@haasn.xyz> <20240703152558.GB29034@haasn.xyz> <20240705203117.GB297771@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20240705203117.GB297771@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="===============5068945325264610920==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============5068945325264610920== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mg8cdxx98+SFDaXr" Content-Disposition: inline --mg8cdxx98+SFDaXr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 05, 2024 at 08:31:17PM +0200, Niklas Haas wrote: > On Wed, 03 Jul 2024 15:25:58 +0200 Niklas Haas wrote: > > On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas wrote: > > =20 > > > 1. Is this a good idea, or too confusing / complex to be worth the ga= in? > > > Specifically, I am worried about confusion arising due to differen= ces > > > in behavior, and implemented options, between all of the above. > > >=20 > > > That said, I think there is a big win to be had from unifying all = of > > > the different scaling and/or conversion filters we have in e.g. > > > libavfilter, as well as making it trivial for users of this API to > > > try using e.g. GPU scaling instead of CPU scaling. > >=20 > > After prototyping this approach a bit (using an internal struct > > AVScaleBackend), I think I like it. It specifically makes handling > > unscaled special converters pretty straightforward, for example - the > > "unscaled" backend can be separate from the generic/scaling backend. > >=20 > > We could also trivially plug in something like libyuv, or some other > > limited-use-case fast path, without the user really noticing. >=20 > Small update: I decided to scrap the idea of separate user-visible > "backends" for now, but preserved the internal API boundary between the > avscale_* "front-end" and the actual back-end implementation, which > I have called 'AVScaleGraph' for now. >=20 > The idea is that this will grow into a full colorspace <-> colorspace > "solver", but for now it is just hooked up to sws_createContext(). >=20 > Attached is my revised working draft of . I dont agree to the renaming of swscale, that is heading toward [...] > /** > * The exact interpretation of these quality presets depends on the backe= nd > * used, but the backend-invariant common settings are derived as follows: > */ > enum AVScaleQuality { > AV_SCALE_ULTRAFAST =3D 1, /* no dither, nearest+nearest */ > AV_SCALE_SUPERFAST =3D 2, /* no dither, bilinear+nearest */ > AV_SCALE_VERYFAST =3D 3, /* no dither, bilinear+bilinear */ > AV_SCALE_FASTER =3D 4, /* bayer dither, bilinear+bilinear */ > AV_SCALE_FAST =3D 5, /* bayer dither, bicubic+bilinear */ > AV_SCALE_MEDIUM =3D 6, /* bayer dither, bicubic+bicubic */ > AV_SCALE_SLOW =3D 7, /* bayer dither, lanczos+bicubic */ > AV_SCALE_SLOWER =3D 8, /* full dither, lanczos+bicubic */ > AV_SCALE_VERYSLOW =3D 9, /* full dither, lanczos+lanczos */ > AV_SCALE_PLACEBO =3D 10, /* full dither, lanczos+lanczos */ I dont think its a good idea to hardcode dither and the "FIR" filter to the= quality level in the API [...] > /** > * Like `avscale_frame`, but operates only on the (source) range from `ys= tart` > * to `height`. > * > * @param ctx The scaling context. > * @param dst The destination frame. The data buffers may either be alr= eady > * allocated by the caller or left clear, in which case they= will > * be allocated by the scaler. The latter may have performan= ce > * advantages - e.g. in certain cases some (or all) output p= lanes > * may be references to input planes, rather than copies. > * @param src The source frame. If the data buffers are set to NULL, th= en > * this function behaves identically to `avscale_frame_setup= `. > * @param slice_start First row of slice, relative to `src`. Must be a > * multiple of avscale_slice_alignment(src). > * @param slice_height Number of (source) rows in the slice. Must be a > * multiple of avscale_slice_alignment(src). > * > * @return 0 on success, a negative AVERROR code on failure. > */ > int avscale_frame_slice(AVScaleContext *ctx, AVFrame *dst, > const AVFrame *src, int slice_start, int slice_he= ight); >=20 > /** > * Like `avscale_frame`, but without actually scaling. It will instead me= rely > * initialize internal state that *would* be required to perform the oper= ation, > * as well as returning the correct error code for unsupported frame > * combinations. > * > * @param ctx The scaling context. > * @param dst The destination frame to consider. > * @param src The source frame to consider. > * @return 0 on success, a negative AVERROR code on failure. > */ > int avscale_frame_setup(AVScaleContext *ctx, const AVFrame *dst, > const AVFrame *src); somewhat off topic as this is public API but the swscale filtering code could internally use libavutil/executor.h having filters and slices interdepend and need to execute them "in order" and parallel, maybe that API is usefull, not sure, just wanted to mention it thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope --mg8cdxx98+SFDaXr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZohmywAKCRBhHseHBAsP q/AtAJ4i8/6d2OZE9WkaqhF0ND8gmUUbpgCfddJ29IBMZb9LHTblOZIDsOSPUFI= =BxPj -----END PGP SIGNATURE----- --mg8cdxx98+SFDaXr-- --===============5068945325264610920== 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". --===============5068945325264610920==--