1961610 - HDR video is forced on Youtube on non HDR display and settings

Status: RESOLVED FIXED

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

Description

[Eduard Kachur]

Attachment: about:support

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0

Steps to reproduce:

Linux, Firefox nightly 139 and beta 138
Ubuntu 25.04, Gnome 48
gfx.webrender.compositor disabled
gfx.wayland.hdr disabled

Open HDR video in Youtube

Actual results:

Youtube quality selector shows that HDR video is playing back and video is grayish, doesn't allow to select non HDR format.

Expected results:

Youtube plays standard non HDR video.

Comment 1

[Eduard Kachur]

As a workaround I tried enabling gfx.wayland.hdr, this makes colors look correct, meaning there is some tonemapping active, but with some artifacts and being too bright.
This snippet https://jsfiddle.net/jimmathies/dhws9852/38/ shows this:
screen: no
decode: yes

Comment 2

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

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.

Comment 3

[Jan Alexander Steffens [:heftig]]

I see the same on GNOME 48, Arch Linux, with only a SDR screen.

I tested using https://www.youtube.com/watch?v=5z43FTxB30A

With older builds, YouTube chooses its SDR video, which looks much better. The HDR video is either desaturated (gfx.wayland.hdr off) or too dark (gfx.wayland.hdr on).

Last good revision: ab15b94c2e9bce73b278b1c71af19eb738d654bc
First bad revision: a011cae095cd555562c1798414e8b8dc906105df
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ab15b94c2e9bce73b278b1c71af19eb738d654bc&tochange=a011cae095cd555562c1798414e8b8dc906105df

Regressed by bug 1948007.

I see two issues here:

• With gfx.wayland.hdr off, HDR capability is exposed to YouTube
• With gfx.wayland.hdr on, HDR capability is exposed to YouTube even without a HDR monitor

Comment 4

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

:stransky, since you are the author of the regressor, bug 1948007, could you take a look?

For more information, please visit BugBot documentation.

Comment 5

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

The real issue may be here:
https://searchfox.org/mozilla-central/rev/29184ec2b107c8b9dd8c9a594711c27545dfb2c7/widget/gtk/ScreenHelperGTK.cpp#268

The regression range covers only old/new protocol switch.

Comment 6

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

Attachment: Bug 1961610 [Wayland] Advertise HDR support only of gfx.wayland.hdr pref is set r?emilio

Comment 7

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

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

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3efa51ad1d24
[Wayland] Advertise HDR support only of gfx.wayland.hdr pref is set r=emilio

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

Comment on attachment 9480190 [details]
Bug 1961610 [Wayland] Advertise HDR support only of gfx.wayland.hdr pref is set r?emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Advertise HDR video playback capability although HDR itself is disabled so if user selects HDR broken video is played.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Disable HDR according to pref (which is off by default).
• String changes made/needed:
• Is Android affected?: No

Comment 10

[Eduard Kachur]

Doesn't look clear why IsHDREnabled returns true, could that be some mutter bug?

Comment 11

[Sandor Molnar[:smolnar]]

Backed out for causing build bustage & mochitest failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/2ba81390e44f1a9653721a7c156f810335510052

Push with failures

Failure log bustage

Failure log mochitest

Comment 12

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

Attachment: Bug 1961610 [Wayland] Fix pref include file r?emilio

Comment 13

[Jan Alexander Steffens [:heftig]]

(In reply to Eduard Kachur from comment #10)

Doesn't look clear why IsHDREnabled returns true, could that be some mutter bug?

That function currently checks for the ability to create parametric image descriptions, which is used to signal the HDR colorspace information to the compositor. This is always available and doesn't tell you whether any output supports HDR.

I think Firefox needs to check the outputs' parameters (maybe maximum luminance or PQ transfer function?) whenever a website queries either HDR decoding or HDR display, to avoid getting locked into HDR on/off at startup (this is assuming gfx.wayland.hdr is enabled).

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/11bb99361d4c
[Wayland] Advertise HDR support only of gfx.wayland.hdr pref is set r=emilio

Comment 15

[Eduard Kachur]

So it looks like current implementation even with config check, could create a situation with dual displays, that HDR playback will be enabled for non HDR display.

Comment 16

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

(In reply to Eduard Kachur from comment #15)

So it looks like current implementation even with config check, could create a situation with dual displays, that HDR playback will be enabled for non HDR display.

Yes, you're right.

Comment 17

[pstanciu]

Backed out for causing failures on StaticPrefList_layers.h

• Backout link
• Push with failures
• Failure Log

Comment 18

[Jan Alexander Steffens [:heftig]]

It looks like the MakeScreenGtk runs before prefs are loaded? So accessing an AtStartup pref locks all of them in, and when prefs are actually loaded later you run into an assert.

Comment 19

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

That's interesting, Thanks.

Comment 20

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

Attachment: Bug 1961610 [Wayland] Don't advertise HDR support on Wayland r?emilio

Comment 21

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

Comment on attachment 9480518 [details]
Bug 1961610 [Wayland] Don't advertise HDR support on Wayland r?emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: HDR content is served on Wayland where HDR protocol is present which leads to washed out video.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Flip HDR support pref as it was before.
• String changes made/needed:
• Is Android affected?: No

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8a05f6d8590d
[Wayland] Don't advertise HDR support on Wayland r=emilio

Comment 23

[Dianna Smith [:diannaS]]

Comment on attachment 9480518 [details]
Bug 1961610 [Wayland] Don't advertise HDR support on Wayland r?emilio

There are no more betas left in the 138 cycle. Moving the request to release, and leaving this open for consideration into the 138 dot release.

Comment 24

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/8a05f6d8590d

Comment 25

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

The patch landed in nightly and beta is affected.
:stransky, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox138 to wontfix.

For more information, please visit BugBot documentation.

Comment 26

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

Yes, please ship that to release, it's just a pref flip.

Comment 27

[Dianna Smith [:diannaS]]

Comment on attachment 9480518 [details]
Bug 1961610 [Wayland] Don't advertise HDR support on Wayland r?emilio

Approved for 138.0.3

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/8e0b140d5e4b