On Wed, 03 Jul 2024 15:25:58 +0200 Niklas Haas <ffmpeg@haasn.xyz> wrote:
> On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas <ffmpeg@haasn.xyz> wrote:
>  
> > 1. Is this a good idea, or too confusing / complex to be worth the gain?
> >    Specifically, I am worried about confusion arising due to differences
> >    in behavior, and implemented options, between all of the above.
> > 
> >    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.
> 
> 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.
> 
> We could also trivially plug in something like libyuv, or some other
> limited-use-case fast path, without the user really noticing.

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.

The idea is that this will grow into a full colorspace <-> colorspace
"solver", but for now it is just hooked up to sws_createContext().

Attached is my revised working draft of <avscale.h>.