[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