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

### 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 (385f5cf58f23bf4580c361a9b99f7956a88425ee)

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

None