[Bug]: 422p and 440p conversions appear to be buggy

[philipl]

Which component impacted?

Video Processing

Is it regression? Good in old configuration?

No, this issue exist a long time

What happened?

ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i video-x264-8bit-420.mp4 -vf scale_vaapi=format=yuv422p,hwdownload,format=yuv422p output.mp4

This command line demonstrates the bug, and doesn't require #1708.

It takes a normal video that is decoded to a functional format (nv12 in this case) and then converts it to yuv422p (422H), which we then download and encode in software. The resulting video frames have mangled chroma as shown in the screenshot:

Conversion to yuv440p (422V) is also buggy and in a consistent way (the green area is on the right instead of the bottom).

What's the usage scenario when you are seeing the problem?

Transcode for media delivery, Playback

What impacted?

Playback of 8bit 4:2:2 content (eg: hevc) in mpv. mpv cannot directly display packed yuyv422, so we need to do a conversion. Normally, this conversion is done to XYUV (a 4:4:4 format) but after #1708, yuv422p will appear as a valid conversion target, and will be preferred, because it has matching subsampling. The buggy conversion then puts a bad image on the screen for the user.

Debug Information

Compiled using latest master (385f5cf)

Do you want to contribute a patch to fix the issue?

None

[intel-mediadev]

Auto Created VSMGWL-67202 for further analysis.

[MicroYY]

As I know, 422H/422V is neither supported as VP output, nor as encode input format.
Refer to https://github.com/intel/media-driver/blob/master/docs/media_features.md

ffmpeg configuration depends on driver capability which means it should report error for unsupported format. For this case no configuration error is found. We will check current caps settings and fix potential issues.