Open philipl opened 11 months ago
Auto Created VSMGWL-67202 for further analysis.
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.
Which component impacted?
Video Processing
Is it regression? Good in old configuration?
No, this issue exist a long time
What happened?
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 (385f5cf58f23bf4580c361a9b99f7956a88425ee)
Do you want to contribute a patch to fix the issue?
None