MPV not reading DV HDR Max/Avg value
mpv Information
mpv v0.40.0-389-g2412feaf4 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
built on Oct 10 2025 05:02:07
libplacebo version: v7.357.0 (v7.351.0-85-g63a3d64-dirty)
FFmpeg version: N-121416-g6f1ab828d
FFmpeg library versions:
libavcodec 62.16.100
libavdevice 62.2.100
libavfilter 11.9.100
libavformat 62.6.101
libavutil 60.13.100
libswresample 6.2.100
libswscale 9.3.100
Other Information
- Windows version: Windows 11 22621.1992
- GPU model, driver and version:
- Source of mpv: https://github.com/zhongfly/mpv-winbuild/releases/tag/2025-10-10-2412fea
- Latest known working version: https://github.com/zhongfly/mpv-winbuild/releases/tag/2025-09-13-d837c43 (https://github.com/mpv-player/mpv/commit/d837c43656876fb2fb7cbcf7e74bd438ba563217)
- Issue started after the following happened:
Reproduction Steps
Open a video that has Dolby Vision RPU in the bitstream.
Expected Behavior
The Max/Avg info is read from RPU.
Actual Behavior
It's measured by MPV.
Log File
Sample Files
No response
I carefully read all instruction and confirm that I did the following:
- [x] I tested with the latest mpv version to validate that the issue is not already fixed.
- [x] I provided all required information including system and mpv version.
- [x] 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. - [x] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
- [x] I attached the full, untruncated log file.
- [ ] I attached the backtrace in the case of a crash.
Works correctly on my end. We need a sample to reproduce this.
https://pixeldrain.com/u/PxoZPD8X
I'm confused now, this build from 09/08 also doesn't work. https://github.com/shinchiro/mpv-winbuild-cmake/releases/download/20250908/mpv-x86_64-v3-20250908-git-77dee9b.7z
mpv v0.40.0-301-g77dee9be2 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
built on Sep 8 2025 00:07:27
libplacebo version: v7.354.0 (v7.351.0-67-g515da95-dirty)
FFmpeg version: N-121008-gf4b044bbe
FFmpeg library versions:
libavcodec 62.15.100
libavdevice 62.2.100
libavfilter 11.8.100
libavformat 62.5.100
libavutil 60.12.100
libswresample 6.2.100
libswscale 9.3.100
But this one from 09/13 works. https://github.com/zhongfly/mpv-winbuild/releases/download/2025-09-13-d837c43/mpv-x86_64-v3-20250913-git-d837c43.7z
mpv v0.40.0-302-gd837c4365 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
built on Sep 11 2025 18:08:44
libplacebo version: v7.354.0 (v7.351.0-67-g515da95-dirty)
FFmpeg version: N-121039-ga4fd3f27f
FFmpeg library versions:
libavcodec 62.15.100
libavdevice 62.2.100
libavfilter 11.8.100
libavformat 62.5.100
libavutil 60.13.100
libswresample 6.2.100
libswscale 9.3.100
https://github.com/shinchiro/mpv-winbuild-cmake/commit/23e7ff758c26846422bb83109f03b7d692c271a0 related?
But the FFmpeg in these builds is clearly new enough.
Ok, I see the issue, will fix later.
Isn't it just because of profile 7 FEL never using the metadata?
Isn't it just because of profile 7 FEL never using the metadata?
What does this mean? I don't get it.
Isn't it just because of profile 7 FEL never using the metadata?
Yes, that's the difference. Currently with libdovi enabled we use scene metadata max_pq/avg_pq even when EL is present. While when libdovi disabled, we use scene metadata only when EL is not present. Note that in both cases we don't use mastering display metadata.
IMHO more correct is to not use RPU metadata as we do not use EL, the values may not be correct. This is what the current implementation does. While in some cases it might be useful to use metadata, I think best way would be to add an option for that.
See for context: https://github.com/haasn/libplacebo/blob/master/src/utils/dolbyvision.c#L39
Also there is https://github.com/haasn/libplacebo/pull/286 which fixes use of the metadata for some files.
we use scene metadata only when EL is not present.
I saw only profile 5 RPU gets used.
we do not use EL, the values may not be correct
More correct than MPV's measuring anyway... or at least, more stable.
This is blocked by libplacebo, let's not block 0.41 for this.