Hi,
On Sat, Jul 6, 2024 at 1:29 PM Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
> <mich...@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
> > > <mich...@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-requ...@ffmpeg.org with subject "unsubscribe".
