HDR bug on M2/M3 chip. #4312
Comments
|
This sounds like a duplicate of issue #4214, except I have not heard anyone report this before:
Not sure what to make of that. If you enable HDR and then follow this workaround mentioned in issue #3906 does the dimming stop?:
HDR was working fine on the M1 under macOS Monterey. The problem appeared on the M1 with the release of macOS Ventura. For this reason we have been assuming the problem is due to a defect in macOS. We were hoping 13.3 would have a fix for this, but the problem is still present. In IINA 1.3.1 a horrible hackaround was added that so far as been effective in suppressing the dimming behavior on the M1. The situation is different on the M2. On the M1 the problem only occurs in full screen mode. I'm hearing that is not true on the M2. So the problem is worse on the M2. It is very strange that the sequence shown above works to suppress the problem on the M2. As I do not have a Mac with the M2 chip I've not been able to look into what specifically it is about that sequence that causes the dimming to stop. |
|
Your instruction works temporary. I quit the app and re-open it , the dimming problem shows again. |
|
Unfortunately that is the expected behavior with that workaround. |
|
I can help you with testing the HDR problem in the coming betas on my M2 mac if you want.🧑🏻💻 |
|
I really appreciate the offer of help with testing!! In general, until the definitive root cause of a software problem is identified you can't be absolutely certain of the responsible code. But as HDR was working on the M1 until macOS Ventura we strongly suspect the problem resides in macOS. The M2 behavior also points to macOS as (that I know of) IINA and its dependencies do not contain any code that changes behavior based on the chip it is running on. So we are expecting Apple has to fix this problem. With the M1 we noticed the dimming would stop when the OSC was displayed. @royj prepared what software developers refer to as a hackaround based on the knowledge that for reasons unknown macOS did not dim the screen if another view (the OSC) was present. The "hackaround" mimics that condition adding a tiny nearly invisible view. This is usually termed a hackaround rather than a workaround as we can't explain from a detailed technical perspective how this works around the problem. And therefore we can't be assured that this hackaround will continue to work in future versions of macOS. The situation is similar with the M2 in that we have a workaround of invoking and canceling the crop operation. That suggests that maybe we could come up with a similar "hackaround" as was done for the M1. To do that a developer would need to be able to pull apart the crop code and identify what part of it suppresses the dimming. Doing that requires an iterrative process of changing code and testing the effect on the dimming. That must be done on a Mac with the M2 chip. So we need some developer with a M2 Mac to see if a reasonable hackaround can be developed for the M2. Other than that we are waiting for Apple to fix macOS. |
|
Same M2 Air |
|
Yep, M2 Air too |
|
M2 Pro too. It seems such a challenging job. I really wanna participate in the solving this problem (I LOVE HDR 😉). I'm not that good at developing, but I can offer you testing in m2 pro or some analysis in your request. I'm new to co-operating github project, so could you tell me how can I participate in and what can I do for you. |
|
@GST-Main I really appreciate the offer of help with testing. Caught me busy this weekend with non-IINA stuff, so this is a rushed reply, which I always hate doing as I usually get something wrong when I rush, but lets's blunder ahead… I do not work on IINA's HDR code, it is outside of my area of expertise. I'm involved because my development machine is a MacBookPro18,2 with a XDR display, allowing me to test HDR. I also help when needed with code merges in this area. I just ran a quick test and did not get the results I expected. I played the HDR video I then commented out the hack around that was added to IINA 1.3.1 here that suppresses the problem on the M1. I built the latest IINA sources from the If there is anyone reading this with a M2 machine who knows how to deal with an unsigned nightly build can you please test the latest build found here and see if the dimming still occurs when running on a M2. The Hopefully someone can test the nightly build on a M2 Mac and see if the behavior has changed on the M2 as well. |
|
@GST-Main Thanks for testing the nightly build. Very interesting result. I ran the following test today. Using the This confirms the changes made in PR #4174 have suppressed the dimming problem on both the M1 and the M2. @OceanS2000, @CarterLi any thoughts on how these changes corrected the strange dimming problem? @GST-Main I will ask for more help with testing on the M2 when we are closer to release. Developers are currently working to produce upgraded dependencies including mpv 0.35.1 and FFmpeg 5.2.1. Once the nightly build includes the upgrading dependencies we will want to test again to make sure nothing has changed and HDR is still working. I'm going to do some more testing but this seems to mean I can remove the M1 workaround in |
|
@low-batt OK. I'll be waiting. |
|
This version [8bdf01c] works just fine. The HDR dimming problem has gone. |
|
I have met the same problem with m2 macbook pro. I have tested it in some ways and I want to provide more information on this problem. There are two ways I found that can barely see the effect expected:
I suppose this problem is caused by some system problem such as stage manager. |
|
Thanks for the additional information about the behavior on the M2. You never really know which component is responsible for a software problem until you track down the actual root cause of the problem and can explain why it triggered the behavior seen. Usually with software if you upgrade a component and a problem appears, it is due to a defect in the upgraded component. However it could be that another component was doing something that was invalid and by luck was to able to get away with it until the upgraded component just happened to expose the problem. In the case at hand HDR was working fine on the M1 under macOS Monterey. The problem appeared with the upgrade to macOS Ventura. Other graphics problems not related to IINA have been reported against Ventura. I'm still hearing reports of black screens with macOS 13.3.1. That the behavior differs greatly on the M2 is also suggestive of a problem in macOS as the behavior should be consistent. From the Apple Newsroom article macOS Ventura is now available:
That is referring to Apple's Metal graphics API. So we know Ventura includes a major upgrade to graphics. All this is strongly suggestive that these odd behaviors are due to problems in the graphics portion of macOS. Hopefully all graphics related regressions will be fixed in macOS Ventura 13.4. |
|
Thank you for your insight, very much appreciated |
|
期待早日修复，iina 是用过最好的mac播放器，但是这个问题最近开始困扰我了 |
|
After my testing the latest version #52708e7 was able to dog in my MacBook pro M2 MAX to solve the HDR problem. |
|
The latest unsigned nightly build found here has been built with upgraded dependencies including mpv 0.35.1 and FFmpeg 6.0. It also contains a new tone mapping setting in the @GST-Main These are the changes I was having you wait for before testing again. |
I have just tried the 52708e7 commit version. Tested multiple HDR videos, dimming problem is fixed. |
I tested 52708e7 version and there's no dimming. However, I don't know the tone mapping setting actually works. It seems to be a feature that makes a SDR video like a HDR video by tone mapping, but when I tried with some SDR videos (and also HDR videos) by turning on and off and changing peek brightness setting, it seems there's no changes. Can I ask you that this is a right way to test new tone mapping setting, what is the effect exactly and how I can use it? |
|
Thanks everyone for testing! On this:
First I probably should have mentioned IINA needs to be restarted after changing the tone mapping settings for the new value to take effect. Remember I am not doing the HDR work, merely helping merge and testing. For how this relates to SDR, I'm hoping @CarterLi will comment on that. With respects to HDR, it depends upon the video being played. From High-dynamic-range television:
The XDR screens in the latest MacBook Pros can handle 1000 nits. But if you tried to play a video that was encoded such that the dynamic range goes up to 10000 nits it would need to be tone mapped to stay within the range of the XDR display. Some of the effects are subtle. You have to look close at scenes that use the full dynamic range. To really confirm tone mapping is occurring we can exaggerate the effects for a test. First:
Then:
Now:
|
Nothing related. SDR videos have low maximum brightness and don't need to be tone mapped. In addition, for HDR videos, if the maximum brightness used by the video source is lower than the maximum brightness of your monitor supports, no tone mapping is needed. |
@CarterLi So, the tone mapping is for some videos with peak brightness that is brighter than device's max brightness spec, right? |
|
Yes. |
I tested it and it works fine! |
|
Interesting aside. On my M2 MacBook Pro with v1.3.1, playing HDR video is very dark UNLESS I also play a video in VLC at the same time. Also, I checked the latest 1.3.2 build and the dark screen HDR appears to be fixed. |
|
Yeah, it's super annoying indeed. What you can do about the border is to use accessibility zoom and zoom the screen in to 105% for example. This way you can tune out the black borders (but of course your video won't be pixel perfect anymore if you care about that + some small content on the sides will be lost). But I just mostly resorted to watching HDR videos in SDR mode or get my M1 MBP and use that for watching videos. |
|
btw - imho this issue should get a "bug" tag and a "priority: high" :) |
|
This issue is not a priority for the development team because to investigate it requires a Mac with the M2 chip and probably an external monitor capable of HDR. Last I checked none of the developers possess the required equipment to look into this one. The IINA code does not contain any checks that change the behavior when running on a M2 chip vs. running on a M1 chip. I don't know for sure, but I would be surprised if there is this level of conditionalization in the libraries that IINA uses. That suggests the difference in behavior between M1 working and M2 failing is coming from macOS. We've been hoping this problem would disappear in a macOS update. I used the word "suggests" because until an investigation identifies the root cause you can't say for sure where the fault lies. I've not heard yet if this problem is still present under macOS Sonoma or what the situation is with the M3. I have upgraded one of my machines to macOS Sonoma 14.1.1. Shortly after the upgrade macOS crashed on me. I'm also encountering some new problems that do not reproduce on my primary development machine running macOS Ventura. I'm not recommending upgrading to Sonoma at this time. |
|
Yeah, Sonoma has a lot of issues (but this issue is present for Ventura as well). For M2 users who has a high refresh rate external display with HDR (or use a 4K TV at 120Hz), Sonoma 14.1 finally fixes the lack of HDR beyond certain resolutions (for example HDR at 2560x1440 120Hz was unavailable previously) that's been plaguing these systems for many months now. Strangely enough, on M1 Macs Sonoma 14.1 breaks HDR on exactly the same resolutions that were unavailable with M2 previous to 14.1 (probably somebody tried to fix this bug with M2 but obviously botched it). Apple is quite obviously struggling with this whole HDR thing (they probably don't really test their releases properly with third party displays, I suppose all developers use XDR displays which work completely differently thanks to the combined SDR-HDR mode with XDR EDR so they are blindsided). Regarding the HDR bug, macOS properly reports the EDR range on M2 on third party HDR displays in HDR mode and generally HDR works just fine (tried it with some Metal layers + BetterDisplay has no problem with HDR brightness upscaling either, the EDR headroom is correctly reported and detected etc). |
|
On HDR working fine and this:
IINA is not using Metal; IINA is using OpenGL. As Apple has Deprecated OpenGL they may not be doing as much testing as they used to especially for HDR support. For audio/video support IINA uses a library from the mpv project. The project has been working on a next generation renderer (GPU Next) that uses Vulkan instead of OpenGL. Recently support for using On this:
That is certainly interesting to hear. Seems to confirm the macOS needs chip specific graphics code as suspected. Pretty bad that Apple missed that the fix for M2 broke M1. Had a friend who just got a MacBook Pro with the M3 Pro chip test streaming The World in HDR in 4K (ULTRA HD) using IINA 1.3.3. He reported HDR playback was fine in windowed and full screen modes. This was under macOS 14.1.1. Not clear yet if he will be able to test playback on an external HDR display. |
|
All right @low-batt - this makes sense, thanks. I plan to get an M3 MBP, will see if things work with an external HDR display. Can't test M2 with internal display myself for comparison as I only have a Studio from that generation (my MBP is still M1). Note: an other trick with M2 to somewhat bring back HDR with IINA is to let it render darkly as it is but use BetterDisplay's HDR brightness upscaling feature (this is normally meant to help remap the normal SDR color range of the desktop to the HDR range, thus giving extra brightness both for third party HDR displays and Apple's XDR displays) but recalibrate it (using the calibration slider under Settings) to overcompensate for IINA's dim rendering. This is not a very nice solution, but kinda works (however due to the compressed dynamic range of the too dark rendering this deteriorates the quality somewhat and might result in some banding etc especially if the framebuffer depth is 8-bits instead of 10-bits). |
|
Hi @waydabber, following up to your comment. I have a 240hz HDR display with an M3 Macbook Pro Max running Sonoma. This problem still occurs. IINA detects HDR fine when dragging the window onto the display but its just very dark. The (Video->crop->custom->cancel) workaround fixes the issue, and the video becomes brighter than max SDR brightness so HDR definately kicks in. IINA works fine on the in-built display, only related to external displays as far as I can tell. |
|
Thanks @xanather for the info! Based on what @low-batt says, the problem is unlikely to be resolved as Apple indeed abandoned OpenGL and it's typical for things to start slowly breaking for deprecated stuff in macOS (well, sometimes even non-deprecated things start breaking slowly, I could name a few... 😄). @caipod @low-batt - I think it might be a good idea to update the issue title to "Dark HDR video bug on M2/M3 chips" based on @xanather's report. |
|
IINA uses OpenGL? Apple M3 hardware is insane tech but their inability to support anything but the Metal API is really hindering them at this point. They added proper external monitor HDR support but there's not really any friendly codec universal video players that support playback in that mode without issues currently. Stupid. |
|
On this:
Darn. I was just about to report that my friend got back to me that HDR worked fine with his MacBook Pro with the M3 Pro chip running macOS 14.1.1 and using a LG TV model OLED65CXAUA through HDMI. This seems to indicate the problem involves some other factor that we have not yet identified. One factor it would be nice to rule out is that the way the video is encoded has something to do with the problem. Did you test streaming The World in HDR in 4K (ULTRA HD)? On this:
IINA has no choice but to use From the mpv player's site:
For the Mac that means it is expected that you start
And most importantly from IINA's perspective:
As can be seen by looking over the OPTIONS section of the Right at this moment the hold up is the following from the Known limitations / missing options section of the GPU Next vs GPU wiki post:
Once that is solved then IINA will need to make the changes required to support the new renderer. |
|
Hey @low-batt, running that video via Safari the HDR works fine on both DP and HDMI as I would expect that it doesn't touch OpenGL. I could compare with Firefox which doesnt support HDR yet. I have both HMDI and DisplayPort connections (I have quite a unique setup actually, three 240hz HDR 1440p displays all from one M3 chip, two DP and one HDMI). IINA darkness bug behaves the same on all three displays. Unfortunately I don't have the time to contribute to mpv or IINA at the moment to help debug, but if anyone would like me to test any senarios with my setup fling me a message. Can you share the video file your friend used that worked properly with IINA? |
|
On this:
I had him stream the YouTube video: The World in HDR in 4K (ULTRA HD) That Safari is working is more evidence that suggests this could be a problem with OpenGL. |
|
Now if I enable accessibility zoom and zoom the screen in even just 1% (or any negligible amount) the rendering appears to be correct both in windowed and full screen mode (without crop hack - running M2, Sonoma 14.2 beta3 with an external third party HDR display). As the app for sure does not do anything special during accessibility zoom, this finding clearly points to some kind of macOS desktop compositor issue to me. Anyway, using accessibility zoom is the simplest, quickest and best workaround I found so far. |
|
Thanks for posting that tip. I agree. This is more evidence that suggests the problem is in macOS. |
|
Another simple workaround is to mirror the external TV with the built-in screen |
|
I have the same exact issue on M2 MAX Mac Studio connecting to only one monitor. For me, the proposed (Video->crop->custom->cancel) workaround works ONLY when NOT going fullscreen. But before seeing this issue report, actually I found myself another workaround that works all the time, i.e., use the sidecar display feature to connect an iPad as an extended display. This sidecar connection workaround magically works all the time. |
|
An other workaround - if |
It's indeed a problem with macos |
|
@xiushimt Thank you for the update. Very helpful. |
|
Yes, I can confirm this, IINA was working fine both with Beta1 and Beta2 (the same config had issues under Sonoma). Tested with MBP M3 Max + external HDR display. |
|
This is great news. I was concerned this was not fixed in Sonoma. |
and others
System and IINA version:
Expected behavior:
The player will display the right HDR effect when I switch on the HDR during playing an HDR MKV file.
Actual behavior:
I recently bought the M2 mac mini. The interface goes much much darker when I play a HDR MKV file, but when I switch off the HDR, the player displays the right HDR effect.
But this situation will not appear on the M1 mac. My Mac studio works just fine.
Crash report:
mpv log:
Steps to reproduce:
How often does this happen?
Everytime
mpv.log
The text was updated successfully, but these errors were encountered: