On Thu, 24 Oct 2024 13:08:36 +0200 Anton Khirnov <an...@khirnov.net> wrote: > Quoting Niklas Haas (2024-10-24 12:02:41) > > On Thu, 24 Oct 2024 11:30:12 +0200 Anton Khirnov <an...@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 _______________________________________________ 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".
