User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

1. opened youtube
2. started watching a video
3. oversaturaded playback
4. press the notifaction bell and the saturation fixes itself

Actual results:

The playback of video is completly oversaturated. Same goes for twitch.
Disabling HDR in windows leads to general under saturation but the playback turns also normal.

What i noticed else is clicking the notifaction bell or profile "fixes" the issue as long as it's open.

Between nightly build of 2023-05-11-21-32-13 and 2023-05-13-09-21-59 it started to occur.

Expected results:

Playback should not be oversaturated

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

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6752303f266a1222f277dd00c46c3486b5d9c26e&tochange=2a3a45421336c52fdcb337accef77094b19947c6

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

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

For more information, please visit BugBot documentation.

Naidin, what GPU do you have?

AMD 7900 XTX

Monitor is an AOC AGON AG275QX and Driver was 23.4.3 WHQL

I see the same thing, but it's not just Firefox, my entire desktop is oversaturated.

What notification are you referring to here?

'press the notifaction bell and the saturation fixes itself'

The colours also correct when I try to use the windows snipping tool thats why I took photos with the phone.

Not sure, but this might have something to do with the video playback work Sotaro has been working on. The notification is an overlay on top of the video, which sounds a bit like what we experienced on the macos hdr work with video overlays.

Sorry, I missed the regression relationship here. Looks like a regression from some work Kelsey did.

The bug is marked as tracked for firefox114 (beta). However, the bug still isn't assigned.

:jimm, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #14)

The bug is marked as tracked for firefox114 (beta). However, the bug still isn't assigned.

:jimm, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Simply backing out the regressor which itself was a regression, will again 'regress' colour management other than HDR video.
This would become a ping-pong between two issues: either render images/web-content correctly OR render HDR video correctly.

The original value for native_srgb used to be false pre 113, suddenly it was changed to true and now reverting to the original value false breaks HDR video. Conclusion the real regression is a change in a (HDR) video component that now requires the flag to be true to function properly.

(In reply to Alice0775 White from comment #2)

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6752303f266a1222f277dd00c46c3486b5d9c26e&tochange=2a3a45421336c52fdcb337accef77094b19947c6

Regression window w/ force setting gfx.color_management.native_srgb to false
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=decd6920ef5201a5b549ede7956c90a4fb00ad7e&tochange=59c2b380d4740b9113040b9579c7e272c570778d

FWIW,
Setting gfx.webrender.dcomp-video-overlay-win to false seems to fix this problem on Nightly115.0a1 Windows10 without changing the other preferences.

(In reply to Alice0775 White from comment #17)

FWIW,
Setting gfx.webrender.dcomp-video-overlay-win to false seems to fix this problem on Nightly115.0a1 Windows10 without changing the other preferences.

I needed to restart the browser as well, but it does fix it for me on 114.0b4.

Bug 1760724 seems to interfere with video color management, so let's mark it as a block bug.

(In reply to Alice0775 White from comment #17)

FWIW,
Setting gfx.webrender.dcomp-video-overlay-win to false seems to fix this problem on Nightly115.0a1 Windows10 without changing the other preferences.

can confirm switching this solves it for me under Win 11 with 115.0a1

There was confusion about the purpose of this pref. Just hard code
it for now.

AFAICT, this and related bugs don't seem to be impacting 113.0.1, so updating the status for 113 accordingly.

On non-Intel GPU on Windows, gfx.webrender.dcomp-video-overlay-win is false by default, except in Early Beta and Nightly.

https://hg.mozilla.org/mozilla-central/rev/4210d649f10b