[FFmpeg-devel] [PATCH v3 14/18] swscale/graph: add new high-level scaler dispatch mechanism
Anton Khirnov
anton at khirnov.net
Fri Oct 25 11:37:43 EEST 2024
Quoting Niklas Haas (2024-10-24 22:33:26)
> 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.
I meant the graph API you're adding here, not the actual public API.
--
Anton Khirnov
More information about the ffmpeg-devel
mailing list