Closed Bug 1833030 Opened 1 year ago Closed 1 year ago

HDR playback oversaturated

Categories

(Core :: Graphics: Color Management, defect)

Firefox 115
defect

Tracking

()

RESOLVED FIXED
115 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox113 --- disabled
firefox114 + disabled
firefox115 --- fixed

People

(Reporter: fundaris, Assigned: jrmuizel)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

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

See Also: → 1832881

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.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

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?

Flags: needinfo?(fundaris)

AMD 7900 XTX

Flags: needinfo?(fundaris)

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'

Flags: needinfo?(fundaris)
Attached image Notification opens
Flags: needinfo?(fundaris)

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.

Flags: needinfo?(jgilbert) → needinfo?(sotaro.ikeda.g)

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

Flags: needinfo?(sotaro.ikeda.g) → needinfo?(jgilbert)

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.

Flags: needinfo?(jmathies)

(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.

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.

Blocks: 1760724
Component: Audio/Video: Playback → Graphics: Color Management

(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.

Assignee: nobody → jmuizelaar
Status: NEW → ASSIGNED

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

See Also: → 1833544

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

Flags: needinfo?(jmathies)
Pushed by jmuizelaar@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4210d649f10b
Don't use native_srgb on Windows. r=jgilbert
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch
Flags: needinfo?(jgilbert)
Flags: qe-verify+
See Also: → 1842755
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: