1642854 - (hdr-video-linux) HDR video support for Linux

Status: NEW

(Core :: Audio/Video: Playback, enhancement)

Description

[romulasry]

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

Steps to reproduce:

Go to https://www.youtube.com/channel/UCve7_yAZHFNipzeAGBI5t9g/ and view a video on Linux.

Actual results:

VIdeos were in SDR

Expected results:

Been in HDR

Comment 1

[romulasry]

(In reply to romulasry from comment #0)

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

Steps to reproduce:

Go to https://www.youtube.com/channel/UCve7_yAZHFNipzeAGBI5t9g/ and view a video on Linux.

Actual results:

VIdeos were in SDR

Expected results:

Been in HDR

Comment 2

[BugBot [:suhaib / :marco]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Elle Solomina (she/her)]

Hey! It's still not working properly in Firefox 79 Oo Rly??? It's not a platform issue, on Windows and Linux, and Android is absolutely same, Firefox not working with HDR.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

To have a roadmap here let's point out some tasks we need to finish to have HDR support on Linux:

• Extend existing NativeLayerWayland() to support external images (that's how video frames are injected to renderer). MacOS variant is here: https://phabricator.services.mozilla.com/D84638
• Extend DMABufSurfaces to hold HDR YUV surfaces (10-bit formats)
• Extend DMABufSurfaces to hold HDR color data
• Pass HDR data from FFmpeg decoder via DMABufSurfaces to MozContainer (or something else) and apply them during wl_surface_commit
• Propagate Linux/HDR support so web playes can serve us HDR content (i.e. clips in bt.2020 color space with yuv420p10 bit planes)
• Optionally update NativeLayerRootWayland to do local composition (by GL?) and send to Wayland compositor as less subsurfaces as possible.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Attachment: hdr-wip-2.patch

WIP v.2 patch, mostly contains unification for layer and multi buffer code.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1642854 [Wayland] hdr patch

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Attachment: WIP: Bug 1642854 [WIP][Wayland] hdr patch v.14 - viewport scale

Comment 8

[Martin Stránský [:stransky] (ni? me)]

A new patch which uses viewport scale instead of buffer scale. It should fix all the "wrong buffer size" bugs when Firefox is moved between screens with different scales. We can also remove all the stuff we use to stop compositor rendering during scale changes at nsWindow.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1642854 [WIP][Wayland] hdr patch v.16

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Attachment: WIP: Bug 1642854 [WIP][Wayland] hdr patch v.23

Comment 11

[Martin Stránský [:stransky] (ni? me)]

The patch here implements very experimental HDR playback. As it's missing correct wl_buffer format negotiation (Bug 1743631) and trows whatever it has to compositor it tends to crash due to unsupported modifiers. It needs further work on stabilization, layers rendering optimization and some layers fixes (D&D is broken due to missing layer screenshotter and there are rendering errors on scrolling).

Comment 12

[s.zharkoff]

I have tried 135beta1, 135beta2, trunk from yesterday morning - where fixes for wayland surfaces applied.

Everywhere notice a power consumption regression on idle. Same pages opened in 134 consumes 5 watts average on idle, 135 and trunk - 8 watts.
When playing videos on youtube the difference is not so big but still seems to be there - around 10 watts 134 and 11-12 135 and higher.

The FF processes in 135 and 134 seems to consume about the same CPU but with 135 version and higher compositor always runs at 10-13% CPU even when nothing is happening in FF. With 134 version at the same condition compositor is somewhere at the end of process list using abut 1%.

I understand that this is a very early WIP stage and such things is normal at this moment, just want to make early warning that there is something wrong in new wayland code related to the idle CPU/battery usage.

Use wayfire compositor based on wlroots 18.2.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

(In reply to s.zharkoff from comment #12)

I have tried 135beta1, 135beta2, trunk from yesterday morning - where fixes for wayland surfaces applied.

Everywhere notice a power consumption regression on idle. Same pages opened in 134 consumes 5 watts average on idle, 135 and trunk - 8 watts.
When playing videos on youtube the difference is not so big but still seems to be there - around 10 watts 134 and 11-12 135 and higher.

The FF processes in 135 and 134 seems to consume about the same CPU but with 135 version and higher compositor always runs at 10-13% CPU even when nothing is happening in FF. With 134 version at the same condition compositor is somewhere at the end of process list using abut 1%.

I understand that this is a very early WIP stage and such things is normal at this moment, just want to make early warning that there is something wrong in new wayland code related to the idle CPU/battery usage.

Use wayfire compositor based on wlroots 18.2.

Do you mean with the WIP: Bug 1642854 [WIP][Wayland] hdr patch v.19 patch applied or without it?
Thanks.

Comment 14

[s.zharkoff]

Do you mean with the WIP: Bug 1642854 [WIP][Wayland] hdr patch v.19 patch applied or without it?
Thanks.

It was before applying this patch. As I understand this patch will not be in 135 - but 135 is already broken. Is this patch supposed to fix the idle issue?

wlroots is not yet capable of HDR signalling, so I do not expect to get HDR on my display and just view regular SDR videos, so in fact the issue is not because of sdr but because of some changes how ff talks with compositor, and those changes already landed in 135. So I guess my coments are not for thos patch but for the whole big wayland rework being done to allow HDR to happen.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

(In reply to s.zharkoff from comment #14)

Do you mean with the WIP: Bug 1642854 [WIP][Wayland] hdr patch v.19 patch applied or without it?
Thanks.

It was before applying this patch. As I understand this patch will not be in 135 - but 135 is already broken. Is this patch supposed to fix the idle issue?

wlroots is not yet capable of HDR signalling, so I do not expect to get HDR on my display and just view regular SDR videos, so in fact the issue is not because of sdr but because of some changes how ff talks with compositor, and those changes already landed in 135. So I guess my coments are not for thos patch but for the whole big wayland rework being done to allow HDR to happen.

Okay, please file a new bug for it, I'll look at it. Please attach your about:support there.
Thanks.

Comment 16

[s.zharkoff]

Created the new bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1940924

Comment 17

[Martin Stránský [:stransky] (ni? me)]

With the v.21 patch HDR is supposed to work. It includes dmabuf feedback and direct composition from external dmabuf surfaces (WebGL/VA-API). SW HDR rendering is not supported yet so you need VA-API decode of VP9 Profile 2 to decode P10 formats. It's under gfx.wayland.hdr pref.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

There are still some bugs remaining - D&D doesn't work due to missing snapshotter and there are rendering artifacts like missing tiles during scrolling.

Comment 19

[Amine Hassane]

With the latest patch Firefox crashes for me upon starting a HDR video with this error:
GFX1-]: (kde) Wayland protocol error: zwp_linux_buffer_params_v1#857: error 7: importing the supplied dmabufs failed.

Comment 20

[Jonathan Bennett]

I'm also running into https://bugzilla.mozilla.org/show_bug.cgi?id=1732051 trying to test this. Once vsync is disabled, seeing the same error as Amine. Fedora 41 KDE, on an AMD card.

Comment 21

[Robert Mader [:rmader]]

FTR., for fully correct playback we'll also need to implement the color representation protocol - which is getting ready as well.

It mainly needed to tell the compositor whether to use BT601, BT709 or BT2020 matrix coefficients (and limited or full range) in the YCbCr->RGB conversion. Without that compositors like Mutter and KMS drivers will usually default to BT709 while one wants BT2020 for HDR10. The visual impact is not too bad, but visible once you compare directly next to each other.

See also my MR for Gstreamer as example.

Comment 22

[Martin Stránský [:stransky] (ni? me)]

Hello Robert,
we use xx_color_manager_v4 to set surface colorspace:
https://searchfox.org/mozilla-central/rev/d1fbe983fb7720f0a4aca0e748817af11c1a374e/widget/gtk/WaylandSurface.cpp#1356
isn't that enough?
Thanks.

Comment 23

[Robert Mader [:rmader]]

Only for RGB content like games. For YCbCr/YUV content, which is what we're aiming for here, you additionally need the matrix coefficients and range (and in theory chroma location) as specified in ITU-T Rec. 273 - i.e. for HDR10 you want the PQ curve (XX_COLOR_MANAGER_V4_TRANSFER_FUNCTION_ST2084_PQ) and the BT2020 primaries (XX_COLOR_MANAGER_V4_PRIMARIES_BT2020) from the color protocol in combination with BT2020 coefficients/limited range (WP_COLOR_REPRESENTATION_V1_COEFFICIENTS_BT2020/WP_COLOR_REPRESENTATION_V1_RANGE_LIMITED) from the color representation protocol.

But the color representation protocol won't make it into Gnome 48 anyways (I only added some initial plumbing for the KMS properties here) and the error is not too bad. Once the protocol lands - likely in 49 - it should be an easy addition. I just wanted to give you a heads-up.

Some context:

• Weston implementation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1682

Comment 24

[Shengyu Qu [:Stat_headcrabbed]]

Final version of wayland color management protocol has just been merged: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/color-management/color-management-v1.xml?ref_type=heads

Comment 25

[GreyXor]

Hello,
Just tried latest nightly and now it run correctly on sway with gfx.webrender.compositor.force-enabled
but I got crashes after randomly navigation

• https://crash-stats.mozilla.org/report/index/d2ee6e63-0cbf-43bc-ac5e-2ffe60250220
• https://crash-stats.mozilla.org/report/index/5cdc4aa3-2c69-4f77-a853-f478d0250220
• https://crash-stats.mozilla.org/report/index/24f593f3-adc5-4535-a5bf-26a780250220

Should I create new issues for that ?

Comment 26

[Martin Stránský [:stransky] (ni? me)]

(In reply to GreyXor from comment #25)

Hello,
Just tried latest nightly and now it run correctly on sway with gfx.webrender.compositor.force-enabled
but I got crashes after randomly navigation

• https://crash-stats.mozilla.org/report/index/d2ee6e63-0cbf-43bc-ac5e-2ffe60250220
• https://crash-stats.mozilla.org/report/index/5cdc4aa3-2c69-4f77-a853-f478d0250220
• https://crash-stats.mozilla.org/report/index/24f593f3-adc5-4535-a5bf-26a780250220

Should I create new issues for that ?

Yes please, you can file as blocking this one.

Comment 27

[Shengyu Qu [:Stat_headcrabbed]]

Btw we still have some color management issues even in SDR mode, which really needs paying attention on:
https://bugzilla.mozilla.org/show_bug.cgi?id=1939259
https://bugzilla.mozilla.org/show_bug.cgi?id=1834978

Comment 28

[GreyXor]

Latest build : https://hg.mozilla.org/mozilla-central/rev/54c1adbab9fb0376a3a0521762af1e52070bb2a5
Cannot see video anymore

tested https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
I can hear the sound, but the image remains black
with gfx.webrender.compositor.force-enabled

Comment 29

[GreyXor]

There a regression with VRR with compositor.force-enabled VRR is not working anymore.

I'm using vbltest to check the actual real refresh rate of my output.

Doing nothing: 32fps
Open nautilus and doing nothing: 32fps
Moving mouse anywhere: 60fps
Open firefox: 60fps
doing nothing in firefox: 60fps
open firefox (without compositor.fore-enabled): 32fps

If I disable compositor.force-enabled then vrr is working as expected again

Comment 30

[Martin Stránský [:stransky] (ni? me)]

(In reply to GreyXor from comment #29)

There a regression with VRR with compositor.force-enabled VRR is not working anymore.

I'm using vbltest to check the actual real refresh rate of my output.

Doing nothing: 32fps
Open nautilus and doing nothing: 32fps
Moving mouse anywhere: 60fps
Open firefox: 60fps
doing nothing in firefox: 60fps
open firefox (without compositor.fore-enabled): 32fps

If I disable compositor.force-enabled then vrr is working as expected again

That's possible, please file a new bug for it.
Thanks.

Comment 31

[GreyXor]

(In reply to GreyXor from comment #28)

Latest build : https://hg.mozilla.org/mozilla-central/rev/54c1adbab9fb0376a3a0521762af1e52070bb2a5
Cannot see video anymore

tested https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
I can hear the sound, but the image remains black
with gfx.webrender.compositor.force-enabled

what about this issue :stransky ? Should I open a new issue too ? it's basically videos are not working anymore with compositor on

Comment 32

[Martin Stránský [:stransky] (ni? me)]

(In reply to GreyXor from comment #31)

(In reply to GreyXor from comment #28)

Latest build : https://hg.mozilla.org/mozilla-central/rev/54c1adbab9fb0376a3a0521762af1e52070bb2a5
Cannot see video anymore

tested https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
I can hear the sound, but the image remains black
with gfx.webrender.compositor.force-enabled

what about this issue :stransky ? Should I open a new issue too ? it's basically videos are not working anymore with compositor on

Yes, please open a new bug for it.
Thanks.

Comment 33

[Jan Alexander Steffens [:heftig]]

Is this supposed to be working? I've enabled .compositor.force-enabled and .wayland.hdr, and something is happening - the video gets much darker and the overlaid video controls are not rendered correctly (posterization) - but it doesn't actually seem to be HDR. It doesn't get any brighter than the UI and the video is still affected by GNOME's HDR Brightness slider.

I've managed to get an HDR image out of mpv, so HDR seems to be working in general, just not in Firefox.

I've tested with https://www.youtube.com/watch?v=5z43FTxB30A.

Firefox Nightly
GNOME 48
Arch Linux

Comment 34

[Martin Stránský [:stransky] (ni? me)]

(In reply to Jan Alexander Steffens [:heftig] from comment #33)

Is this supposed to be working? I've enabled .compositor.force-enabled and .wayland.hdr, and something is happening - the video gets much darker and the overlaid video controls are not rendered correctly (posterization) - but it doesn't actually seem to be HDR. It doesn't get any brighter than the UI and the video is still affected by GNOME's HDR Brightness slider.

I've managed to get an HDR image out of mpv, so HDR seems to be working in general, just not in Firefox.

I've tested with https://www.youtube.com/watch?v=5z43FTxB30A.

Firefox Nightly
GNOME 48
Arch Linux

Please file as separated bug. It's still WIP.

Comment 35

[[:dmwp]]

Looks like this broke something else: enabling gfx.wayland.hdr (Firefox 137 release, Arch Linux) results in "unpainted"/uninitialized areas randomly appearing when scrolling, which turns back to normal whenever a UI element updates itself: https://0x0.st/82JG.png

Comment 36

[Martin Stránský [:stransky] (ni? me)]

(In reply to alekseipesorin from comment #35)

Looks like this broke something else: enabling gfx.wayland.hdr (Firefox 137 release, Arch Linux) results in "unpainted"/uninitialized areas randomly appearing when scrolling, which turns back to normal whenever a UI element updates itself: https://0x0.st/82JG.png

Please test latest nightly only.

Comment 37

[Shengyu Qu [:Stat_headcrabbed]]

Color representation protocol is ready to get merged, seems we can start supporting it?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183#note_2867502

Comment 38

[Martin Stránský [:stransky] (ni? me)]

(In reply to wiagn233 from comment #37)

Color representation protocol is ready to get merged, seems we can start supporting it?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183#note_2867502

Can you explain what's that and how/why we should use it?
Thanks?

Comment 39

[Shengyu Qu [:Stat_headcrabbed]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #38)

(In reply to wiagn233 from comment #37)

Color representation protocol is ready to get merged, seems we can start supporting it?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183#note_2867502

Can you explain what's that and how/why we should use it?
Thanks?

Robert have talked about this above: https://bugzilla.mozilla.org/show_bug.cgi?id=1642854#c23

Comment 40

[Martin Stránský [:stransky] (ni? me)]

Okay, but is not supported in Gnome yet. Let's wait until it's there.

Comment 41

[s.zharkoff]

tried to build latest source - and with hdr compositor enabled see the issue with scrolling.
Reported it here -
https://bugzilla.mozilla.org/show_bug.cgi?id=1962033

This was happening some time ago, then fixed - now looks like it is back again.

Comment 42

[Anton Valishin]

This happens on fedora 24 kde on firefox built by fedora when gfx.wayland.hdr is enabled
https://www.youtube.com/watch?v=xL4_DLU5TmY

Firefox
Version 138.0.3
Build ID 20250512220248
Distribution ID fedora
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0
OS Linux 6.14.6-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 9 20:11:19 UTC 2025
OS Theme Breeze / Adwaita
Window Protocol wayland

Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × 13th Gen Intel® Core™ i9-13900K
Memory: 94.0 GiB of RAM
Graphics Processor 1: Intel® Graphics

Comment 43

[Anton Valishin]

Attachment: hdr.mp4

Comment 44

[Anton Valishin]

Comment on attachment 9490323 [details]
hdr.mp4

wrong bug, sorrry

Comment 45

[kode54]

This happens on Arch Linux, running their stable builds of Firefox, and continues to happen with the latest stable.

Firefox
Version 141.0
Build ID 20250721102543
Distribution ID archlinux
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:141.0) Gecko/20100101 Firefox/141.0
OS Linux 6.16.0-rc7-2-cachyos-rc #1 SMP PREEMPT_DYNAMIC Wed, 23 Jul 2025 06:39:47 +0000
OS Theme adw-gtk3-dark / adw-gtk3 (The video was captured from Breeze, though)
Window Protocol wayland

Operating System: Arch Linux
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.16.0-rc7-2-cachyos-rc (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7700X
Memory: 64.0 GiB of RAM
Graphics Processor 1: AMD Radeon RX 7700 XT

https://youtu.be/y4cstqYvsQI

The problem does not replicate with Nightly. I have another issue that does occur with Nightly, which I will post in a second comment.

Comment 46

[kode54]

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is that the HDR video on YouTube appears to be completely blown out, compared to a properly configured mpv using gpu-next and Vulkan HDR, which plays it with the correct color grading.

Firefox
Version 143.0a1
Build ID 20250723074135
Distribution ID archlinux
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0
OS Linux 6.16.0-rc7-2-cachyos-rc #1 SMP PREEMPT_DYNAMIC Wed, 23 Jul 2025 06:39:47 +0000
OS Theme adw-gtk3-dark / adw-gtk3
Window Protocol wayland

Operating System: Arch Linux
Gnome mutter version: 48.4-1
Kernel Version: 6.16.0-rc7-2-cachyos-rc (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7700X
Memory: 64.0 GiB of RAM
Graphics Processor 1: AMD Radeon RX 7700 XT

https://youtu.be/pvMdap1yw6M (Taking longer than expected to process, probably because it's an HDR screen capture.)

Comment 47

[kode54]

(In reply to kode54 from comment #45)

This problem does occur on Nightly, only slightly different, especially since it's happening differently in Gnome.

There's another issue with Stable as well. When I enable gfx.wayland.hdr there, SDR videos don't play at all in YouTube. They present as a green frame instead of the actual picture. HDR videos play, and play with the correct color, unlike Nightly.

Comment 48

[kode54]

(In reply to kode54 from comment #46)

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is that the HDR video on YouTube appears to be completely blown out, compared to a properly configured mpv using gpu-next and Vulkan HDR, which plays it with the correct color grading.

Oops, I accidentally recorded my music into that video, so I had to delete it. Uploaded another:

https://youtu.be/Hw2JcsIJ7QU

Comment 49

[Martin Stránský [:stransky] (ni? me)]

(In reply to kode54 from comment #47)

(In reply to kode54 from comment #45)

This problem does occur on Nightly, only slightly different, especially since it's happening differently in Gnome.

There's another issue with Stable as well. When I enable gfx.wayland.hdr there, SDR videos don't play at all in YouTube. They present as a green frame instead of the actual picture. HDR videos play, and play with the correct color, unlike Nightly.

Please file as separated bug.

Comment 50

[Martin Stránský [:stransky] (ni? me)]

(In reply to kode54 from comment #46)

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is

Bug 1731895

Comment 51

[kode54]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #49)

(In reply to kode54 from comment #47)

(In reply to kode54 from comment #45)

This problem does occur on Nightly, only slightly different, especially since it's happening differently in Gnome.

There's another issue with Stable as well. When I enable gfx.wayland.hdr there, SDR videos don't play at all in YouTube. They present as a green frame instead of the actual picture. HDR videos play, and play with the correct color, unlike Nightly.

Please file as separated bug.

Sorry about that. Also, I already found an applicable green frame bug.

Comment 52

[kode54]

Huh, my e(In reply to kode54 from comment #48)

(In reply to kode54 from comment #46)

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is that the HDR video on YouTube appears to be completely blown out, compared to a properly configured mpv using gpu-next and Vulkan HDR, which plays it with the correct color grading.

Oops, I accidentally recorded my music into that video, so I had to delete it. Uploaded another:

https://youtu.be/Hw2JcsIJ7QU

Huh, my example video plays correctly, but the original video does not. I figured out the differences here.

My video is:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn (default)

His original video that plays with blown out colors is:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt2020nc/bt2020/arib-std-b67), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn (default)

Comment 53

[Jan Alexander Steffens [:heftig]]

Two different transfer functions - smpte2084 is PQ and arib-std-b67 is HLG. AFAIU GNOME does not support HLG, so Firefox would have to choose PQ and convert the video.

Comment 54

[kode54]

(In reply to Jan Alexander Steffens [:heftig] from comment #53)

Two different transfer functions - smpte2084 is PQ and arib-std-b67 is HLG. AFAIU GNOME does not support HLG, so Firefox would have to choose PQ and convert the video.

I added HLG transfer support to wlroots and labwc, but either it didn't work, or Firefox didn't support it.

Does the transfer function need to be reported as the current output buffer format? It should be reported as a possible alternate surface transfer function.

Comment 55

[kode54]

I just checked:

https://github.com/mozilla-firefox/firefox/blob/96666ecb794f59d5bcba4d5d1d3d5464a650b5be/widget/gtk/WaylandSurface.cpp#L1309-L1310

Firefox just sets ST2084_PQ regardless of what transfer function the video expects.

And I also checked, KDE supports gamma22, but not hlg. So I guess win for me that I added both to wlroots as well, only to find out that my test case isn't using either of them.

Comment 56

[kode54]

It would be great if Firefox could use preferred surface image descriptions in the future. Unfortunately, I don't know how well that's supported by compositors that implement the color management v1 protocol. Currently, wlroots doesn't send that message to clients, and kwin is probably the most likely to currently support it.

Oh well, best stick to what's supported for now, until everyone is on board.

Comment 57

[Martin Stránský [:stransky] (ni? me)]

Please file that as separated bugs blocking this one. We discuss the details there then.
Thanks.

Comment 58

[kode54]

I filed a bug as blocking this one, but it doesn't appear to have registered here?

https://bugzilla.mozilla.org/show_bug.cgi?id=1979908

Comment 59

[Marco Roehrs]

Tried to enable gfx.wayland.hdr on my System.. it worked at first.. (played HDR video on YT) but it had random crashes even when not playing a (HDR) Video.

I reported those crashes.. but no idea where those reports go?!

Fedora 42, KDE Plasma 6.5.1, Firefox 144.0.2 (fedora build)

Comment 60

[Marco Roehrs]

If there is anything to test. I'm happy to deliver real life troubleshooting intel :)

Comment 61

[Martin Stránský [:stransky] (ni? me)]

Please test only latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries

Comment 62

[Marco Roehrs]

Fedora 43 (kernel 6.17.7), KDE Plasma 6.5.2, Firefox 147.0a1 (2025-11-16) (64-bit)

i had to activate gfx.wayland.hdr AND gfx.wayland.hdr.force-enabled to make youtube offer HDR.

playback works, no crashes.. BUT: it looks washed out.

I've checked "Enable HDR", 10bits per color and calibrated it in Plasma Display Configuration

if you need more info (logs etc. let me know how to provide them)

Youtube Nerd-Overlay shows Color smptre2084 (PQ) / bt2020

Comment 63

[Marco Roehrs]

(In reply to Marco Roehrs from comment #62)

Fedora 43 (kernel 6.17.7), KDE Plasma 6.5.2, Firefox 147.0a1 (2025-11-16) (64-bit)

i had to activate gfx.wayland.hdr AND gfx.wayland.hdr.force-enabled to make youtube offer HDR.

playback works, no crashes.. BUT: it looks washed out.

I've checked "Enable HDR", 10bits per color and calibrated it in Plasma Display Configuration

if you need more info (logs etc. let me know how to provide them)

Youtube Nerd-Overlay shows Color smptre2084 (PQ) / bt2020

GPU is Intel integrated Arc (185h / meteorlake)
Monitor is PG27UCDM attached over hdmi cable to Laptop, running at 4k, 10bit, 120hz

Comment 64

[Martin Stránský [:stransky] (ni? me)]

(In reply to Marco Roehrs from comment #62)

Fedora 43 (kernel 6.17.7), KDE Plasma 6.5.2, Firefox 147.0a1 (2025-11-16) (64-bit)

i had to activate gfx.wayland.hdr AND gfx.wayland.hdr.force-enabled to make youtube offer HDR.

playback works, no crashes.. BUT: it looks washed out.

I've checked "Enable HDR", 10bits per color and calibrated it in Plasma Display Configuration

if you need more info (logs etc. let me know how to provide them)

Youtube Nerd-Overlay shows Color smptre2084 (PQ) / bt2020

Please file a new bug for it which blocks this one.
Thanks.

Comment 65

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jimm, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 66

[Martin Stránský [:stransky] (ni? me)]

Would be great to get any performance data how the HDR mode affect overall desktop performance - as we move compositing from Firefox to desktop and also do rapid map/unmap of surfaces during scrolling for instance.

Comment 67

[Thibault [:thibaulltt]]

Hi, I reported bug 2012285, which seems to be similar to Marco's problem a few comments above. I hope this can be somehow linked to this bug :)

Comment 68

[Shengyu Qu [:Stat_headcrabbed]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #66)

Would be great to get any performance data how the HDR mode affect overall desktop performance - as we move compositing from Firefox to desktop and also do rapid map/unmap of surfaces during scrolling for instance.

Kernel KMS color pipeline API would land in next kernel version and KDE also needs this PR to fully utilize color pipeline API to do HW MPO offload, so we won't see much performance difference now.

Comment 69

[Jeff Muizelaar [:jrmuizel]]

Martin, out of curiosity, what things do you think are needed to have HDR video enabled by default?

Comment 70

[Martin Stránský [:stransky] (ni? me)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #69)

Martin, out of curiosity, what things do you think are needed to have HDR video enabled by default?

Bug 1731895 is the main blocker here (and then testing).

Comment 71

[Sotaro Ikeda [:sotaro]]

:stransky, what is current status of HDR support on Linux? And does the HDR support need WebRender layer compositor?

Comment 72

[Martin Stránský [:stransky] (ni? me)]

(In reply to Sotaro Ikeda [:sotaro] from comment #71)

:stransky, what is current status of HDR support on Linux?

Roughly works on unscaled displays. Scaled displays need scale-v2 wayland extension support which is implemented as experimental feature on KDE and missing on Mutter (KDE aims to ship at 6.13).

Generally we need more testing of webrender compositor on Linux (running on testsuite, speed testing etc.)

And does the HDR support need WebRender layer compositor?

No, it works also with old webrender compositor. Haven't tested the WebRender layer compositor yet.

Comment 73

[GreyXor]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #72)

(In reply to Sotaro Ikeda [:sotaro] from comment #71)

:stransky, what is current status of HDR support on Linux?
Roughly works on unscaled displays. Scaled displays need scale-v2 wayland extension support which is implemented as experimental feature on KDE and missing on Mutter (KDE aims to ship at 6.13).

Also missing in wlroots: https://gitlab.freedesktop.org/wlroots/wlroots/-/work_items/4086
emersion don't seems to be a fan of this protocol

Comment 74

[Martin Stránský [:stransky] (ni? me)]

(In reply to GreyXor from comment #73)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #72)

(In reply to Sotaro Ikeda [:sotaro] from comment #71)

:stransky, what is current status of HDR support on Linux?
Roughly works on unscaled displays. Scaled displays need scale-v2 wayland extension support which is implemented as experimental feature on KDE and missing on Mutter (KDE aims to ship at 6.13).

Also missing in wlroots: https://gitlab.freedesktop.org/wlroots/wlroots/-/work_items/4086
emersion don't seems to be a fan of this protocol

We need something to proceed here, and we don't have anything better.

Comment 75

[Louis-Philippe Manette [:louisphilippe]]

Hi everyone,

I'm running KDE Wayland Plasma 6.7.3 in HDR mode with an AMD RX 9060 XT on Gentoo (FF 152.0.6), and I ran into two issues: PQ HDR videos look washed out (SDR luminance), and HLG videos (like on YouTube) simply crash Firefox.

I looked into the code and found:

• MaxCLL/MaxFALL aren't passed to wp_image_description_creator_params_v1_create in WaylandSurface::EnableColorManagementLocked, causing the washed-out colors.
• The crash happens when requesting HLG in the same method.

I made a local fix to wire HDRMetadata through DMABufSurfaceYUV down to the WaylandSurface. To stop the HLG crash, I temporarily forced a fallback to PQ (I know colors are wrong without tone mapping, but it prevents the crash with my configuration).

Would you be interested in a patch for the HDRMetadata plumbing, or is this already in progress?

Comment 76

[Brad Werth [:bradwerth]]

(In reply to Louis-Philippe from comment #75)

Would you be interested in a patch for the HDRMetadata plumbing, or is this already in progress?

Thank you for finding this and for posting the issue. Please open this as a new Bug, which blocks this Bug -- meta Bugs are never landed, never closed. The new Bug should have a test video if possible, and also add a comment with the text of "about:support" on your system. And of course also add your proposed fix to the Bug. That will make it very clear what is being fixed and how.

Comment 77

[Louis-Philippe Manette [:louisphilippe]]

Hi!
Thank you for your answer.
I submitted 2057751

I removed the changes regarding HLG because it's a different issue.
-> With my configuration, at least, KWin doesn't support HLG and crash firefox if it demands this transfert function. It crash when playing or hovering HLG content in youtube.

I will make another ticket for this issue.

Comment 78

[Louis-Philippe Manette [:louisphilippe]]

I submitted 2057813 for the crash with HLG videos.

Comment 79

[Martin Stránský [:stransky] (ni? me)]

Sotaro, do I understand correctly the the recent plan is to move to layer compositor (Bug 1959009 / gfx.webrender.layer-compositor=true) by default and run HDR there?
Thanks.

Comment 80

[Sotaro Ikeda [:sotaro]]

We do not have a clear plan to move to layer compositor yet. To support HDR android, we need to use layer compositor(with ASurfaceControl). And to enable layer compositor on macOS and software webrender, we need to address performance problem by borrowing some implementation from native compositor.

And I did not check about performance change with layer compositor on Wayland.

If HDR does not need layer compositor with Wayland, we could enable HDR without layer compositor.

Comment 81

[Sotaro Ikeda [:sotaro]]

:ahale, what is the current plan of HDR on walyand?

Comment 82

[Martin Stránský [:stransky] (ni? me)]

And what's the key difference between old compositor and layer compositor?

Comment 83

[laichiaheng]

Hi, after the latest update from https://bugzilla.mozilla.org/show_bug.cgi?id=2057813
The video brightness of PQ seems to be too dark.

Comment 84

[Louis-Philippe Manette [:louisphilippe]]

(In reply to laichiaheng from comment #83)

Hi, after the latest update from https://bugzilla.mozilla.org/show_bug.cgi?id=2057813
The video brightness of PQ seems to be too dark.

Hi, thanks for testing the latest build and reporting this!

Since I authored the recent Wayland HDR update in Bug 2057813, I'd like to investigate why PQ content is rendering too dark for you. To help me reproduce and trace the issue, could you please provide:

1. A link to an example video where you are seeing this behavior.
2. The output when playing that video after launching firefox with the following command
   WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayland:5,ColorManagement:5" firefox 2>&1 | grep -i tf_named

Thanks for your help!

Comment 85

[laichiaheng]

https://www.youtube.com/watch?v=onVhbeY7nLM&t=62s

You mean the output from terminal?

[2257227.978] {Default Queue} wp_color_manager_v1#49.supported_tf_named(2)
[2257227.983] {Default Queue} wp_color_manager_v1#49.supported_tf_named(11)
[2257227.988] {Default Queue} wp_color_manager_v1#49.supported_tf_named(5)
[2257227.992] {Default Queue} wp_color_manager_v1#49.supported_tf_named(1)
[2257918.771] {Default Queue} wp_image_description_info_v1#75.tf_named(2)
[2304907.712] {Default Queue}  -> wp_image_description_creator_params_v1#112.set_tf_named(11)
[2307064.662] {Default Queue}  -> wp_image_description_creator_params_v1#356.set_tf_named(11)
[2308536.456] {Default Queue}  -> wp_image_description_creator_params_v1#456.set_tf_named(11)
[2324765.116] {Default Queue}  -> wp_image_description_creator_params_v1#777.set_tf_named(11)
[2345507.725] {Default Queue}  -> wp_image_description_creator_params_v1#423.set_tf_named(11)
[2346734.415] {Default Queue}  -> wp_image_description_creator_params_v1#951.set_tf_named(11)

Comment 86

[Louis-Philippe Manette [:louisphilippe]]

Yes I meant the terminal output, sorry. Thank you for the traces and the video example.

The change 2057813 adds a check to fail in the case the transfer function isn't supported.
The terminal output confirms that your compositor supports the PQ transfer function (tf=11) and Firefox is correctly requesting it.
According to the log traces the patch should change nothing to the input in your case.
Did you happen to test the exact build right before the update to confirm if the video was brighter?

On my system, I get the exact same PQ luminosity on the video you provided, whether I use a build with or without Bug 2057813.

Though, having a PQ video too dark could be a result of the issue linked to 2057751.

Comment 87

[laichiaheng]

(In reply to Louis-Philippe Manette from comment #86)

Yes I meant the terminal output, sorry. Thank you for the traces and the video example.

The change 2057813 adds a check to fail in the case the transfer function isn't supported.
The terminal output confirms that your compositor supports the PQ transfer function (tf=11) and Firefox is correctly requesting it.
According to the log traces the patch should change nothing to the input in your case.
Did you happen to test the exact build right before the update to confirm if the video was brighter?

On my system, I get the exact same PQ luminosity on the video you provided, whether I use a build with or without Bug 2057813.

Though, having a PQ video too dark could be a result of the issue linked to 2057751.

My bad, after I compare it to the Firefox stable release, the PQ brightness of them are the same, but it is significantly darker than Brave browser and MPV player, I even think that it is playing in SDR.

Comment 88

[Martin Stránský [:stransky] (ni? me)]

I guess we may try to enable HDR on nightly and unscaled displays (as scaled ones depends on missing fractional-scale-v2 in compositors).
We may also enable AMD/Intel only as NVIDIA is blocked by Bug 2012285.

Comment 89

[Ashley Hale [:ahale]]

Also worth noting for any relnote in future on this that the resolution of Bug 2057813 is showing HLG video as SDR if Wayland doesn't support it, I tested on AMD and it doesn't support that (which is ironic because the hardware definitely does), that limitation is fairly severe and was what blocked launching HDR video on Windows. In this case I'd prefer to encourage Wayland developers to support HLG rather than develop our own shader to convert (which was the solution on Windows), but we may end up having too write such a conversion shader to make this shippable if Wayland doesn't support it widely enough.

Comment 90

[Hi-Angel]

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

In this case I'd prefer to encourage Wayland developers to support HLG rather than develop our own shader to convert (which was the solution on Windows), but we may end up having too write such a conversion shader to make this shippable if Wayland doesn't support it widely enough.

Confused, if shader was already written for Windows, why would it need to be written again?

Comment 91

[Martin Stránský [:stransky] (ni? me)]

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

Also worth noting for any relnote in future on this that the resolution of Bug 2057813 is showing HLG video as SDR if Wayland doesn't support it, I tested on AMD and it doesn't support that (which is ironic because the hardware definitely does), that limitation is fairly severe and was what blocked launching HDR video on Windows. In this case I'd prefer to encourage Wayland developers to support HLG rather than develop our own shader to convert (which was the solution on Windows), but we may end up having too write such a conversion shader to make this shippable if Wayland doesn't support it widely enough.

HLG doesn't seem to be supported on Linux compositors at all so the shared may be the option here. Do you convert ti to RGB or something else? And do you blend HDR content or put it directly to windows as HDR video surface/overlay?

Comment 92

[laichiaheng]

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

Comment 93

[Sotaro Ikeda [:sotaro]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #82)

And what's the key difference between old compositor and layer compositor?

Current difference is the followings.

• Use big layers in layer compositor. Native compositor uses tiles for composition.
• Layer compositor has flexibility to change how to composite.

Comment 94

[Louis-Philippe Manette [:louisphilippe]]

(In reply to laichiaheng from comment #92)

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

This is likely related to Bug 2057751.
The fix has just landed in the latest nightly builds. Could you please test it and confirm if it resolves the issue for you?

With this update, I'm getting the exact same luminosity output as mpv on the video you linked.

You can download it here:
https://archive.mozilla.org/pub/firefox/nightly/2026/08/2026-08-12-20-20-37-mozilla-central/

Comment 95

[Louis-Philippe Manette [:louisphilippe]]

(In reply to Louis-Philippe Manette from comment #94)

(In reply to laichiaheng from comment #92)

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

This is likely related to Bug 2057751.
The fix has just landed in the latest nightly builds. Could you please test it and confirm if it resolves the issue for you?

With this update, I'm getting the exact same luminosity output as mpv on the video you linked.

You can download it here:
https://archive.mozilla.org/pub/firefox/nightly/2026/08/2026-08-12-20-20-37-mozilla-central/

You can download it here as well:
https://www.firefox.com/en-US/channel/desktop/#nightly

Comment 96

[Martin Stránský [:stransky] (ni? me)]

(In reply to Sotaro Ikeda [:sotaro] from comment #93)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #82)

And what's the key difference between old compositor and layer compositor?

Current difference is the followings.

• Use big layers in layer compositor. Native compositor uses tiles for composition.
• Layer compositor has flexibility to change how to composite.

I see - looks like something we really want to enable to reduce wayland compositor load and make sure we're enable to promote HDR planes directly. I'd say we should use it by default when HDR on Linux is enabled.

That may also reduce the missing scale-v2 visible artifacts although it may not fix it completely.

Comment 97

[laichiaheng]

(In reply to Louis-Philippe Manette from comment #94)

(In reply to laichiaheng from comment #92)

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

This is likely related to Bug 2057751.
The fix has just landed in the latest nightly builds. Could you please test it and confirm if it resolves the issue for you?

With this update, I'm getting the exact same luminosity output as mpv on the video you linked.

You can download it here:
https://archive.mozilla.org/pub/firefox/nightly/2026/08/2026-08-12-20-20-37-mozilla-central/

It becomes too bright and too saturated on the HLG, and the PQ is still much dimmer than MPV player and Brave browser.
I can offer the comparison later when the HDR processing on YouTube is over.

I use firefox-nightly.x86_64 155.0a1-20260812093659 vs brave-origin.x86_64 1.93.136-1

Comment 98

[Louis-Philippe Manette [:louisphilippe]]

(In reply to laichiaheng from comment #97)

(In reply to Louis-Philippe Manette from comment #94)

(In reply to laichiaheng from comment #92)

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

This is likely related to Bug 2057751.
The fix has just landed in the latest nightly builds. Could you please test it and confirm if it resolves the issue for you?

With this update, I'm getting the exact same luminosity output as mpv on the video you linked.

You can download it here:
https://archive.mozilla.org/pub/firefox/nightly/2026/08/2026-08-12-20-20-37-mozilla-central/

It becomes too bright and too saturated on the HLG, and the PQ is still much dimmer than MPV player and Brave browser.
I can offer the comparison later when the HDR processing on YouTube is over.

I use firefox-nightly.x86_64 155.0a1-20260812093659 vs brave-origin.x86_64 1.93.136-1

If I read the trace you sent previously, the HLG behavior occurs because HLG isn't currently supported by your Wayland compositor:
[2257227.978] {Default Queue} wp_color_manager_v1#49.supported_tf_named(2)
[2257227.983] {Default Queue} wp_color_manager_v1#49.supported_tf_named(11)
[2257227.988] {Default Queue} wp_color_manager_v1#49.supported_tf_named(5)
[2257227.992] {Default Queue} wp_color_manager_v1#49.supported_tf_named(1)

Regarding the PQ issue, could you please share the link to the specific video where you spotted the brightness difference?
Additionally, it would be very helpful if you could provide the terminal output by running the following command while playing that video:
WAYLAND_DEBUG=1 MOZ_LOG="FFmpegVideoDecoder:5,WidgetWayland:5,ColorManagement:5" ./firefox 2>&1 | grep -i -E 'wp_image_description|HDR|wp_color_representation|wp_color_manager|EnableColorManagementLocked'

Comment 99

[Louis-Philippe Manette [:louisphilippe]]

(In reply to laichiaheng from comment #97)

(In reply to Louis-Philippe Manette from comment #94)

(In reply to laichiaheng from comment #92)

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

This is likely related to Bug 2057751.
The fix has just landed in the latest nightly builds. Could you please test it and confirm if it resolves the issue for you?

With this update, I'm getting the exact same luminosity output as mpv on the video you linked.

You can download it here:
https://archive.mozilla.org/pub/firefox/nightly/2026/08/2026-08-12-20-20-37-mozilla-central/

It becomes too bright and too saturated on the HLG, and the PQ is still much dimmer than MPV player and Brave browser.
I can offer the comparison later when the HDR processing on YouTube is over.

I use firefox-nightly.x86_64 155.0a1-20260812093659 vs brave-origin.x86_64 1.93.136-1

Please post the video link and the resulting logs directly in Bug 2057751

Comment 100

[Louis-Philippe Manette [:louisphilippe]]

(In reply to laichiaheng from comment #97)

(In reply to Louis-Philippe Manette from comment #94)

(In reply to laichiaheng from comment #92)

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

This is likely related to Bug 2057751.
The fix has just landed in the latest nightly builds. Could you please test it and confirm if it resolves the issue for you?

With this update, I'm getting the exact same luminosity output as mpv on the video you linked.

You can download it here:
https://archive.mozilla.org/pub/firefox/nightly/2026/08/2026-08-12-20-20-37-mozilla-central/

It becomes too bright and too saturated on the HLG, and the PQ is still much dimmer than MPV player and Brave browser.
I can offer the comparison later when the HDR processing on YouTube is over.

I use firefox-nightly.x86_64 155.0a1-20260812093659 vs brave-origin.x86_64 1.93.136-1

Please can you update your nightly to 20260812202037 and check if it’s solved.

Comment 101

[laichiaheng]

(In reply to Louis-Philippe Manette from comment #99)

(In reply to laichiaheng from comment #97)

(In reply to Louis-Philippe Manette from comment #94)

(In reply to laichiaheng from comment #92)

https://www.youtube.com/watch?v=Mk7GIiZg8M4

Why is the HDR on Firefox nightly so much dimmer than Brave browser?

This is likely related to Bug 2057751.
The fix has just landed in the latest nightly builds. Could you please test it and confirm if it resolves the issue for you?

With this update, I'm getting the exact same luminosity output as mpv on the video you linked.

You can download it here:
https://archive.mozilla.org/pub/firefox/nightly/2026/08/2026-08-12-20-20-37-mozilla-central/

It becomes too bright and too saturated on the HLG, and the PQ is still much dimmer than MPV player and Brave browser.
I can offer the comparison later when the HDR processing on YouTube is over.

I use firefox-nightly.x86_64 155.0a1-20260812093659 vs brave-origin.x86_64 1.93.136-1

Please post the video link and the resulting logs directly in Bug 2057751

I have no permission to post on that link.

Comment 102

[laichiaheng]

Attachment: HLG log

Comment 103

[laichiaheng]

I'm deeply sorry, I didn't know that I need to add the --refresh for dnf to install the latest firefox-nightly, although I could see it in the app list.

After upgrading to the 20260812202037, the brightness of videos in PQ look the same as Brave now, the only problem left is the saturation and brightness of HLG.

I have posted the log from the terminal above, and I will show you how they look after YouTube successfully encoding the the HDR.

Comment 104

[laichiaheng]

Here is how it looks on HLG: The video

As you can see, the one on the right hand side is firefox-nightly, on the left are brave and mpv, the color of firefox-nightly is too saturated.

The source video: https://youtu.be/54YZKj5oQ5I

Comment 105

[Ashley Hale [:ahale]]

(In reply to laichiaheng from comment #104)

Here is how it looks on HLG: The video

As you can see, the one on the right hand side is firefox-nightly, on the left are brave and mpv, the color of firefox-nightly is too saturated.

The source video: https://youtu.be/54YZKj5oQ5I

Speculating, this may be an issue with full range video vs limited range video, as if the video is full range HLG but being displayed as limited range HLG it would make the color range more extreme and saturated.

Comment 106

[Louis-Philippe Manette [:louisphilippe]]

In the case of this video it's a BT2020 limited level vp9 profile 2 video and the color representation is set accordingly
[3435381.649] {Default Queue} -> wp_color_representation_surface_v1#819.set_coefficients_and_range(6, 2)

I think the reason for the colors is that since the compositor doesn't support HLG, WaylandSurface::EnableColorManagementLocked can't set any transfer function for this video.

Comment 107

[Louis-Philippe Manette [:louisphilippe]]

Wayland doesn't expose any default value for TF in the specification but the result looks like as PQ TF is used as default if the colorspace is BT2020.
That may be the default behavior of the compositor in this case.

Comment 108

[laichiaheng]

So it's a KWIN or Wayland problem?

Comment 109

[Marcel]

Could you please comment in the bug that caused the issue or create a separate bug for that specific issue. I think meta bugs are not meant to be used like that.

Comment 110

[Shayan Moraghebi]

On the latest Nightly (Version 156.0a1 (2026-08-18)), HDR videos play correctly on YouTube with color and brightness displayed correctly, and with no side effects or issue found for now. Jellyfin Web reports that the container is not compatible with the color range of the video, unsure if that is a bug with Firefox or Jellyfin though. Using Fedora 44 KDE Plasma Edition on AMD GPU.