1912677 - After bug 1911920, washed out video on HDR monitor (Windows, maybe other OS)

Status: VERIFIED FIXED

(Core :: Graphics: Color Management, defect, P1)

Description

[Dimitry Andric]

Attachment: Video looking normal

After bug 1911920 landed, I get washed-out video colors on a HDR monitor, using Windows. I bisected this with mozregression, and it turns out to be caused by https://phabricator.services.mozilla.com/D218698 / https://hg.mozilla.org/mozilla-central/rev/6941e8e0d44dbf894188b3ac18b4b41c6e92596b .

Comment 1

[Dimitry Andric]

Attachment: Video looking washed out

Comment 2

[Dimitry Andric]

Note that I had to take pictures with a camera, since Windows screenshotting apparently changes the colors yet again!

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[iBenny]

IMO. I thin this bug goes in the 'Core:Audio/Video: Playback' componment categorie instead !

Comment 5

[iBenny]

Have the same issue : Bug 1912625

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

:jgilbert, since you are the author of the regressor, bug 1911920, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 7

[Dimitry Andric]

(In reply to iBenny from comment #4)

IMO. I thin this bug goes in the 'Core:Audio/Video: Playback' componment categorie instead !

Bug 1911920 was in the category Graphics:Color Management so I've updated this bug to match that.

Comment 8

[Glenn Watson [:gw]]

S2 for now, as it's a recent regression.

Comment 9

[iBenny]

(In reply to Dimitry Andric from comment #7)

(In reply to iBenny from comment #4)

IMO. I thin this bug goes in the 'Core:Audio/Video: Playback' componment categorie instead !

Bug 1911920 was in the category Graphics:Color Management so I've updated this bug to match that.

Not changed yet...

Comment 10

[Shouvik Saha]

Attachment: Video rendering on Firefox stable v129 (left) and Nightly v131.0a1 (right)

This color rendering bug visible in an HDR monitor. The video itself in the screenshot is an SDR video.

Comment 11

[Shouvik Saha]

(In reply to Shouvik Saha from comment #10)

Created attachment 9418911 [details]
Video rendering on Firefox stable v129 (left) and Nightly v131.0a1 (right)

This color rendering bug visible in an HDR monitor. The video itself in the screenshot is an SDR video.

Can confirm on my system. I have this exact issue on Nightly131.0a1 (2024-08-12). I searched for a video where the difference would immediately and very distinctly visible and clicked the photo.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1911920

Comment 13

[iBenny]

(In reply to Shouvik Saha from comment #11)

(In reply to Shouvik Saha from comment #10)

Created attachment 9418911 [details]
Video rendering on Firefox stable v129 (left) and Nightly v131.0a1 (right)

This color rendering bug visible in an HDR monitor. The video itself in the screenshot is an SDR video.

Can confirm on my system. I have this exact issue on Nightly131.0a1 (2024-08-12). I searched for a video where the difference would immediately and very distinctly visible and clicked the photo.

I do confirm the issue ! I have the same issue with my HDR monitor on Nightly 131.0a1 (2024-08-12) (64 bits)

Comment 14

[Dimitry Andric]

Note, I cannot reproduce this on macOS (13.6 Ventura), on the same HDR monitor. It appears to affect only Windows, as far as I can see. (I don't have Linux hardware hooked up any HDR screens, unfortunately, so I cannot test it there.)

Comment 15

[Kelsey Gilbert [:jgilbert]]

Hi, can you attach your about:support?

Comment 16

[Kelsey Gilbert [:jgilbert]]

Commenting out the IDCompositionTableTransferEffect in DCLayerTree fixes this, it seems.
Perhaps IDCompositionTableTransferEffect isn't working as-expected [in dwm?] in hdr mode?
The weirdest part is that using the color-picker (from PowerToys) shows the correct values, and using print-screen makes the colors temporarily match between e.g. Chrome and Firefox.

Comment 17

[Kelsey Gilbert [:jgilbert]]

...which is why the old skip-tf-inversion branch saved us from this!

It's a little hard to see at-a-glance whether the tf-to-linear and linear-to-tf tables cancel out, but checking DstFromSrc in a debugger shows that we're getting a no-op in the poorly-displaying case:

  const auto dstRedOne = conv.DstFromSrc(color::vec3({1,0,0})); // -> 1,0,0
  const auto dstRedHalf = conv.DstFromSrc(color::vec3({0.5,0,0})); // -> 0.5,0,0
  const auto dstGrayHalf = conv.DstFromSrc(color::vec3({0.5,0.5,0.5})); // -> 0.5,0.5,0.5

Commenting out either tf-to-linear or linear-to-tf shows that these are having some effect, but not what we expect?
I wonder if DComp is sending values through these tables that are hdr already, even though they shouldn't be. (Is it trying to optimize and has already converted this data to e.g. scrgb or hdr10?

On the balance, let's just disable the tf-to-linear and linear-to-tf IDCompositionTableTransferEffects for now, and I will investigate more but fix Nightly.

Comment 18

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1912677 - Add gfx.webrender.dcomp.debug.hueshift-color-managed.

Comment 19

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1912677 - Don't use IDCompositionTableTransferEffect because breaks under window's hdr:true.

Comment 20

[Dimitry Andric]

Attachment: bug1912677-about-support.txt

(In reply to Kelsey Gilbert [:jgilbert] from comment #15)

Hi, can you attach your about:support?

Comment 21

[iBenny]

I found the source of the problem with the assistance of the NVIDIA support agent :

The problem relates to mismanagement of the "Performance | material acceleration" setting ! Disable it and the problem will go away.

Firefox now have to verify their code so that the problem don't arise with the "material acceleration" enabled...

Comment 22

[iBenny]

(In reply to iBenny from comment #21)

I found the source of the problem with the assistance of the NVIDIA support agent :

The problem relates to mismanagement of the "Performance | material acceleration" setting ! Disable it and the problem will go away.

Firefox now have to verify their code so that the problem don't arise with the "material acceleration" enabled...

They also asked to disable 'material acceleration' setting in the OS : "System|display|graphic settings link at the bottom|material acceleration" but it was already unchecked in my case...

Comment 23

[iBenny]

Is this a FF miscoding in this regards ? Not really cuz I had the same problem in Vivaldi and it was resolved by disabling the "material acceleration" there too !

Comment 24

[Dimitry Andric]

Even if this could be fixed by toggling some NVIDIA specific setting, it is not a good solution. The video looked fine before this bug was filed, without having to mess with video card settings, and it has been verified to be broken by the commit for bug 1911920.

Therefore, the easiest fix is usually to revert those commits, and then try other approaches. I am unsure why this has not already been done, since HDR is now broken for more than a week. No pressure. ;)

Comment 25

[iBenny]

(In reply to Dimitry Andric from comment #24)

Even if this could be fixed by toggling some NVIDIA specific setting, it is not a good solution. The video looked fine before this bug was filed, without having to mess with video card settings, and it has been verified to be broken by the commit for bug 1911920.

Therefore, the easiest fix is usually to revert those commits, and then try other approaches. I am unsure why this has not already been done, since HDR is now broken for more than a week. No pressure. ;)

Agreed ! I prefer using the "material acceleration" feature to fully take advantage of the GC capacities...

Comment 26

[iBenny]

Problem seem to have been solved by FF...

Comment 27

[iBenny]

(In reply to iBenny from comment #26)

Problem seem to have been solved by FF...

False alarm ! Still bugged : need to disable "material acceleration" in the parameters

Comment 28

[iBenny]

And contrary to most settings, the browser has to be restarted for this "material acceleration" setting be applied...

Comment 29

[Dianna Smith [:diannaS]]

Kelsey, is this patch going to fix all the issues mentioned in the "See also" tickets? I'm hesitant to add those as duplicates so that we can confirm one by one that it does fix it once this patch lands (hopefully soon?) We have some time, but let me know if you prefer to backout the regressor.

Comment 32

[Kelsey Gilbert [:jgilbert]]

With an updated Nightly, after bug 1913073, do you see this problem still?

Comment 33

[Dimitry Andric]

(In reply to Kelsey Gilbert [:jgilbert] from comment #32)

With an updated Nightly, after bug 1913073, do you see this problem still?

No, it's now fixed. Thanks!

Comment 34

[iBenny]

(In reply to Dimitry Andric from comment #33)

(In reply to Kelsey Gilbert [:jgilbert] from comment #32)

With an updated Nightly, after bug 1913073, do you see this problem still?

No, it's now fixed. Thanks!

I do not agree ! its NOT fixed on my end.

Sometimes people reverts the "performance | material acceleration" settings and do a test to see if the issue is fixed but... they forget to restart the browser prior to do the test because contrary to most parameter/configuration firefox settings, the "performance | material acceleration" setting needs a browser restart to make it active.

Comment 35

[Dianna Smith [:diannaS]]

Adding NI for review of comment 34

Comment 36

[iBenny]

(In reply to Dianna Smith [:diannaS] from comment #35)

Adding NI for review of comment 34

Same as for Bug 1912501 : I missed its closure to put my NI. I need a permission to add a comment in closed Bug 1912501 but to who ? How ?

Comment 37

[Dianna Smith [:diannaS]]

:iBenny could you confirm what nightly build you are still experiencing the issue with? You could find the build id in the about:support page.
Also, Ive reopened bug 1912501.

Comment 38

[iBenny]

(In reply to Dianna Smith [:diannaS] from comment #37)

:iBenny could you confirm what nightly build you are still experiencing the issue with? You could find the build id in the about:support page.
Also, Ive reopened bug 1912501.

131.0a1 (2024-08-26) (64 bits)
Comp ID : 20240826094418

The issue arise when checking the "Performance | material acceleration" setting "ON".
The issue arise with Youtube videos and news site videos. Not in Rumble neither in Odysee.

See here : https://www.cjoint.com/doc/24_08/NHAr5YwMPn6_FF-acc%C3%A9l%C3%A9ration-bug.jpg

Comment 39

[Kelsey Gilbert [:jgilbert]]

This bug as reported by the reporter is fixed.

iBenny: It sounds like you should open a new bug for your issue, since it's clear it is different than the issue other people were having! We can investigate your issue better there.

Comment 40

[Daniel Bodea [:danibodea]]

I can confirm this fix in Beta v131.0b1 and Nightly v132.0a1. The WebRTC stream is displayed with correct coloration on Windows 10 with HDR monitor.

I have also reported a similar issue observed with screen sharing video stream as bug 1916707. Thank you.