Add the functionality to automatically toggle the WIN HDR switch on and off #15919
Comments
|
Why would you need this? Just use --vo=gpu-next with --target-colorspace-hint=auto mpv will apply the corresponding colorspace. |
Because I have used: UHD disc players, the built-in player of the TV, CoreELEC boxes, and other players on the PC such as the 'Movies & TV' of WIN, potplayer, mpc-be, powerDVD, and renderers like madVR, mpc video render, D3D11, I know exactly what the correct picture should look like for HDR passthrough playback! Currently, the HDR images played by mpv, which automatically activates the HDR API of the graphics card (AMD and NVIDIA) are incorrect: the saturation overflows in window mode, and the colors fade in full-screen mode. Only when the WIN HDR switch is turned on does the HDR playback show the correct picture! mpv can very conveniently adjust the peak brightness of dynamic tone mapping, the mode of tone mapping, contrast recovery, and other parameters in real-time during HDR passthrough playback, and it has very low hardware requirements, so it already has the potential to be the best player on the PC! I am also very familiar with the HDR code for MPV: "target colorspace hint=yes", "hdr compute peak=auto", and various "tone mapping" parameters |
|
So turn it on.
I said use --target-colorspace-hint=auto. Apparently, you aren't familiar. |
|
d3d11 doesn't work. Which is recorded here. #11812 (comment) |
|
Better to read jeeb's comment #10158 (comment) |
If it is still true. How could other players did it? It's deprecated. It's better to forget it. |
|
Something must be clarified here HDR switch on Windows has never been a supported feature. This is true for neither D3D11, Vulkan, nor DXGI. Some people, out of ignorance or malice, claimed that Vulkan supports HDR switch, which is actually a driver bug, NVIDIA and AMD have fixed their drivers, so you will notice that this does not work. Other players' implementations use undocumented, private platform APIs. mpv should never use these. If you want HDR, just enable Windows HDR, don't try to switch automatically. |
My suggestion is that you first go and buy an HDR monitor, and then you'll understand the difference between "target-colorspace-hint=auto" and "target-colorspace-hint=yes"! Apparently, you don't have it and have no idea what the correct picture for HDR passthrough should look like! |
I have an OLED display that supports both Dolby Vision and HDR10. I have Windows HDR enabled 100% of the time. I use --target-colorspace-hint=auto, and I followed the issue report and subsequent developments that resulted in the And based on what everyone else here is telling you, you apparently are not understanding. Or just don't want to listen. |
You were talking about the different thing. My suggestion is stop meanless arguing and wait for devs' comment. |
|
The reason people are reluctant to enable HDR globally is that it changes the SDR hue, which is largely caused by the lack of HDR capability of their display. My suggestion is that you first go and buy an real HDR monitor. |
|
You should read the comments in the PR. Just make an auto-profile for either HDR or SDR and set the appropriate target-peak. Setting 203 or lower, the swapchain is configured for SDR (bt.709 colorspace), and 204 and above will be HDR (bt.2020). Set it and forget it. This is what I use and it works well. The easiest way to do this is set --target-peak=203, globally, then make an auto-profile for bt.2020 media and set the --target-peak for your display. I do it a a little differently because I use inverse tonemapping for bt.709 media. Dynamically switching Windows in and out of HDR is something I've never agreed with. With the right config, you don't need to. And by setting --target-colorspace-hint=auto, if you decide to disable Windows HDR, the colorspace will always be correctly configured. That was the point of auto. One and done! |
I have no interest in converting HDR to SDR for playback! If you have genuinely researched dynamic tone mapping in mpv, you should know that "target-peak=" should first be set to 10000 nits. This way, you can avoid any tone mapping (the default peak brightness for Windows displays is usually 1499 nits). Then, you gradually reduce the "target-peak=" value in nits until you find a level that matches your brightness perception while preserving as much highlight detail as possible. Therefore, it's quite obvious that the "203" nits value you mentioned is a rather laughable setting for your OLED TV and HDR passthrough playback! As for my mention of "hdr-compute-peak=auto," that was a typo on my part—it should have been "target-peak="! I hope you can understand what I'm saying! |
You didn't understand. HDR will be passed through. SDR will be played at 203 in a bt.709 colorspace. |
Unfortunately, if the WIN HDR switch is not forcibly turned on and HDR playback is attempted by automatically activating the graphics card's HDR API, although the TV's HDR status will be activated, the HDR playback image will be incorrect! Of course, if your graphics card (AMD or NVIDIA) driver is quite old, it might still work, but from what I understand, this should no longer be possible starting from 2021! |
|
OK. So here is one very basic way you can try what I'm suggesting. Turn Windows HDR on. Then try this basic config. So for HDR, I get this
And for everything else, I get this
I use different values because my display was calibrated by ASUS before I bought it.
|
My suggestion is that you use the built-in "Movies & TV" player in the Windows system. First, forcibly enable the Windows HDR switch, and then proceed to play HDR videos. This is the most error-free method for HDR playback! It is also the simplest way to determine whether your HDR pass-through playback is functioning correctly! |
I've played the same file in the Windows player at the same time in mpv and put them side by side, and there is no difference. |
I regret to inform you that I did not detect your AMD or NVIDIA dedicated graphics card! Additionally, my recommendation for you is: when setting up the optimal dynamic tone mapping scheme for mpv, it's best to use videos that feature sustained high-brightness scenes, such as the movies "Aquaman" or "The Meg." Furthermore, the "Spears & Munsil UHD" disc contains HDR and Dolby Vision demonstration videos that are genuinely mastered at 10,000 nits, and it also includes highly professional 10,000-nit videos designed to test PQ EOTF compliance! |
I have no such issues
|
Can you check your HDR screenshot and see if you have noticed: "avg 1.02 cd/M2"? How much tone mapping difference can you expect to see in a frame with an average brightness of only 1.02nit?
So why do you think you don't have this problem and nobody else does? |
I can't know that. I don't have access to their devices. |
Anyway, thank you very much for providing your MPV code, but your HDR profile judgment statement is still not rigorous. Let me show you mine: [HDR] This is the best initial setting for any HDR video, because at the current level of HDR film and television production, there is no need for dynamic tone mapping at all！ By the way, I have measured the true maxCLL and maxFALL of most HDR movies and TV shows, as well as the avgFALL of the entire movie and TV show! |
That's what --hdr-compute-peak is returning. The mastering display is 1000 nits, so that data is probably incorrect. It probably doesn't have a peak of 10,000 nits.
That was just a basic config. I use something different. You can be more precise with other params: https://mpv.io/manual/master/#command-interface-video-params/min-luma |
|
So use the metadata params that I linked to. |
|
|
There isn't much more I can offer here. Everything works well for me. Windows HDR shouldn't be switched on and off, as others have stated here. Microsoft doesn't want that. |
You're right, I checked chartGPT and found out that MPC Video renderer uses the DirectShow framework, specifically designed for the Windows platform, so this feature should not be implemented by MPV! This is really a pity! |
|
|
This is not related to DirectShow. If you search MSDN for This means that Microsoft reserves the right to change its intended behavior without prior notice, and if it does, the HDR Switch will break. Therefore, despite the simplicity of the implementation, mpv should not do this. If you can understand this, then it shouldn't be hard to understand why Microsoft wants you to always have Windows HDR/ACM enabled. |
|
It's trivial to implement this as cplugin for mpv. |
|
Could it be used in a lua script? That way if Microsoft breaks it, then no fix is required. |
If I keep the WIN HDR switch enabled all the time, its poor color gamut conversion is unbearable for most people's ordinary usage scenarios. Additionally, what should I do if I want to watch SDR videos? Let's shift our perspective: perhaps most people are accustomed to not forcibly enabling the WIN HDR switch, but they are unaware that the most stable and absolutely correct HDR passthrough playback in mpv requires the WIN HDR switch to be forcibly enabled first. And this is the crux of the issue! The WIN HDR switch has nothing to do with privacy, patents, copyrights, or system stability. I believe no one would turn HDR videos on and off more than 10 times in a minute—does this pose any potential risk to Microsoft? |
|
That toggles the Windows HDR switch. This guy thinks that using that gives an incorrect output. He thinks that the old-school way is better 🤪😂 |
Windows HDR's sRGB transfer function can be controversial, but it's usually not obvious. If you do care, there are some ugly but effective workarounds
Yes, mpv should indeed clarify in the documentation that for Windows, any form of HDR support requires Windows HDR as a prerequisite, there is no other workaround.
I don’t know what Microsoft’s specific thoughts are, but as Windows is a desktop operating system with broad hardware compatibility, in order to ensure a consistent HDR experience, it is natural to use HDR based on composition and tone mapping: Windows supports eDP, HDMI, DP and various other proprietary display protocols, but these protocols did not define how to output HDR and SDR signals at the same time. Due to force majeure factors such as DSC, there is a long re-handshakes time when you switch signal mode. Combining the two, if you want a seamless HDR experience, then the SDR colors have to be represented in the HDR colorspace, so tone-mapping has to be performed by the DWM, which then always outputs the HDR signal. |
I believe you can indeed use luajit FFI to operate it. |
I can't even take this seriously. Even if there were a disparity, I highly doubt that anyone has the visual acuity tell the difference. Most people will have cheap uncalibrated displays and shouldn't let the display tone-map. And if you did have a very expensive display that is professionally calibrated to your viewing environment, I think most people would just tell themselves they can see the difference. Not knowing what it was supposed to look like to begin with and not having the visual acuity to perceive the correct differences....should there be any. In my case, my display is calibrated by the manufacturer, ASUS. It has specific HDR color management that can't be altered by Windows. It says so in the settings. So I don't question it's color accuracy. The peak of the display is 617 nits, so almost all HDR is going to be tone-mapped, and I still prefer what @haasn and @kasper93 have done over letting the display do all of the tone-mapping. I've been studying that, recently. Watching when mpv tone-maps. My faith is in that. |
I'd suggest that if a change were to be made, someone should write that script. |
The focus of our discussion should be on the difference in risks between automatically turning the WIN HDR switch on and off during video playback versus manually turning it on before playback and manually turning it off after playback. Clearly, the risks are the same, but if I wanted to perform this operation 10 times within a minute, it would be impossible to do so manually! However, the risk of damage is something that an adult should be responsible for themselves! Additionally, I proposed this suggestion for another reason: if mpv relies solely on automatically activating the graphics card's HDR API to play HDR videos, the difference compared to correct HDR playback is not significant. However, those familiar with it can easily notice differences in brightness and color, which can create a false impression: that mpv's HDR passthrough playback quality is very poor! |
mpv Information
Other Information
Reproduction Steps
Before playing HDR videos, I must forcefully enable the WIN HDR switch; otherwise, HDR playback will result in errors. This is because, starting in 2021, both NVIDIA and AMD graphics card HDR API drivers have been changed. The current method that mpv uses to automatically activate the graphics card HDR API does not correctly play HDR videos. Only the WIN OS HDR method can play HDR content correctly.
Expected Behavior
Therefore, it is hoped that mpv will add the following feature:
Currently, the MPC Video Renderer has a similar function: win hdr ---Allow turn on/off,It is very convenient to play HDR video！
Actual Behavior
Add a code:-- WIN-HDR-auto<yes|no>
Log File
1
Sample Files
1
I carefully read all instruction and confirm that I did the following:
--log-file=output.txt.The text was updated successfully, but these errors were encountered: