1899938 - Opening an HDR video in fullscreen causes the video to flicker and lag; enter browser eventually lags

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Jonathan Almeida [:jonalmeida]]

Attachment: video of the bug - 1.mov

Steps to reproduce

1. Open an HDR youtube link (example: https://www.youtube.com/watch?v=LXb3EKWsInQ)
2. While the video is playing, open the video in fullscreen mode.
3. Observe.

Expected result

• The video should not flicker.

Actual result

• Video flickers and stutters (see first video).
• General performance of Firefox seems to be affected (e.g. scrolling through list of tabs in the UI chrome) even after the video has stopped playing.

Additional information

• Once the STR have been used, it's possible to reproduce the bug from just refreshing the page and playing the video without fullscreen. See secondary video.
• Profiles:
  • Graphics: https://share.firefox.dev/4e03n4d
• Mac OS 14.4 (23E214), Macbook Pro M1 Max

Comment 1

[Jonathan Almeida [:jonalmeida]]

Attachment: video of the bug - 2.mov

(In reply to Jonathan Almeida [:jonalmeida] from comment #0)

• Once the STR have been used, it's possible to reproduce the bug from just refreshing the page and playing the video without fullscreen. See secondary video.

This is the video referenced.

Comment 2

[Brad Werth [:bradwerth]]

I'll figure this out. It's possible that this is fixed by Bug 1883946, which landed shortly after this report. This doesn't reproduce for me on similar hardware, but what is happening here is that the HDR video is alternating between being "promoted" (treated as a video, passed to macOS to process all the colors) and not (blended in with the other SDR content, flattening the colors). To diagnose this, would you please:

1. Launch Firefox Nightly from Terminal.
2. Navigate to "about:config" and set the pref gfx.core-animation.specialize-video.log to true.
3. Reproduce the problem.
4. Switch the pref back to false, close Firefox.
5. Copy the lines of text in Terminal that start with VIDEO_LOG: and paste them as an attachment to this Bug?

Comment 3

[Jonathan Almeida [:jonalmeida]]

Attachment: VIDEO_LOG from reproduction.log

It was a bit harder today to reproduce the bug and once I was able to, I'm not sure my terminal scrollback buffer was large enough to get the logs. I can try this again and pipe it to a file if needed.

Comment 4

[Brad Werth [:bradwerth]]

Thanks that's informative. This is showing that this is not Bug 1883946; but that the surface is sometimes failing to promote for unknown reasons. If I can reproduce the issue, I'll be able to figure out why. If not, then Bug 1898621 will improve our logging here and we'll be able to get your setup to generate a useful report.

Comment 5

[Jonathan Almeida [:jonalmeida]]

Attachment: about:support output.txt

In case there is something that can help based on comment 4, I've added my about:support output here as well.

Comment 6

[Brad Werth [:bradwerth]]

Now that Bug 1898621 has landed, we have another form of logging in Nightly that will reveal why the video is alternating between promoted and not, which is what is causing the flickering. Would you please:

1. Update your Nightly.
2. Navigate to "about:config" and set the pref gfx.webrender.debug.surface-promotion-logging to true.
3. Restart Nightly from the Terminal.
4. Reproduce the problem, quit Nightly.
5. Copy the logging text from Terminal and upload it to this Bug as an attachment.

The logging is very verbose/spammy and will generate a lot of output. The relevant lines start with "Surface promotion of prim".

Comment 7

[Jonathan Almeida [:jonalmeida]]

Just as an update, I've been having a difficult time reproducing the bug again with my current nightly build 129.0a1 (2024-06-18), but I'll keep trying. If I'm unable to, I'll close it as works for me.

Comment 8

[Jonathan Almeida [:jonalmeida]]

Closing as per comment 7. Thanks for the help with the bug investigation!