HDR video appears dull and incorrect when unpaused or switched to fullscreen

[tofu-dreg]

mpv Information

mpv v0.39.0-dev-ga8f5beb5a Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Mar 14 2025 16:09:38
libplacebo version: v7.350.0
FFmpeg version: 7d1c1d5
FFmpeg library versions:
   libavcodec      61.19.101
   libavdevice     61.3.100
   libavfilter     10.4.100
   libavformat     61.7.100
   libavutil       59.39.100
   libswresample   5.3.100
   libswscale      8.3.100

Other Information

- Windows version: Microsoft Windows [Version 10.0.26100.3476] (Windows 11)
- GPU model, driver and version: Nvidia 4070 Ti,  driver ver. 572.70
- Source of mpv: first party builds (mpv-x86_64-windows-msvc) -- however shinchiro and zhongify builds exhibit same issue
- Latest known working version: Unknown (I only acquired an OLED monitor yesterday)
- Issue started after the following happened: Unknown (same as above)

Reproduction Steps

Opening the HDR video in mpv and pausing it, then unpausing it and/or switching to fullscreen

Expected Behavior

mpv plays HDR video with correct looking brightness and TRC

Actual Behavior

When playing HDR videos via Chrome (whether via Youtube or playing the downloaded webms in Chrome directly), the video appears correct with very bright highlights and correct looking EOTF with proper detail visibility, whether paused or unpaused or windowed/fullscreened.

In mpv, the video only appears 'correct' (i.e. matching Chrome) while paused and windowed; upon unpausing the video or switching to fullscreen, it becomes duller looking with less highlight brightness, less vivid colours and some kind of wrong looking EOTF that makes detail visibility worse. Additionally, while windowed and paused, the video will momentarily flash to the duller look while the "Screenshot: filename.etc" message is visible in the top left corner, and will also momentarily flash to the duller look when moving the mouse away from the focused window.

Additional information:

• This issue occurs across multiple HDR videos that I've tested, not just the one used in this output.txt
• I tried adjusting d3d11-exclusive-fullscreen=yes/no to no avail
• I tried gpu-api=vulkan to no avail
• I tried --no-config to see if I could locate the cause via reintroducing my config options one by one, but the issue occurs in some form or another even with no config at all, albeit exhibiting itself differently, but always exhibiting some noticeable difference in gamma/visible detail between windowed and fullscreen modes or paused/unpaused
• I tried disabling fullscreen optimisations on mpv.exe
• I tried disabling G-sync in nvidia control panel and VRR in monitor OSD
• I tried disabling Nvidia overlay via NVApp
• I tried setting icc-profile-auto=yes/no
• I tried searching for similar issues and found a few earlier github threads relating to windowed-fullscreen differences, but nothing that pertained exactly to my issue or could solve it

Screenshots: I was unable to get screenshots to work in a way where they usefully showed any difference. With screenshot-format=avif, the screenshots produced were entirely red and looked identical to each other anyway. I suspect tonemapped SDR screenshots would also fail to capture the observed difference, but if anyone knows how to configure the screenshot options in such a way that they can produce useful information I'll be happy to give it a try.

OBS recording: I tried taking an OBS recording with HDR settings to see if it could capture the difference, but strangely the issue did not show up in the recording, with the sample video appearing correct at all times in the recording when moused over and toggled between windowed and fullscreen and/or paused-unpaused (I used Chrome to view the OBS recording)

Log File

output.txt

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.
• [x] I attached the backtrace in the case of a crash.

[kasper93]

Set target-colorspace-hint option to auto or yes.

[tofu-dreg]

Set target-colorspace-hint option to auto or yes.

Doesn't do anything. In the mean time I found that vo=gpu fares better and displays HDR properly while unpaused and fullscreen, but it has other issues like SDR-in-HDR video playback appearing extremely bright/corrupted when paused (but not while playing).

[Doofussy2]

This might be a Windows issue. Do you have multiple GPUs? An iGPU as well your Nvidia? If yes, go into your Windows display settings and specify using your Nvidia GPU for mpv and don't let Windows decide. Windows seems to have a hiccup with the window management when multiple GPUs are present.

[tofu-dreg]

This might be a Windows issue. Do you have multiple GPUs? An iGPU as well your Nvidia? If yes, go into your Windows display settings and specify using your Nvidia GPU for mpv and don't let Windows decide. Windows seems to have a hiccup with the window management when multiple GPUs are present.

Forcing mpv to dGPU in windows display settings had no effect.

[Doofussy2]

What if you specify the adapter in mpv?

https://mpv.io/manual/master/#options-d3d11-adapter

[tofu-dreg]

What if you specify the adapter in mpv?

https://mpv.io/manual/master/#options-d3d11-adapter

No effect.

[Doofussy2]

Try disabling --video-sync

[tofu-dreg]

Try disabling --video-sync

No effect.

[Doofussy2]

Have you tried running it from the commandline?

--no-config --vo=gpu-next --target-colorspace-hint=yes

[tofu-dreg]

Have you tried running it from the commandline?

--no-config --vo=gpu-next --target-colorspace-hint=yes

That doesn't work either. I did spend quite a bit of time starting from --no-config and trying to isolate problem options, but it seems that gpu-next doesn't want to play nice no matter what.

[Doofussy2]

I can't reproduce this. With vo_gpu I get similar results. I always have. But with gpu-next, I get stable results. With vo_gpu, I have to set colorspace and trc. So using vo_gpu and setting --target-prim=bt.2020 --target-trc=pq it would stabilize.

[Andarwinux]

I'm not sure exactly what the cause is, but disabling MPO may help debug the issue.

[tofu-dreg]

I'm not sure exactly what the cause is, but disabling MPO may help debug the issue.

Great idea. I tried disabling MPOs via the reg edits on this page: https://nvidia.custhelp.com/app/answers/detail/a_id/5157/%7E/after-updating-to-nvidia-game-ready-driver-461.09-or-newer%2C-some-desktop-apps

And now HDR looks correct while playing (i.e. unpaused) in windowed mode. However, it still becomes dull when switching to fullscreen. At least this is progress.

[Andarwinux]

It seems that for some reason there is a difference in tone-mapping between Composed Flip and Independent Flip. I'm not sure if this is a Microsoft or NVIDIA problem, and I've been unable to reproduce this myself. As a workaround, you should be able to make windowed fullscreen fallback to the Composed Flip with some overlays?

[tofu-dreg]

It seems that for some reason there is a difference in tone-mapping between Composed Flip and Independent Flip. I'm not sure if this is a Microsoft or NVIDIA problem, and I've been unable to reproduce this myself. As a workaround, you should be able to make windowed fullscreen fallback to the Composed Flip with some overlays?

Indeed, re-enabling MPO restored the previous behaviour. I also noticed that opening the start menu with win key while the video is fullscreen will revert to correct looking HDR (for as long as the start menu is open). So it clearly has something to do with window management.

[Doofussy2]

From your description, the metadata appears to be getting lost. So, possibly related ro how mpv establishes the swapchain? I still have an unresolved issue relating to that from several years ago. But I've never experienced it with gpu-next.

[tofu-dreg]

From your description, the metadata appears to be getting lost. So, possibly related ro how mpv establishes the swapchain? I still have an unresolved issue relating to that from several years ago. But I've never experienced it with gpu-next.

The HDR only looks partially broken however. It still looks like HDR video (much brighter highlights than watching the same video in tonemapped SDR, at least), just not good and broken looking HDR. Could that be the case if the metadata is getting lost? I've finally recorded a video that shows the difference clearly, maybe this is useful information. The exposure on the video is quite right so the bright region detail loss you can see is exactly what I see in person:

https://github.com/user-attachments/assets/81c56188-1600-4d61-b78d-fce519d78511

[Doofussy2]

That looks like its switching between passthrough and being tone-mapped. Look at the peak difference in the collar. That suggests to me that this is related to the swapchain. Either momentarily being defeated, or being put in the background somehow. When you pause playback, what happens if you use frame advance >

[Doofussy2]

Might this have something to do with --d3d11-flip ?

[tofu-dreg]

That looks like its switching between passthrough and being tone-mapped. Look at the peak difference in the collar. That suggests to me that this is related to the swapchain. Either momentarily being defeated, or being put in the background somehow. When you pause playback, what happens if you use frame advance >

Frame advance appears as normal unless I hold > down, then it looks wrong.

As for --d3d11-flip, I get these errors with it set to no (and the resulting output looks extremely washed out):

[vo/gpu-next/d3d11] Color space RGB_FULL_G2084_NONE_P2020 (12) is not supported by this swapchain! [vo/gpu-next/libplacebo] New swap chain configuration was deemed not supported: format: supported, color space: unsupported. Failling back to 8bit RGB. [vo/gpu-next/libplacebo] New swap chain configuration was deemed not supported: format: supported, color space: unsupported. Failling back to 8bit RGB. [vo/gpu-next/libplacebo] New swap chain configuration was deemed not supported: format: supported, color space: unsupported. Failling back to 8bit RGB. ...

[Doofussy2]

As for --d3d11-flip, I get these errors with it set to no (and the resulting output looks extremely washed out)

I wasn't suggesting to disable it, instead that there maybe was a bug with its operation. Disabling it will revert to tonemapping.

Frame advance appears as normal unless I hold > down, then it looks wrong.

That was kinda what I was expecting. That sample you're using has a frame rate of 60, so you likely won't see changes every frame. But you are seeing changes, as I have in the report I made a few years ago. If you play a video with 23 fps, and frame advance, is the issue more noticeable?

[tofu-dreg]

As for --d3d11-flip, I get these errors with it set to no (and the resulting output looks extremely washed out)

I wasn't suggesting to disable it, instead that there maybe was a bug with its operation. Disabling it will revert to tonemapping.

Frame advance appears as normal unless I hold > down, then it looks wrong.

That was kinda what I was expecting. That sample you're using has a frame rate of 60, so you likely won't see changes every frame. But you are seeing changes, as I have in the report I made a few years ago. If you play a video with 23 fps, and frame advance, is the issue more noticeable?

Things just got a bit weirder. I downloaded this 24fps HDR video "Samsung Extreme Sports UHD 4K Demo.ts" and now the opposite problem occurs: while windowed and paused, the video appears wrong (same dull highlights and bright region detail loss as the other video) whereas playing the video or switching it to fullscreen (whether playing or paused) causes it to look correct. As for frame advance, it is also the opposite of before, with single frame advances having no effect while holding > will restore the correct look of the video.

[Doofussy2]

I think this is related to the issue I reported years ago, and I'm now suspecting it has something to do with --d3d11-flip and the swapchain. Much has changed since then, but to my knowledge, those haven't. For me, it is only with vo_gpu, but I suspect it has the same root cause.

[tofu-dreg]

Small update: I finally tested MPC-HC (with MPC Video Renderer) and have the exact same issue. However VLC (vlc-4.0.0-dev-win64-c26a50fa, set to D3D11 renderer) and of course Chrome/Edge are fine.

[tofu-dreg]

I've been reading through other issues today and discovered this: https://github.com/mpv-player/mpv/issues/15175

Could it be that fullscreen mode is successfully passing HDR metadata untouched, leaving it to the internal tonemapping of my display (27GS93QE) which is why it looks bad? Bad internal tonemapping on this display? Therefore not an mpv issue?

Chrome and vo=gpu not exhibiting this "issue" maybe because they are not passing untouched metadata and it's getting tonemapped by Windows DWM or the program itself first?

[Doofussy2]

I've been reading through other issues today and discovered this: #15175

Could it be that fullscreen mode is successfully passing HDR metadata untouched, leaving it to the internal tonemapping of my display (27GS93QE) which is why it looks bad? Bad internal tonemapping on this display? Therefore not an mpv issue?

Chrome and vo=gpu not exhibiting this "issue" maybe because they are not passing untouched metadata and it's getting tonemapped by Windows DWM or the program itself first?

You could experiment by lowering the target-peak and watch the stats on page 2. It'll show you when mpv is tone-mapping..

[tofu-dreg]

I've been reading through other issues today and discovered this: #15175 Could it be that fullscreen mode is successfully passing HDR metadata untouched, leaving it to the internal tonemapping of my display (27GS93QE) which is why it looks bad? Bad internal tonemapping on this display? Therefore not an mpv issue? Chrome and vo=gpu not exhibiting this "issue" maybe because they are not passing untouched metadata and it's getting tonemapped by Windows DWM or the program itself first?

You could experiment by lowering the target-peak and watch the stats on page 2. It'll show you when mpv is tone-mapping..

Hmm. I have to set target-peak=10000 to avoid mpv tone mapping, but even then the same behaviour is exhibited (wrong image fullscreen, only windowed+paused correct image and it's broken by mouse movement/osd etc). And vo=gpu won't tone map (according to stats page 2 at least) at all even with target-peak=10000.

[Doofussy2]

What happens if you use --ontop with --d3d11-exclusive-fs

[tofu-dreg]

What happens if you use --ontop with --d3d11-exclusive-fs

Still lost highlights/lost detail as usual.

[Jerrk]

I believe i have the same or very similar issue where in fullscreen the colours are off but in windowed mode the colours are correct.

I can also "fix" the colours in fullscreen if i open the start menu or if i change the volume, or even if i render on top a 1px window somewhere on the display.

i dont have the issue where the colours break when unpausing the video.

I've tried to troubleshoot this specific issue and for me it seems to be connected to the target-colorspace-hint option, if set to no the colours are always off, but if set to yes the issue is as above.