[FFmpeg-devel] [PATCH v3 14/18] swscale/graph: add new high-level scaler dispatch mechanism
Niklas Haas
ffmpeg at haasn.xyz
Thu Oct 24 23:33:26 EEST 2024
On Thu, 24 Oct 2024 13:08:36 +0200 Anton Khirnov <anton at khirnov.net> wrote:
> Quoting Niklas Haas (2024-10-24 12:02:41)
> > On Thu, 24 Oct 2024 11:30:12 +0200 Anton Khirnov <anton at khirnov.net> wrote:
> > > Does this (or can it) support copy-free passthrough of individual
> > > planes, for cases like YUV420P<->NV12?
> >
> > Not currently, no. We could switch to AVBufferRefs for the plane pointers to
> > add this functionality down the line, but it's not a high priority because
> > doing this will require the much harder problem of rewriting the underlying
> > scaler dispatch logic to begin with.
> >
> > Doing this would not be terribly difficult either way, but the problem is that
> > swscale currently does not exactly have a good concept of what's happening
> > to each plane - it's all a jumble of ad-hoc cases.
> >
> > One of my plans for SwsGraph is to first make a list of operations to perform
> > on each plane, and then eliminate reduntant passes to figure out what special
> > cases and/or noop passes can be optimized. But this has to wait a bit, as I'm
> > first working on the immediate goal of adding support for more complex
> > colorspaces (by chaining together multiple scaling passes).
>
> Right, as long as it's reasonably implementable down the line I have no
> objections. My concern was mainly about locking ourselves into a
> high-level API that does not allow this, and this constraint then
> propagating into the lower-level implementations.
The public API explicitly documents this behavior. The idea is for users to
call `sws_scale_frame` on a dst frame that has no data pointers allocated.
>
> --
> Anton Khirnov
More information about the ffmpeg-devel
mailing list