[FFmpeg-user] can swscale handle AV_PIX_FMT_YUV444P input/output?

[Andrew Randrianasulu]

https://www.cinelerra-gg.org/bugtracker/view.php?id=665

we run  into strange problem:

if cinelerra-gg  uses RGBA-8 format internally  we can process yuv444p
(full chroma) test sample made with

ffmpeg -f lavfi -i yuvtestsrc -frames 1 -color_range 2
/dev/shm/yuv-test.y4m

by rendering it to y4m (yuv444p pixel format) and then comparing two files
does not show big difference.

Yet if we switch our pipeline to yuv (8 bit, 4:4:4) result is totally off
(in YUVviewer) for same y4m render.

I looked in libswscale and can't see much handling for specifically

guest at slax:~/botva/src/mplayer/ffmpeg/libswscale$ grep "AV_PIX_FMT_YUV444P"
*.c
input.c:    case AV_PIX_FMT_YUV444P9LE:
input.c:    case AV_PIX_FMT_YUV444P10LE:
input.c:    case AV_PIX_FMT_YUV444P12LE:
input.c:    case AV_PIX_FMT_YUV444P14LE:
input.c:    case AV_PIX_FMT_YUV444P16LE:
input.c:    case AV_PIX_FMT_YUV444P9BE:
input.c:    case AV_PIX_FMT_YUV444P10BE:
input.c:    case AV_PIX_FMT_YUV444P12BE:
input.c:    case AV_PIX_FMT_YUV444P14BE:
input.c:    case AV_PIX_FMT_YUV444P16BE:
input.c:    case AV_PIX_FMT_YUV444P9LE:
input.c:    case AV_PIX_FMT_YUV444P10LE:
input.c:    case AV_PIX_FMT_YUV444P12LE:
input.c:    case AV_PIX_FMT_YUV444P14LE:
input.c:    case AV_PIX_FMT_YUV444P16LE:
input.c:    case AV_PIX_FMT_YUV444P9BE:
input.c:    case AV_PIX_FMT_YUV444P10BE:
input.c:    case AV_PIX_FMT_YUV444P12BE:
input.c:    case AV_PIX_FMT_YUV444P14BE:
input.c:    case AV_PIX_FMT_YUV444P16BE:
swscale_unscaled.c:    if ((srcFormat == AV_PIX_FMT_YUV444P || srcFormat ==
AV_PIX_FMT_YUVA444P) &&
swscale_unscaled.c:    if (dstFormat == AV_PIX_FMT_YUV444P &&
swscale_unscaled.c:        IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat,
AV_PIX_FMT_YUV444P9)  ||
swscale_unscaled.c:        IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat,
AV_PIX_FMT_YUV444P10) ||
swscale_unscaled.c:        IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat,
AV_PIX_FMT_YUV444P12) ||
swscale_unscaled.c:        IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat,
AV_PIX_FMT_YUV444P14) ||
swscale_unscaled.c:        IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat,
AV_PIX_FMT_YUV444P16))
utils.c:    [AV_PIX_FMT_YUV444P]     = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P16LE] = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P16BE] = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P9BE]  = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P9LE]  = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P10BE] = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P10LE] = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P12BE] = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P12LE] = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P14BE] = { 1, 1 },
utils.c:    [AV_PIX_FMT_YUV444P14LE] = { 1, 1 },
utils.c:        *format = AV_PIX_FMT_YUV444P;
utils.c:    case AV_PIX_FMT_YUVA444P:           return AV_PIX_FMT_YUV444P;
utils.c:    case AV_PIX_FMT_YUVA444P9BE:        return AV_PIX_FMT_YUV444P9;
utils.c:    case AV_PIX_FMT_YUVA444P9LE:        return AV_PIX_FMT_YUV444P9;
utils.c:    case AV_PIX_FMT_YUVA444P10BE:       return AV_PIX_FMT_YUV444P10;
utils.c:    case AV_PIX_FMT_YUVA444P10LE:       return AV_PIX_FMT_YUV444P10;
utils.c:    case AV_PIX_FMT_YUVA444P16BE:       return AV_PIX_FMT_YUV444P16;
utils.c:    case AV_PIX_FMT_YUVA444P16LE:       return AV_PIX_FMT_YUV444P16;

it seems input.c does not deal well with specifically this format? There is
no default case in switches ...

in swscale_unscaled I also mostly see specific yuv-nv12 wrappers, not
yuv444 standalone.

util.c is again declares what to do with >8 bpc yuv, mostly.

did I miss something important?

our ffmpeg mappings live at


https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/ffmpeg.C;h=9b8832dd718c94dd8b815edc7eb5c9d732953dd6;hb=HEAD

ps: non-ffmpeg png writer seems to output nearly exactly same png if I set
cingg to yuv8 or rgba8 internal processing. So, for same input test file as
long as libswscale did its job once on input -  pipeline itself does not
ruin video, as long as there was no second swscale ? unfortunately we do
not have direct yuv writer, so at the end our yuv444 transformed into rgba
for saving into tga or png or ppm by our routines.