[FFmpeg-devel] Towards YUVJ removal
Martin Storsjö
martin at martin.st
Wed Feb 15 11:30:14 EET 2023
On Fri, 9 Dec 2022, Niklas Haas wrote:
> So, as was discussed at the last meeting, we should move towards
> removing YUVJ.
Libswscale still does have cases where it doesn't work correctly, for some
conversions, unless differences in range is signalled with the YUVJ pixel
formats (this, despite that swscale itself warns that the user is
specifying the deprecated pixel formats).
Attached is a small testcase example, which uses swscale to convert from
YUV to YUV, with various color spaces and ranges. When converting from
limited to full range or vice versa, within the same colorspace, swscale
fails to realize that this isn't a no-op operation, unless the YUVJ
formats are used.
When running the attached test example, I get the following output
(modulo swscale warnings):
red 601 limited -> 601 full YUV 49,109,184 -> 38,106,192
red 601 full -> 601 limited YUV 38,106,192 -> 49,109,184
red 709 limited -> 709 full YUV 39,115,184 -> 27,113,192
red 709 full -> 709 limited YUV 27,113,192 -> 39,115,184
If the example is modified to always set yuv_{in,out}->format to
AV_PIX_FMT_YUV420P, then swscale no longer actually does any conversion:
red 601 limited -> 601 full YUV 49,109,184 -> 49,109,184
red 601 full -> 601 limited YUV 38,106,192 -> 38,106,192
red 709 limited -> 709 full YUV 39,115,184 -> 39,115,184
red 709 full -> 709 limited YUV 27,113,192 -> 27,113,192
So this is yet another small detail that needs to be fixed before we can
proceed towards actually removing the YUVJ formats.
// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yuv2yuv.c
Type: text/x-csrc
Size: 2789 bytes
Desc:
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230215/6a49ce21/attachment.c>
More information about the ffmpeg-devel
mailing list