The order of parsed "Mastering display colour volume SEI message" seems wrong.

[SYamaguchi]

Summary of the bug:
The result of Mastering Display Colour Volume SEI message is not correct.
The order of RGB is swapped. (In the example below, the value of red_x,y should be blue_x,y, green should be red, and blue should be green.)
Of course, I checked the binary of video file and confirmed that the data is right.

I tested other video but it was okay, so I attach the video which the error occured.

How to reproduce:

% ffprobe 250207_Wrong_Display_Metadata_HEVC.mp4 -show_entries side_data=red_x,red_y,green_x,green_y
,blue_x,blue_y,white_point_x,white_point_y -report
ffprobe started on 2025-02-07 at 11:35:46
Report written to "ffprobe-20250207-113546.log"
Log level: 48
ffprobe version 6.0-essentials_build-www.gyan.dev Copyright (c) 2007-2023 the FFmpeg developers
  built with gcc 12.2.0 (Rev10, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libvpl --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '250207_Wrong_Display_Metadata_HEVC.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf61.1.100
  Duration: 00:00:27.65, start: 0.000000, bitrate: 5709 kb/s
  Stream #0:0[0x1](und): Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 1920x1080 [SAR 1:1 DAR 16:9], 5833 kb/s, 23.98 fps, 23.98 tbr, 1200k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavf58.29.100
  Stream #0:1[0x2]: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 2 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
[PACKET]
[SIDE_DATA]
[/SIDE_DATA]
[/PACKET]
[PACKET]
[/PACKET]
[FRAME]
[SIDE_DATA]
red_x=7049/50000
red_y=2445/50000
green_x=33905/50000
green_y=15945/50000
blue_x=11825/50000
blue_y=35240/50000
white_point_x=15634/50000
white_point_y=16450/50000
[/SIDE_DATA]

[SYamaguchi]

logfile when the command run

[SYamaguchi]

Video sample which the error occurs

[James]

The ordering of values in the mdcv SEI message is GBR as per the spec:

For describing mastering displays that use red, green, and blue colour primaries, it is suggested that index value c equal to 0 should correspond to the green primary, c equal to 1 should correspond to the blue primary, and c equal to 2 should correspond to the red colour primary

And this is what's coded and therefore exported:

[trace_headers @] Mastering Display Colour Volume
[trace_headers @] 32          display_primaries_x[0]                       1000010001110001 = 33905
[trace_headers @] 48          display_primaries_y[0]                       0011111001001001 = 15945
[trace_headers @] 64          display_primaries_x[1]                       0010111000110001 = 11825
[trace_headers @] 80          display_primaries_y[1]                       1000100110101000 = 35240
[trace_headers @] 96          display_primaries_x[2]                       0001101110001001 = 7049
[trace_headers @] 112         display_primaries_y[2]                       0000100110001101 = 2445
[trace_headers @] 128         white_point_x                                0011110100010010 = 15634
[trace_headers @] 144         white_point_y                                0100000001000010 = 16450
[trace_headers @] 160         max_display_mastering_luminance  00000000100110001001011010000000 = 10000000
[trace_headers @] 192         min_display_mastering_luminance  00000000000000000000000000000001 = 1

If the values are wrong, then whatever generated the SEI message for this sample is at fault, not ffmpeg's decoder. More so considering that the Content Light Level Information SEI message is suspiciously all zeroes.

[Tom Hebb]

I just ran into this issue as well, as it stops most of mpv's gamut mapping modes from working for videos with non-GBR ordering. I don't agree that videos with non-GBR ordering are out of spec, though: the spec only says that GBR ordering is "suggested", and the ​video that I'm having trouble with is one of DASH-IF's official HEVC test vectors.

For what it's worth, GStreamer does the same thing as FFmpeg and ​assumes GBR ordering, but mediainfo ​detects which primary is which. I can't find other open source tools that actually care about the primaries, but there's clearly not a consensus.