Corrupted mastering display primaries (degenerate gamut) cause severe color/luma distortion

[Lamfeto]

mpv Information

mpv v0.41.0-dev-g41f6a6450 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Dec 21 2025 19:30:47
libplacebo version: v7.358.0
FFmpeg version: f853d12
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Other Information

- Microsoft Windows 11 [version 10.0.26200.8737]
- GPU model, driver and version: NVIDIA GeForce RTX 3080 (Driver: 610.88)
- Source of the mpv binary: GitHub (mpv v0.41.0-dev-g41f6a6450)
- Latest known working version: this is not a regression, but an unhandled edge-case with degenerate mastering primaries
- Issue started after the following happened: Playing a video file with corrupted/degenerate mastering display primaries metadata (blue primary coordinates matching the D65 white point)

Reproduction Steps

1. Play the provided sample using gpu-next with default/clean settings:
   mpv --no-config --vo=gpu-next sample.m2ts
2. Press i (or Shift+I then 2) to open stats.lua and inspect the colorimetry details.
3. Observe that the video reports degenerate primaries: Primaries: [0.708 0.292, 0.170 0.797, 0.313 0.329, 0.313 0.329] in bt.2020 (the blue primary is corrupted and matches the D65 white point).
4. Observe the resulting severe rendering distortion (blown-out highlights, black crush, and loss of color balance) in both SDR tone-mapping and HDR passthrough modes.
5. Attempting to override the stream primaries via --vf=format=primaries=bt.2020 does NOT fix the issue, as gpu-next / libplacebo continues to use the corrupted ST 2086 mastering display metadata attached to the video frames.

Expected Behavior

libplacebo / mpv should implement a sanity check on mastering display chromaticity coordinates:

1. Verify that the chromaticity coordinates form a valid, non-degenerate triangle (non-zero area, blue primary != white point).
2. If the mastering display primaries are degenerate/invalid or produce an ill-conditioned color transformation matrix, gpu-next should discard the broken mastering metadata and gracefully fall back to the nominal container primaries (bt.2020).
3. (Optional / Quality of life) Provide a way to ignore or override bad mastering metadata (e.g. --hdr-metadata=no or similar).

Actual Behavior

gpu-next evaluates the degenerate mastering primaries matrix without validation, producing severe color corruption (extreme solarization / clipping). Because the metadata is attached at the frame/decoder level, user-side format filters cannot override it.

Log File

mpv.log

Sample Files

Sample file : https://www.mediafire.com/file/awsijs1e4ligx8l/sample.zip/file

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[ValeZAA]

Attempting to override the stream primaries via --vf=format=primaries=bt.2020

You did not override anything, the primaries on your video already are bt.2020. Mastering display primaries are what original display for this used when mastering was done, and it just asks to cut some part of BT.2020 that is outside that display.