Divergent interpretation of YUV4MPEG2 "C" parameter

[Mingye Wang]

Summary of the bug:
The way ffmpeg interprets the "C" field of Y4M is quite different from everybody else (vp9/av1 dialect, original dialect) does it in some ways.

How to reproduce:
Someone could make a test example that exploits the different pixel position interpretation, but it's not for me today. Let's just step into the two source files in libavformat.

Disagreement 1. What's a C422/C411?
​yuv4mpegdec.c:pix_fmt_array says a C422 and a C411 should be AVCHROMA_LOC_UNSPECIFIED. However, the original ​man page specifies that they are co-sited, which would translate to AVCHROMA_LOC_TOPLEFT.

Disagreement 2. What's a C420paldv?
​yuv4mpegdec.c:pix_fmt_array says a C420paldv should be a AV_PIX_FMT_YUV420P, AVCHROMA_LOC_TOPLEFT. However, this does not actually describe how PAL-DV siting (as required by the original man page) works: you actually have Y and R at top left, but B at "center" (see ​y4m_convert_42xpaldv_42xjpeg, also IEC 61834-2).

(Of course there is really no way to just specify a split chroma location with a single AVChromaLocation. For the same reason, ​libavcodec/h2645_vui.c fails to deal with the bottom field location.)

The issue also persists to the encoding side: ​yuv4mpegenc.c happily translates any 420 + topleft into C420paldv. This allows round-trip in ffmpeg, but could go wrong when you put in something that actually tries to do PAL-DV.

Disagreement 3. What's a C420?
The last major disagreement is on the definition of C420. This thing is not defined in the original standard.

• ffmpeg says it is AVCHROMA_LOC_CENTER, the same as C420jpeg.
• ​rav1e says it should be co-sited like the C422 and C411 in the original standard.
• ​aom says it should be the same as C420jpeg. But it's also derived from some ​libvpx code that treats C420mpeg2 the same as C420jpeg, so maybe it's not a good source of wisdom.

---

Now, the bottom line is that ffmpeg currently round-trips with itself, which might just be enough for a barely-defined format like y4m. These disagreements only affect interoperability with other implementations, which are not that interoperable with each other to start with.

[Balling]

However, the original ​man page specifies that they are co-sited, which would translate to AVCHROMA_LOC_TOPLEFT.

422 can be only center. Left is also center...

DV chroma is more complex. And yes, different chroma licayion in top and bottom fields are possible.

ffmpeg says it is AVCHROMA_LOC_CENTER

Well, it probably should depend on matrix. Bt.2020 mattix likes top-left, bt.709 left, jpeg (so full range BT.601) is center.