i assume it's a duplicate of #4248.

It seems that they are separate issues. The difference in #4248 is subtle while it's significant in my case.

I believe Quicktime Player is able to utilize a new feature of Catalina which increases the brightness of the screen when playing HDR content.

quicktime and mpv look 'identically' if i use mpv --no-config. so i would assume quicktime doesn't do any tone mapping. if i use the settings you suggested my middle rectangle is completely clipped and nearly identically to the brightest one.

Sorry, forget about my setting. iina/iina#2705 has a better explanation of this situation.

so if you play both at the same time, in quicktime and mpv, they looks the 'same' brightness wise? since quicktime increases the screen brightness?

if the screen brightness really increased target-peak won't work because it would be dynamic in that case.

Nope. Only the Quicktime window would have higher brightness, although I'm not quite sure how that's achieved. Wonder if that's possible for mpv to adopt this function.

if it's not the screen but only that window, i can only think about a few possibilities. though i am not sure how this would fit into mpv's render pipeline.

1. https://developer.apple.com/documentation/quartzcore/caopengllayer/1521900-wantsextendeddynamicrangecontent
2. https://developer.apple.com/documentation/appkit/nsscreen/1388362-maximumextendeddynamicrangecolor
3. https://developer.apple.com/documentation/appkit/nsscreen/3180382-maximumreferenceextendeddynamicr
4. https://developer.apple.com/documentation/appkit/nsscreen/3180381-maximumpotentialextendeddynamicr

i would need to test this and maybe it would be helpful to know what those values output on your end.

I would like to help but I have no idea how to. Could you tell me how can I get these values?

i will have to write some small script for that. maybe next week when i am on vacation.

if you want you can test following script and paste me the output here:
https://gist.github.com/Akemi/67f7a566d758bb843cb2ae405feecfa1

call like:

swift hdr.swift

Thanks for your script. Here's my result:

When the video I mentioned is played with mpv / When nothing is played:
Color LCD
maximumPotentialExtendedDynamicRangeColorComponentValue: 2.0
maximumReferenceExtendedDynamicRangeColorComponentValue: 0.0
maximumExtendedDynamicRangeColorComponentValue: 1.0

Played with Quicktime:
Color LCD
maximumPotentialExtendedDynamicRangeColorComponentValue: 2.0
maximumReferenceExtendedDynamicRangeColorComponentValue: 0.0
maximumExtendedDynamicRangeColorComponentValue: 2.0

on a side note, i am still on 10.14 so i only get the last value. in both cases only mpv is playing or only quicktime is playing:

maximumExtendedDynamicRangeColorComponentValue: 1.0

so i guess it's most likely the reason why quicktime can be brighter (probably twice as much).

Great. Now we know what causes the difference.

Is there a way to implement this function? I guess Quicktime has done more than simply multiplying the brightness by 2.0. There is guessing that Quicktime utilize a system built-in tone mapping method. If so, would it be possible to adopt that? Or modify our own tone mapping to achieve similar effect?

like i said, i am not sure how this would fit into mpv's render pipeline (yet).

no we can't use the macOS tone mapping since we do our own, and yes quicktime most likely uses the system tone mapping since Apple provides a public API for that.

those values only remotely have something to do with tone mapping per se. note those values are called Extended Dynamic Range (EDR) and not HDR. this can even be helpful for none HDR content, in the case i understand everything correctly so far.

i am writing up a new test case.

Got it. Quicktime activates EDR when playing HDR videos, that's why I thought it's related to tone mapping. I'll WIP and see if I could help more.

i made a second test:
https://gist.github.com/Akemi/185d83afbef47c0c8e0add2a3c99b6d2

call like:

swift edr.swift

you can quit the script on the terminal with CTRL+C.

it should spawn two windows with 4 rectangles. 2 white rectangles, 1 gray and 1 black. on the left window both white rectangles should look the same. on the right window both white rectangles should be distinguishable. the bottom one should be the brighter one.

also please post the terminal output (without the deprecation warning) and possibly a screenshot. should look like this (on your screenshot the right white rectangles should be distinguishable):

----------------------------- BEFORE EDR REQUEST ------------------------------
DELL U2715H
maximumPotentialExtendedDynamicRangeColorComponentValue: -1.0
maximumReferenceExtendedDynamicRangeColorComponentValue: -1.0
maximumExtendedDynamicRangeColorComponentValue: 1.0
-------------------------------------------------------------------------------
--------- Layer with EDR: true ---------
Created CGL pixel format with attributes: kCGLPFAOpenGLProfile, kCGLOGLPVersion_3_2_Core, kCGLPFAAccelerated, kCGLPFADoubleBuffer, kCGLPFAColorSize, 64, kCGLPFAColorFloat, kCGLPFABackingStore, kCGLPFAAllowOfflineRenderers, kCGLPFASupportsAutomaticGraphicsSwitching, 0
--------- Layer with EDR: false ---------
Created CGL pixel format with attributes: kCGLPFAOpenGLProfile, kCGLOGLPVersion_3_2_Core, kCGLPFAAccelerated, kCGLPFADoubleBuffer, kCGLPFAColorSize, 64, kCGLPFAColorFloat, kCGLPFABackingStore, kCGLPFAAllowOfflineRenderers, kCGLPFASupportsAutomaticGraphicsSwitching, 0
------------------------------ AFTER EDR REQUEST ------------------------------
DELL U2715H
maximumPotentialExtendedDynamicRangeColorComponentValue: -1.0
maximumReferenceExtendedDynamicRangeColorComponentValue: -1.0
maximumExtendedDynamicRangeColorComponentValue: 1.0
-------------------------------------------------------------------------------

Wow, you're fast! Here's what I got:

----------------------------- BEFORE EDR REQUEST ------------------------------
Color LCD
maximumPotentialExtendedDynamicRangeColorComponentValue: 2.0
maximumReferenceExtendedDynamicRangeColorComponentValue: 0.0
maximumExtendedDynamicRangeColorComponentValue: 1.0
-------------------------------------------------------------------------------
--------- Layer with EDR: false ---------
Created CGL pixel format with attributes: kCGLPFAOpenGLProfile, kCGLOGLPVersion_3_2_Core, kCGLPFAAccelerated, kCGLPFADoubleBuffer, kCGLPFAColorSize, 64, kCGLPFAColorFloat, kCGLPFABackingStore, kCGLPFAAllowOfflineRenderers, kCGLPFASupportsAutomaticGraphicsSwitching, 0
--------- Layer with EDR: true ---------
Created CGL pixel format with attributes: kCGLPFAOpenGLProfile, kCGLOGLPVersion_3_2_Core, kCGLPFAAccelerated, kCGLPFADoubleBuffer, kCGLPFAColorSize, 64, kCGLPFAColorFloat, kCGLPFABackingStore, kCGLPFAAllowOfflineRenderers, kCGLPFASupportsAutomaticGraphicsSwitching, 0
------------------------------ AFTER EDR REQUEST ------------------------------
Color LCD
maximumPotentialExtendedDynamicRangeColorComponentValue: 2.0
maximumReferenceExtendedDynamicRangeColorComponentValue: 0.0
maximumExtendedDynamicRangeColorComponentValue: 1.492808222770691
-------------------------------------------------------------------------------

maximumExtendedDynamicRangeColorComponentValue after EDR request changed each time. From about 1.1 to 1.5. I guess it would gradually increase to 2.0 after opening the windows.

The screenshots look the same, but the bottom left rectangle in EDR activated window is actually brighter.

okay, so i at least got the right switch how to trigger the increase of the EDR value. it makes sense that it gradual increases the value, an abrupt value change would most likely look weird. you can test the final value with the first script i posted, if you want.

i guess the screenshot represents exactly what you see on your screen, eg you couldn't see a difference between the two white rectangles? which is too bad and i need to look into it a bit more.

on a side note, how does the white rectangle compare to the white rectangle in the test clip you posted when played back in quicktime? is it also less bright?

okay i updated my script here https://gist.github.com/Akemi/185d83afbef47c0c8e0add2a3c99b6d2

i additionally set the wantsExtendedDynamicRangeOpenGLSurface of the view. maybe that makes it work properly, if it didn't already.

would be nice if you could try again and let me know you findings, terminal output etc.

I tried the first script. When I manually toggled system brightness to maximum, the final value was 1.6666666269302368. Other than that, it was 2.0.

you couldn't see a difference between the two white rectangles?

The second script works! I could see the difference between the two white rectangles on my screen when EDR activated. They only look the same in the screenshot. (My poor English just betrayed me.) Still, I tried the third script and here's the result:

----------------------------- BEFORE EDR REQUEST ------------------------------
Color LCD
maximumPotentialExtendedDynamicRangeColorComponentValue: 2.0
maximumReferenceExtendedDynamicRangeColorComponentValue: 0.0
maximumExtendedDynamicRangeColorComponentValue: 1.0
-------------------------------------------------------------------------------
--------- Layer with EDR: true ---------
--------- View with EDR: true ---------
Created CGL pixel format with attributes: kCGLPFAOpenGLProfile, kCGLOGLPVersion_3_2_Core, kCGLPFAAccelerated, kCGLPFADoubleBuffer, kCGLPFAColorSize, 64, kCGLPFAColorFloat, kCGLPFABackingStore, kCGLPFAAllowOfflineRenderers, kCGLPFASupportsAutomaticGraphicsSwitching, 0
--------- Layer with EDR: false ---------
--------- View with EDR: false ---------
Created CGL pixel format with attributes: kCGLPFAOpenGLProfile, kCGLOGLPVersion_3_2_Core, kCGLPFAAccelerated, kCGLPFADoubleBuffer, kCGLPFAColorSize, 64, kCGLPFAColorFloat, kCGLPFABackingStore, kCGLPFAAllowOfflineRenderers, kCGLPFASupportsAutomaticGraphicsSwitching, 0
------------------------------ AFTER EDR REQUEST ------------------------------
Color LCD
maximumPotentialExtendedDynamicRangeColorComponentValue: 2.0
maximumReferenceExtendedDynamicRangeColorComponentValue: 0.0
maximumExtendedDynamicRangeColorComponentValue: 1.212622046470642
-------------------------------------------------------------------------------

Screenshot:

The second script works! I could see the difference between the two white rectangles on my screen when EDR activated. They only look the same in the screenshot. (My poor English just betrayed me.)

that's great. it wasn't your fault, i didn't see you write something beneath the screenshot that answered my question.

so everything works as expected. now i only need to find out how to integrate that into mpv itself. thanks for testing.

[edit]
probably need to add support for this in a different way because we don't have an internal way of supporting it the way we tested it.

since they use libmpv and most likely one of the opengl layers flavours they can do whatever they want and use the OS'/layers hdr capabilities, similar to this PR #8485. though i think i explained it somewhere on a different open issue or a PR.

since they use libmpv and most likely one of the opengl layers flavours they can do whatever they want and use the OS'/layers hdr capabilities, similar to this PR #8485. though i think i explained it somewhere on a different open issue or a PR.

What is lacking in that PR? It works well IMO.
Also Apple seems to expect SDR white to be 1.0 while mpv handles it differently. Is that the reason why some of the color spaces aren't supported?

that's what the PR says in my first comment. nothing changes on the reasons why, it's basically untested.

@anastasiuspernat @Robot-DaneelOlivaw
Did this finally fix HDR on macOS? I'm trying to use mpv in the Stremio project for HDR playback.

is this still something we need or want? my reasoning for asking:

with the recent merge of the vulkan macOS backend for gpu(-next) (and making it default) this is already included with --target-colorspace-hint, eg through libplacebo and vulkan the proper path-through parameter/hints are already set automatically, and MoltenVK maps those settings to the right colorspaces, edr data and dynamic ranges. those are the porperties that need to be set manually in #8485.
see also:
https://github.com/KhronosGroup/MoltenVK/blob/main/MoltenVK/MoltenVK/GPUObjects/MVKSwapchain.mm#L466-L559
https://github.com/KhronosGroup/MoltenVK/blob/b56c152a1245a95e7d4e8d64baca8ae42e85ae6a/MoltenVK/MoltenVK/GPUObjects/MVKSwapchain.mm#L324-L372

implementing this feature, or rather merging #8485, will not work in the vulkan case, since it will interfere with libplacebo/vulkan/moltenvk and actually breaks HDR output. so it shouldn't be added to the metal layer.

that would only leave the old opengl cocoa-cb backend that is more or less deprecated. i could cleanup my PR and add it to cocoa-cb, though it is more or less just a makeshift solution and will never be as good/automatic as --target-colorspace-hint and is only a platform specific solution.

@Akemi I am sorry but I am not familiar with a lot of things that you said. I am still wondering, does mpv work with HDR on macOS as of now or not?

with --vo=gpu-next --gpu-api=vulkan --gpu-context=macvk it works as much as gpu(-next)/libplacebo/moltenvk makes it possible, eg better and more than the WIP PR that is currently open. the current PR also only works with cocoa-cb.

First of all, glad to have you back Akemi! I thought we won't have macOS update anymore. Can't believe it's been four years since this issue was opened, the pandemic thing has come and gone but HDR stayed. mpv with gpu-next can now do tone-mapping beautifully even for Dolby Vision.

I didn't know we need --target-colorspace-hint for EDR, I thought it is just not supported. So I tested it just now and indeed it works! But not quite stable. When I try to scale the window or turn on full screen, sometimes it goes black. Also the tone-mapping seems off.

I'll attach my test result here but if you want to track these in a new issue I can do that. Honestly speaking with Vulkan macOS backend working there is no necessity of implementing EDR on other backends anymore. And we can close this yearslong issue for good.

Important Information

• mpv version: 0.37.0
• macOS Version: Sonoma 14.3.1
• Source of the mpv binary or bundle: Homebrew
• If known which version of mpv introduced the problem: 0.37.0
• Possible screenshot or video of visual glitches:

mpv --no-config --vo=gpu-next --gpu-api=vulkan --gpu-context=macvk:

mpv --no-config --vo=gpu-next --gpu-api=vulkan --gpu-context=macvk --target-colorspace-hint:

Expected behavior

Similar tone-mapping result with or without --target-colorspace-hint. EDR is enabled with --target-colorspace-hint.

Actual behavior

With EDR enabled, I get black screen when trying to scale the window or turn on full screen. Tone-mapping is off.

Log file

https://0x0.st/H7n1.log

Sample files

https://0x0.st/H7nV.mp4

@Robot-DaneelOlivaw If it is not stable yet, do you believe it's a good idea to close the issue right now?
I would say it should stay open till it is stable.

this issue is about utilising the macOS 'HDR' capabilities, which is the case. a feature request should be closed when the feature was/is implemented. any kind of issue that arises after the initialise feature merge, should be reported with a new issue.
there is only the question of, should the old opengl backend get a similar feature, even so apple deprecated opengl already and it will not lead to anything. i myself won't pursue it nymore, and will only fix bugs present in both backend/shared code.

@Robot-DaneelOlivaw basically --target-colorspace-hint sets pl_swapchain_colorspace_hint via libplacebo, which calls set_hdr_metadata, which ends up in MoltenVK in setHDRMetadataEXT and maps the HDR data provided by libplacebo/mpv to the EDR data on the layer. it also maps the colorSpaces by the data provided from libplacebo/mpv here. eg it's nothing the system specific backend does anymore, it's something done by mpv core functionality > libplacebo > MoltenVK and any problems that arise are more likely a problem with molten > libplacebo > mpv core.

i fixed the flickering yesterday with 6016423 i believe you are using an older build.

i believe your expectation to have similar tone-mapping with and without hint is rather unexpected. anyway i didn't look into all the HDR stuff yet, though we have various --target-* that probably need to be set appropriately. besides that any kind of issues are either a moltenvk > libplacebo > mpv core issue, in that order. i would prefer to have a separate issue for any new issues that arises. any tone-mapping problems are probably best directed to @haasn or anyone more knowledgable than myself.

also on i side note, you can get nightly app bundle builds on PRs (#13651 (comment) PR that fixed the flicker) and from master (#13085 (comment) the linked comment explains where to find them and the comment after that hast direct links to the latest master build). so you can try fixes without building mpv yourself.

@Akemi Thanks. I've tested the master build and it indeed fixes the flicker. As of tone-mapping, I also compared the results with Quicktime Player and --target-colorspace-hint still looks pretty different while no --target-colorspace-hint looks similar. But like you said this should be left for a new issue.

there is only the question of, should the old opengl backend get a similar feature, even so apple deprecated opengl already and it will not lead to anything.

Do we still have such use case, a macOS environment that doesn't have MoltenVK support but needs HDR playback capability? I'd say unless people specifically ask for this, there is no need to spend time on it.

i decided to add the HDR/EDR support to the old cocoa-cb/libmpv/opengl backend after all (see PR #14017). reasons are:

• it was already implemented and only needed a rebase + some small adjustments since it's only needed for cocoa-cb now
• it might come in handy for comparisons with the new backend
• we can finally resolve this issue and close some PRs

Thank you Akemi. Issue closed.