[FFmpeg-trac] #10768(avformat:new): Divergent interpretation of YUV4MPEG2 "C" parameter

[FFmpeg]

#10768: Divergent interpretation of YUV4MPEG2 "C" parameter
-------------------------------------+-------------------------------------
             Reporter:  Mingye Wang  |                     Type:  defect
               Status:  new          |                 Priority:  wish
            Component:  avformat     |                  Version:  git-
             Keywords:  YUV4MPEG2    |  master
  y4v avchroma                       |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 **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?
 [https://github.com/FFmpeg/FFmpeg/blob/e9c93009fc34ca9dfcf0c6f2ed90ef1df298abf7/libavformat/yuv4mpegdec.c#L110C56-L110C56
 yuv4mpegdec.c:pix_fmt_array] says a C422 and a C411 should be
 {{{AVCHROMA_LOC_UNSPECIFIED}}}. However, the original
 [https://manned.org/yuv4mpeg.5 man page] specifies that they are co-sited,
 which would translate to {{{AVCHROMA_LOC_TOPLEFT}}}.

 **Disagreement 2.** What's a C420paldv?
 [https://github.com/FFmpeg/FFmpeg/blob/e9c93009fc34ca9dfcf0c6f2ed90ef1df298abf7/libavformat/yuv4mpegdec.c#L92
 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
 [https://chromium.googlesource.com/webm/libvpx/+/refs/heads/main/y4minput.c#310
 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,
 [https://github.com/FFmpeg/FFmpeg/blob/e063c1d079086150580ed7a9ad076da122e27f76/libavcodec/h2645_vui.c#L80
 libavcodec/h2645_vui.c] fails to deal with the bottom field location.)

 The issue also persists to the encoding side:
 [https://github.com/FFmpeg/FFmpeg/blob/e063c1d079086150580ed7a9ad076da122e27f76/libavformat/yuv4mpegenc.c#L107
 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.
 *
 [https://github.com/xiph/rav1e/blob/4a72d17dc87759718d265f1f48192eef440f31b5/src/bin/decoder/y4m.rs#L106
 rav1e] says it should be co-sited like the C422 and C411 in the original
 standard.
 *
 [https://github.com/mozilla/aom/blob/46b7bb243b39929c02d6decc1bdb2e39e11540d6/y4minput.c#L812
 aom] says it should be the same as C420jpeg. But it's also derived from
 some
 [https://chromium.googlesource.com/webm/libvpx/+/refs/heads/main/y4minput.c#872
 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.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10768>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker