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

[Andrew Sayers]

On Mon, Jul 08, 2024 at 07:58:44AM -0400, Ronald S. Bultje wrote:
> On Sat, Jul 6, 2024 at 1:29 PM Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> > On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
[...]
> > > > 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.

That burden exists no matter what, documentation just puts it on the shoulders
of a small number of developers who understand the problem; instead of a large
number of users who have to hope an SO answer isn't out-of-date yet.

We often say e.g. "this struct currently has such-and-such members, but the
size is not part of the public API".  So it's not much of a stretch to say
"this preset enables such-and-such features, but the value is not part of the
public API".