2028946 - YouTube video encoded with an HLG transfer function appears significantly overexposed (Intel UHD / NVIDIA Quadro T2000)

Status: RESOLVED WORKSFORME

(Core :: Audio/Video: Playback, defect, P2)

Description

[Daniel Bodea [:danibodea]]

Attachment: Chrome vs Nightly overexposure.png

Note

• A HDR Youtube video (with HLG transfer function) is rendered overexposed.

Found in

• Nightly v151.0a1 from 2026-04-02

Affected versions

• Nightly v151.0a1 from 2026-04-02

Tested platforms

• Affected platforms: Windows 11 + CPU Intel(R) Core(TM) i9-10885H + GPU Intel(R) UHD Graphics (with HDR enabled)
• Affected platforms: Windows 11 + CPU Intel(R) Core(TM) i9-10885H + GPU NVIDIA Quadro T2000 with Max-Q Design (with HDR enabled)
• Unaffected platforms: -

Steps to reproduce
Preconditions: HDR monitor, HDR enabled in Windows settings, Nightly opened on the HDR monitor.

1. Load and play: https://www.youtube.com/watch?v=vP-ctJUQBws

Expected result

• The video is correctly rendered, HDR is working correctly.

Actual result

• The video appears severely overexposed.

Regression range

• Does not appear to be a regression because a similar issue occurs in a build before this implementation.

Comment 1

[Daniel Bodea [:danibodea]]

Attachment: old Nigh vs new Nigh.png

This is not a regression because a similar issue is also seen in a build before the HDR implementation.
Please note that the screenshot adds MORE overexposure to the image, but the video on the HDR screen appears as overexposed already.
Also note that the video in the build with the new implementation appears a little more overexposed than the build before the implementation.

Comment 2

[Ashley Hale [:ahale]]

I'd like to see the about:support for this so I can look for errors in the Failure Log section of the output.

Comment 3

[Daniel Bodea [:danibodea]]

Attachment: about:support info

This is the about:support information from the affected environment.

Comment 4

[Ashley Hale [:ahale]]

Okay no errors from playing the video in there - was it played before getting the about:support?

One more question - what is the Peak brightness value in nits shown in the windows Settings app in System -> Display -> Advanced display?

Comment 5

[Daniel Bodea [:danibodea]]

Attachment: Reattached the Nightly151 about:support info.

To make sure the information is correct, I've created a new profile, moved to the HDR screen, restarted, loaded and played the YT video to reproduce it, then loaded the about:support and copied the information again.

Comment 6

[Daniel Bodea [:danibodea]]

Attachment: Advanced display info.png

The Peak brightness shown in Windows settings is 400 nits.

Comment 7

[Ashley Hale [:ahale]]

Thanks, I'm going to have to think about this a bit and theorize what is going wrong in this case, may have more questions tomorrow.

Comment 8

[Daniel Bodea [:danibodea]]

In this specific situation, the Youtube player recognizes the HDR video and shows the "HDR" tag on the video quality settings in both Nightly and Chrome, but only Nightly renders the video as overexposed.

Comment 9

[Daniel Bodea [:danibodea]]

This issue is now reproducible in Nightly v152.0a1 (20260507021236) with NVIDIA Quadro T2000 with Max-Q Design with HDR enabled.
It does NOT reproduce with Intel(R) UHD Graphics (10th Gen i9 CPU) with HDR disabled.

Please note that this does not occur in Beta v151.0b7 with either of the GPUs, but I imagine will reproduce in Beta 8 since HDR will be enabled (in bug 2030165).

This result raises suspicion that the NVIDIA GPU might not actually be used, as Windows and Firefox might suggest...?
What do you think, Ashley?

Comment 10

[Daniel Bodea [:danibodea]]

Attachment: aboutsupport when NVIDIA GPU is active.txt

Comment 11

[Ashley Hale [:ahale]]

On these Intel+NVIDIA systems if you set NVIDIA GPU as primary, the Intel GPU is still doing the display output and video processing, despite not being the primary GPU, so the allowlist does not apply properly, but apparently also the VideoProcessorBlt does not do what we are expecting it to do either.

In the about:support I see also that video overlays are being disabled:
Failure Log
(#0): GP+[GFX1-]: Video swapchain is slow

My previous testing showed this resulting in SDR video, but on the Intel+NVIDIA systems with NVIDIA as primary it seems to have yet another different failure mode. I'm not sure what to do about this yet, thinking about it more.

We may need to revise the allowlist to detect the second GPU and recognize these systems, or finish https://bugzilla.mozilla.org/show_bug.cgi?id=2033762 and switch to that approach instead of an allowlist as it would be completely reliable on all systems.

Comment 12

[Daniel Bodea [:danibodea]]

Attachment: aboutsupport information for Dell G5 5590 when Intel GPU is active on Nightly.txt

Comment edited to avoid confusion.

Comment 13

[Daniel Bodea [:danibodea]]

Disregard my last comment, the gfx.color_management.hdr.force_enabled unintentionally left as true. I appologize.
SDR works correctly when Intel GPU is active in about support.

Comment 14

[Donal Meehan [:dmeehan]]

Tracking since Bug 2025322 was uplifted to beta for Fx151

Comment 15

[Ashley Hale [:ahale]]

This is displays connected to an Intel GPU, we are only shipping on AMD/NVIDIA at this time, so not a blocker for shipping, but it is a blocker for shipping on Intel in future.

Comment 16

[Daniel Bodea [:danibodea]]

As suspected, this issue also occurs in Beta 151.0b9 on the same system: DELL Precision 5550, when setting Firefox executable to use the dedicated GPU (NVIDIA Quadro T2000 with Max-Q Design) in Windows settings (System/Display/Graphics). HDR is enabled, as expected.

This issue does not occur when setting Firefox executable to use the integrated GPU (Intel(R) UHD Graphics) in Windows settings (System/Display/Graphics). HDR is disabled as expected.

This issue occurs only when HDR is enabled and working, regardless of which GPU is listed as active in about:support. I have updated comment 0 to ensure the results are clearly presented.

Comment 17

[:Pretentious]

(In reply to Ashley Hale [:ahale] from comment #11)

On these Intel+NVIDIA systems if you set NVIDIA GPU as primary, the Intel GPU is still doing the display output and video processing, despite not being the primary GPU, so the allowlist does not apply properly, but apparently also the VideoProcessorBlt does not do what we are expecting it to do either.

In the about:support I see also that video overlays are being disabled:
Failure Log
(#0): GP+[GFX1-]: Video swapchain is slow

My previous testing showed this resulting in SDR video, but on the Intel+NVIDIA systems with NVIDIA as primary it seems to have yet another different failure mode. I'm not sure what to do about this yet, thinking about it more.

We may need to revise the allowlist to detect the second GPU and recognize these systems, or finish https://bugzilla.mozilla.org/show_bug.cgi?id=2033762 and switch to that approach instead of an allowlist as it would be completely reliable on all systems.

There is also another combination. Laptops with Nvidia Advanced Optimus have 2 distinct states. One is the same as above (called Optimus Mode) and other one which directly outputs display signal from Nvidia GPU (dGPU mode). Advanced Optimus has a special capability of dynamically switching between the two modes based on some program whitelist (can be configured by Nvidia App). While laptops with regular optimus need a reboot to switch between the two modes.

Comment 18

[Ashley Hale [:ahale]]

We now have the ShaderBlt code in place (Bug 2037689), please re-test on nightly or 153 beta.

Comment 19

[Daniel Bodea [:danibodea]]

Nightly:
This issue could still be reproduced in Nightly v154.0a1 from 2026-06-26 with active GPU NVIDIA Quadro T2000 with Max-Q Design (with HDR enabled); the image appears over-exposed.

Verification:

1. Dell Precision 5550, Windows 11 + CPU Intel(R) Core(TM) i9-10885H + active GPU NVIDIA Quadro T2000 with Max-Q Design (with HDR enabled). HDR works correctly.
2. Dell Precision 5550, Windows 11 + CPU Intel(R) Core(TM) i9-10885H + active GPU Intel(R) UHD Graphics (with HDR enabled). HDR works correctly.

Beta:
This issue does not be reproduce in Beta v153.0b6 with active GPU Intel(R) UHD Graphics (with HDR enabled), but HDR is not working.
This issue reproduces in Beta v153.0b6 with active GPU NVIDIA Quadro T2000 with Max-Q Design (with HDR enabled). the image appears over-exposed.

Verification:

1. The fix is confirmed in Beta v153.0b9 with active GPU NVIDIA Quadro T2000 with Max-Q Design (with HDR enabled). HDR works correctly.
2. The fix is also confirmed in Beta v153.0b9 with active GPU Intel(R) UHD Graphics (with HDR enabled). HDR works correctly.

Please note that HDR now works when either GPU is set as active in Windows settings (Intel or NVIDIA).
Feel free to close this report, thank you!