Re: [FFmpeg-devel] [RFC]] swscale modernization proposal

["Ronald S. Bultje" <rsbultje@gmail.com>]

Hi,

On Sat, Jul 6, 2024 at 1:29 PM Hendrik Leppkes <h.leppkes@gmail.com> wrote:

> On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> > > On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > > > /**
> > > > >  * The exact interpretation of these quality presets depends on
> the backend
> > > > >  * used, but the backend-invariant common settings are derived as
> follows:
> > > > >  */
> > > > > enum AVScaleQuality {
> > > > >     AV_SCALE_ULTRAFAST = 1,  /* no dither,      nearest+nearest
>  */
> > > > >     AV_SCALE_SUPERFAST = 2,  /* no dither,      bilinear+nearest
>   */
> > > > >     AV_SCALE_VERYFAST  = 3,  /* no dither,      bilinear+bilinear
>  */
> > > > >     AV_SCALE_FASTER    = 4,  /* bayer dither,   bilinear+bilinear
>  */
> > > > >     AV_SCALE_FAST      = 5,  /* bayer dither,   bicubic+bilinear
>   */
> > > > >     AV_SCALE_MEDIUM    = 6,  /* bayer dither,   bicubic+bicubic
>  */
> > > > >     AV_SCALE_SLOW      = 7,  /* bayer dither,   lanczos+bicubic
>  */
> > > > >     AV_SCALE_SLOWER    = 8,  /* full dither,    lanczos+bicubic
>  */
> > > > >     AV_SCALE_VERYSLOW  = 9,  /* full dither,    lanczos+lanczos
>  */
> > > > >     AV_SCALE_PLACEBO   = 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
> > > >
> > >
> > > The entire point of presets is to have them provide a predefined set
> > > of parameters, easy for users to pick one value, rather than a bunch.
> > > And what a preset actually means should be documented.
> > > How do you define "presets" if they don't hardcode a list of choices
> > > for all the relevant options?
> > >
> > > Advanced settings exist for a user to select any particular detail, if
> > > they so desire.
> >
> > The problem is if new features are added and you have a hardcoded list in
> > the API what each quality corresponds to change it you have to bump major
> >
> > also, do we really have or want to have optimized nearest neighbor scaler
> > code ?
> > If not the AV_SCALE_ULTRAFAST could be slower than AV_SCALE_VERYFAST
> > simply because it now "has to" do something we actually have not
> optimized
> >
>
> So.. you object to the comments that explain what it does?
> Someone that uses presets will never have a guarantee to the selected
> algorithms and options
>

But then why did we provide this information? It's one thing to have it in
a stackoverflow answer re: a specific FFmpeg version, but in a header, it
feels much more ... burdening. Even if no actual API linkage occurred.

Ronald
_______________________________________________
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".