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

Reproduce the problem with mpv --no-config --vo=gpu-next sample.m2ts and inspect the reported primaries in stats.lua. Trace how gpu-next and libplacebo consume the frame-level mastering metadata, then verify that invalid or degenerate primaries fall back to nominal bt.2020 without distortion in SDR tone-mapping and HDR passthrough.

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.