AV1 HDR video on MacOS is extremely bright
Categories
(Core :: Graphics: Color Management, defect, P2)
Tracking
()
People
(Reporter: mail, Assigned: bradwerth)
References
()
Details
Attachments
(6 files)
HDR_bug_photo.jpg
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:149.0) Gecko/20100101 Firefox/149.0
Steps to reproduce:
Example video linked below:
https://miikah.fi/m/mhap69?force_allow_hdr
On my webisite I have by default disabled HDR on Firefox due to issues, but now that there seems to be progress to make it work on Windows I tested if it works on MacOS using a "force_allow_hdr" query parameter to force HDR playback even on unsupported browsers.
Actual results:
On MacOS 26.4 (Macbook Pro M4) the HDR AV1 video plays crazy bright, all overblown. Screen seems to be at pretty much max 1600 nits it can push.
Expected results:
Same video looks fine on Chrome and Safari.
|
||
Comment 1•6 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•6 months ago
|
|
||
Comment 2•6 months ago
|
||
I'm wondering why this would be so bright, the version is before HLG transfer function support and this video is PQ, not HLG, so this should be entirely on existing macOS code paths that predate the current HDR video work...
|
Assignee | |
Comment 3•6 months ago
|
||
Doesn't repro for me, but I'll tweak some params, try with a clean profile, see what happens.
I now tested with a new Firefox Profile to see if I had weird settings enabled somehow. Still seems to happen. I attached a photo of the screen how it looks to me.
Another curious detail is that if I take a screenshot it looks "ok" or at least not overbright, though not sure if that means anything or does MacOS composite the screenshot as SDR so it isn't related to HDR anymore.
|
||
Comment 5•6 months ago
|
||
I see something different in Nightly than Release with that video. Nightly is dimmer and matches Chrome, Release is brighter but not hugely overexposed, and matches Safari
I was doing some more testing myself and added a new url parameter to completely exclude SDR variants of the video (to ensure device doesn't fall back to VP9 or H264): https://miikah.fi/m/mhap69?force_hdr
One thing I noticed is that if I mirror my screen with AirPlay then the video looks normal, although bit washed out. I think reason is that AirPlay forces the screen to SDR mode so it plays the video tonemapped, just worse tonemapping than Chrome/Safari uses so it is slightly faded out.
As soon as I disable AirPlay the video turns super bright again.
I also tried various display presets in MacOS settings, but whether I use the default "Apple XDR Display P3-1600 nits" or any other ones, the video still looks like it is trying to push 10 000 nits or so.
Some additional observations:
- Firefox 150 Beta: Same behavior as 149.0.2, extremely bright HDR
- Firefox Nightly: HDR seems to be disabled. I only get tonemapped and washed out SDR playback
|
||
Comment 8•6 months ago
|
||
Nightly/MacOS is displaying SD for me. Safari can't play the video on my device, and Chrome on MacOS sees to get it right.
|
|
||
Updated•6 months ago
|
|
|
||
Comment 9•6 months ago
|
||
Regression on the lack of hdr in macos nightly was around 4-1, but I was not able to identify the specific change set.
|
|
Assignee | |
Comment 10•6 months ago
|
||
Still unable to reproduce this. Tried on my Intel Mac, looks normal-ish, a little undersaturated. Would you please upload the video file itself? If it's too big, then just upload a shorter clip that demonstrates the same problem.
My about:support attached.
|
Reporter | |
Comment 11•6 months ago
|
||
Sure. I now attached a 6 seconds clip of the video in the original report.
I have a feeling that the issue might only affect the hardware accelerated AV1 path, given how some people can't replicate the issue.
Only Macs with M3 or later chips have hardware decoding support for AV1. Given that the same video with HW acceleration works on Safari and Chrome there could to be some kind of issue on how the HW playback is initialized or what flags are passed with it.
|
|
Reporter | |
Comment 12•6 months ago
|
||
Just to confirm: The attached video in my comment above also triggers the bug on my device. The video player is 95% pure white, only couple of the darkest parts showing anything else.
If I had realized that uploading videos here is possible and the bug replicates in the attachment player I would have included attachment clip in the original report to begin with.
|
|
Assignee | |
Comment 13•6 months ago
|
||
Here's the MediaInfo output from attachment 9570844 [details]. This plays desaturated for me on my M4 Mac, so there's still a problem even if I'm not getting the white balance blowout. I'll check the video log via pref gfx.core-animation.specialize-video.log to confirm that we're not getting an HDR-capable video layer. Presuming that, I'll also try a mozregression.
General
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/av01/iso2/mp41)
File size : 8.54 MiB
Duration : 6 s 17 ms
Overall bit rate : 11.9 Mb/s
Frame rate : 60.000 FPS
major_brand : isom
minor_version : 512
compatible_brands : isomav01iso2mp41
date : 2025
encoder : Lavf62.3.100
Video
ID : 1
Format : AV1
Format/Info : AOMedia Video 1
Format profile : Main@L5.1
Codec ID : av01
Duration : 6 s 12 ms
Source duration : 6 s 0 ms
Bit rate : 11.3 Mb/s
Maximum bit rate : 11.8 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.023
Stream size : 8.10 MiB (95%)
Source stream size : 8.44 MiB (99%)
Title : VideoHandle
Writing library : Lavc62.15.100 libsvtav1
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Codec configuration box : av1C
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 6 s 17 ms
Bit rate mode : Constant
Bit rate : 129 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 94.7 KiB (1%)
Title : SoundHandle
Default : Yes
Alternate group : 1
|
|
Reporter | |
Comment 14•6 months ago
|
||
Hmmm... Couple of interesting notes on how the video behaves on the embedded attachment player:
- When I toggle fullscreen it for a second during the transition looks normal (tonemapped SDR, not overblown), then turns overblown again
- Same as earlier, if I have AirPlay screen mirroring active the video always is using tonemapped SDR that doesn't look overblown (AirPlay not supporting HDR I suppose)
What is most interesting and weirder and what doesn't happen on my website player:
- Initially the attachment player doesn't trigger HDR, just is near full SDR white
- BUT if I open the HDR content (such as this bug report) in Safari, then HDR also activates on Firefox and now the video player is blasting like a flashlight at max nits the screen can show
- If I close Safari the attachment video player turns back to overblown white SDR after 30s or so.
No idea what is going on there, but I can replicate the behavior repeatedly.
|
|
Assignee | |
Comment 15•6 months ago
|
||
Getting somewhere. With a debug build, I get the white balance blowout. Here's the output from the video logging:
2026-04-16 15:45:37.900 firefox[82059:14797228] VIDEO_LOG: Rebuilding video layer with AVSampleBufferDisplayLayer.
2026-04-16 15:45:37.903 firefox[82059:14797228] VIDEO_LOG: LogSurface...
2026-04-16 15:45:37.903 firefox[82059:14797228] Surface values are {
CreationProperties = {
IOSurfaceAllocSize = 24891904;
IOSurfaceBytesPerElement = 1;
IOSurfaceBytesPerRow = 11524;
IOSurfaceElementHeight = 1;
IOSurfaceElementWidth = 1;
IOSurfaceHeight = 2160;
IOSurfaceIsGlobal = 1;
IOSurfaceName = decode;
IOSurfaceOffset = 0;
IOSurfacePixelFormat = 2016686640;
IOSurfacePixelSizeCastingAllowed = 1;
IOSurfacePlaneInfo = (
{
IOSurfacePlaneBase = 512;
IOSurfacePlaneBytesPerElement = 2;
IOSurfacePlaneBytesPerRow = 7680;
IOSurfacePlaneComponentBitDepths = (
10
);
IOSurfacePlaneComponentNames = (
5
);
IOSurfacePlaneComponentRanges = (
2
);
IOSurfacePlaneElementHeight = 1;
IOSurfacePlaneElementWidth = 1;
IOSurfacePlaneHeight = 2160;
IOSurfacePlaneOffset = 512;
IOSurfacePlaneSize = 16588800;
IOSurfacePlaneWidth = 3840;
},
{
IOSurfacePlaneBase = 16589312;
IOSurfacePlaneBytesPerElement = 4;
IOSurfacePlaneBytesPerRow = 7680;
IOSurfacePlaneComponentBitDepths = (
10,
10
);
IOSurfacePlaneComponentNames = (
7,
6
);
IOSurfacePlaneComponentRanges = (
2,
2
);
IOSurfacePlaneElementHeight = 1;
IOSurfacePlaneElementWidth = 1;
IOSurfacePlaneHeight = 1080;
IOSurfacePlaneOffset = 16589312;
IOSurfacePlaneSize = 8294400;
IOSurfacePlaneWidth = 1920;
}
);
IOSurfacePurgeWhenNotInUse = 1;
IOSurfaceSubsampling = 3;
IOSurfaceWidth = 3840;
};
HorizontalDisparityAdjustment = 0;
IOSurfaceChromaLocationBottomField = Left;
IOSurfaceChromaLocationTopField = Left;
IOSurfaceColorPrimaries = "ITU_R_2020";
IOSurfaceColorSpace = 32;
IOSurfaceColorSpaceID = 32;
IOSurfaceName = decode;
IOSurfaceTransferFunction = "SMPTE_ST_2084_PQ";
IOSurfaceYCbCrMatrix = "ITU_R_2020";
kIOSurfacePixelMetadata = {
kIOSurfaceLumaHistogramV1 = {length = 512, bytes = 0x00000000 00000000 00000000 00000000 ... 00000000 00000000 };
kIOSurfaceSessionCookie = 36621094912;
kIOSurfaceSessionFrameNumber = 1;
};
}.
2026-04-16 15:45:37.904 firefox[82059:14797228] ColorSpace is <CGColorSpace 0x305b2fe20> (kCGColorSpaceICCBased; kCGColorSpaceModelRGB; HDTV).
2026-04-16 15:45:37.904 firefox[82059:14797228] Buffer attachments are {
CGColorSpace = "<CGColorSpace 0x305b2fe20> (kCGColorSpaceICCBased; kCGColorSpaceModelRGB; HDTV)";
CVImageBufferChromaLocationBottomField = Left;
CVImageBufferChromaLocationTopField = Left;
CVImageBufferColorPrimaries = "ITU_R_2020";
CVImageBufferTransferFunction = "SMPTE_ST_2084_PQ";
CVImageBufferYCbCrMatrix = "ITU_R_2020";
HorizontalDisparityAdjustment = 0;
}.
2026-04-16 15:45:37.904 firefox[82059:14797228] Codec is x420.
2026-04-16 15:45:37.904 firefox[82059:14797228] Format extensions are {
CVBytesPerRow = 11524;
CVImageBufferChromaLocationBottomField = Left;
CVImageBufferChromaLocationTopField = Left;
CVImageBufferColorPrimaries = "ITU_R_2020";
CVImageBufferTransferFunction = "SMPTE_ST_2084_PQ";
CVImageBufferYCbCrMatrix = "ITU_R_2020";
Version = 2;
}.
This seems to roughly match the output from MediaInfo, meaning we seem to be decoding this properly, just not rendering it well.
|
|
Assignee | |
Comment 16•6 months ago
|
||
Indeed, mozregression indicates Bug 1871796, which just enables AV1 hardware decode. I'll keep working to improve things.
|
|
Assignee | |
Comment 17•6 months ago
|
||
Hardware decode. This is the console output with pref gfx.core-animation.specialize-video.log and pref media.hardware-video-decoding.enabled both true. White balance is blown out.
|
|
Assignee | |
Comment 18•6 months ago
|
||
Software decode. This is the console output with pref gfx.core-animation.specialize-video.log true and pref media.hardware-video-decoding.enabled false. White balance is correct.
|
|
Assignee | |
Comment 19•6 months ago
|
||
Between hardware and software decode, there are differences in the IOSurface properties, and the buffer attachments, and the format extensions. I'm going to start forcing values to see which ones are affecting the white balance.
|
|
Assignee | |
Updated•5 months ago
|
|
|
Reporter | |
Comment 20•2 months ago
|
||
I just did some additional testing with Firefox 153.
On Mac:
- The issue still persists. Video is overblown.
On Windows: - HDR video now works fine without any issues from what I can tell (At least on Nvidia)
- HDR -> SDR tonemap also looks pretty good when display is in SDR mode (in some of the earlier Firefox versions this was faded out)
So at least looks like I can now whitelist Firefox versions >= 153 on Windows user agents.
|
|
Reporter | |
Comment 21•2 months ago
|
||
Also, here is attached video from additional testing on Mac.
The behavior seems to indicate that the issue is somehow related to the OS compositor behavior or something like that. In the video:
- First just a small Firefox window playing the buggy overblown video
- Then I open QuickTime Player with the same video playing in HDR to the right side (it looks fine as expected)
- Now the weird thing happens: With the video player visible side by side, if I change focus to the Firefox window now the video is no longer overblown. Looks less saturated than the video player though.
- Then every time I change window focus to the QuickTime Player, Firefox becomes overblown. Every time I focus the Firefox window the video becomes not overblown.
Another thing I tested was changing about:config "media.hardware-video-decoding.enabled" to false. After restarting Firefox the issue is gone. Then if I enable it again, after restart the issue is back.
This seems to confirm that it only happens with hardware decoded video. So on Macbooks with M3 or newer chips only are affected because older devices don't support hardware decode of AV1.
|
|
Assignee | |
Comment 22•2 months ago
|
||
Bug 2039373 recently landed, which improved some HDR video cases. Would you please re-test and see if the problem is resolved? I'll try again to replicate on an Intel mac.
|
|
Reporter | |
Comment 23•2 months ago
|
||
Nice! I now tested on Firefox Nightly and everything seems to be working flawlessly! Playback on the webpage, the inline player in this bug report, full screen, popup player. All working as expected and HDR renders fine.
|
|
Assignee | |
Comment 24•2 months ago
|
||
(In reply to MiikaH from comment #23)
Nice! I now tested on Firefox Nightly and everything seems to be working flawlessly! Playback on the webpage, the inline player in this bug report, full screen, popup player. All working as expected and HDR renders fine.
Great, thank you. I'll close this as a dupe of Bug 2039373.
Description
•