1995158 - [KDE] Video black level is wrong when using Wayland starting in Firefox 143.0

Status: RESOLVED INVALID

(Core :: Audio/Video, defect, P3)

Description

[PQCraft]

Attachment: Screenshots of before and after the bug

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

Steps to reproduce:

1. Open any video in Firefox

System:

• Machine: Dell Inspiron 15 3525
• OS: Arch Linux
• DE: KDE Plasma 6.4.5
• Kernel: 6.17.2-arch1-1
• CPU: AMD Ryzen 7 5825U (16) @ 4.55 GHz
• GPU: AMD Barcelo iGPU
• RAM: 16GB
• Display: 1920x1080@120Hz, no HDR

Firefox versions tested: 141.0.3, 142.0, 142.0.1, 143.0, 144.0
Out of the tested versions, these were good: 141.0.3, 142.0, 142.0.1
and these were bad: 143.0, 144.0

Actual results:

On Firefox 142.0.1 and earlier, the black levels are correct.

On Firefox 143.0 and later, the black levels are NOT correct.

On Firefox 143.0 with the MOZ_ENABLE_WAYLAND=0 env var set (using X11), the black levels are correct.

Expected results:

The black levels should be correct in Firefox 143.0 with Wayland

Comment 1

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

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

Comment 2

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

Can you use mozregression to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
I think we're messing up a color range here.
Thanks.

Comment 3

[PQCraft]

OK I ran ./mozregression/bin/mozregression --profile /home/pqcraft/.mozilla/firefox/3t3wrvx4.PQCraft --profile-persistence clone-first --good 142.0.1 --bad 143.0 (I made a 'mozregression' venv) and at the end, it output:

 1:58.26 INFO: Last good revision: 9ae25996299c1f471793153512de0019ae21d5e0
 1:58.26 INFO: First bad revision: 34357bbd5cd6e347fe53413e39f7f4c44a91208e
 1:58.26 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=9ae25996299c1f471793153512de0019ae21d5e0&tochange=34357bbd5cd6e347fe53413e39f7f4c44a91208e

I will also upload a .txt file with the copy-pasted terminal output

Comment 4

[PQCraft]

Attachment: mozregression terminal output

Comment 5

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

Can you try 'mozregression --good 142 --bad 143' ? That command without .0 tests nightly so it should provide better regression range.

Comment 6

[PQCraft]

Attachment: mozregression terminal output using nightly

OK I ran the same command but used 142 and 143. I looked at the pushlog and this one is A LOT more narrow than the previous one:

 2:43.89 INFO: Last good revision: 18e77fdb7b45fed7699c8144c3cd046fa9042839
 2:43.89 INFO: First bad revision: 6b94b7181a91fdfa24a98279970f22873bec4797
 2:43.89 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=18e77fdb7b45fed7699c8144c3cd046fa9042839&tochange=6b94b7181a91fdfa24a98279970f22873bec4797

Comment 7

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

Yeah, looks like regression from my wp-color-representation-v1 patch - Bug 1961351.
I guess wp-color-representation-v1 is supported on your Plasma setup and then Firefox sets the color range then:
https://phabricator.services.mozilla.com/D260962
Can you check we set that correctly? (WAYLAND_DEBUG=1 may be enough).
Thanks.

Comment 8

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

Also I think that's in HDR mode only, right?

Comment 9

[PQCraft]

Attachment: firefox WAYLAND_DEBUG=1 output

OK I ran with WAYLAND_DEBUG=1 but I don't really know what to look for. I redirected all the output to a file and attached it.

I am also not using HDR. IIRC, kwin actually emulates HDR if the "Enable EDR" option is checked, but I actually unchecked it trying to fix the bug (it had no effect). I also changed the "Limit color resolution to" option from "Automatic (10 bits per color)" to "8 bits per color" (which also had no effect). On top of this, my display is incapable of HDR which is confirmed by kscreen-doctor -o:

Output: 1 eDP-1 8e342f24-710d-4392-9ce0-0461bdf79e8b
        enabled
        connected
        priority 1
        Panel
        replication source:0
        Modes:  1:1920x1080@120*!  10:640x480@120  11:1280x1024@60  12:1024x768@60  13:1280x800@60  14:1600x900@60  15:1600x900@120  16:1368x768@60  17:1368x768@120  18:1280x720@60  2:1920x1080@60  3:1680x1050@120  4:1280x1024@120  5:1440x900@120  6:1280x800@120  7:1280x720@120  8:1024x768@120  9:800x600@120 
        Geometry: 0,0 1920x1080
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: Automatic
        RgbRange: unknown
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none
        Color profile source: sRGB
        Color power preference: prefer efficiency and performance
        Brightness control: supported, set to 0% and dimming to 100%
        Color resolution: 8 bits per color, range: [8; 16] bits per color
        Allow EDR: never

Comment 10

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

There's the related part here:

[2035030.567] {Default Queue}  -> wp_color_representation_manager_v1#45.get_surface(new id wp_color_representation_surface_v1#132, wl_surface#189)
[2035030.576] {Default Queue}  -> wp_color_representation_surface_v1#132.set_coefficients_and_range(2, 2)

Comment 11

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

(In reply to PQCraft from comment #9)

Created attachment 9521446 [details]
firefox WAYLAND_DEBUG=1 output

OK I ran with WAYLAND_DEBUG=1 but I don't really know what to look for. I redirected all the output to a file and attached it.

I am also not using HDR. IIRC, kwin actually emulates HDR if the "Enable EDR" option is checked, but I actually unchecked it trying to fix the bug (it had no effect). I also changed the "Limit color resolution to" option from "Automatic (10 bits per color)" to "8 bits per color" (which also had no effect). On top of this, my display is incapable of HDR which is confirmed by kscreen-doctor -o:

From the log it looks like you're running Firefox in HDR mode (that's possible even without actual HDR display).

Comment 12

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

According to the log the video has set WP_COLOR_REPRESENTATION_SURFACE_V1_COEFFICIENTS_BT709 / WP_COLOR_REPRESENTATION_SURFACE_V1_RANGE_LIMITED - is that correct?

Please attach output of mpv in verbose mode:

mpv -v video_file

Thanks.

Comment 13

[wiagn233]

There’s an existing fix for kde just merged a few days ago, can you try plasma 6.5 which should have this fix merged? https://invent.kde.org/plasma/kwin/-/merge_requests/8234

Comment 14

[PQCraft]

Attachment: output of mpv -v test.mp4

OK here's the output of doing mpv -v test.mp4 and having the video play for a split second.

I will now update KDE to 6.5.0 from the testing repos, and Firefox back to 144.0.

Comment 15

[PQCraft]

Updating KDE to 6.5.0 fixed it, thanks

Should I close as 'INVALID'?

Comment 16

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

Yeah, Thanks.