1883946 - YouTube HDR video lags entire system on 2019 16" MacBook Pro

Status: RESOLVED FIXED

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

Description

[Sam Johnson]

I have found a particular YouTube video that seems to make my entire system nearly unusable--the video flickers excessively, and everything including mouse input lags system-wide while it is playing.

This reproduces on a 2019 16" MacBook Pro, which has an HDR display, and also has non-HDR displays connected (the issue happens on the internal display as well, however). I was not able to reproduce on an M1 Max Mac Studio without any HDR displays.

Steps to reproduce:

1. Visit https://www.youtube.com/watch?v=BqJXxdDSd_E
2. Set the video to 1080p HDR and play
3. Note excessive flickering and the system becomes nearly unusable.

According to mozregression, this is not a recent regression (builds going back to 2022 still had the issue, though the flickering is worse in older builds).

The video plays fine on the same system with Chrome and Safari, both in HDR and non-HDR (though Chrome never offers HDR for this video).

Comment 1

[Jim Mathies [:jimm]]

Could you help us out by trying to capture a Firefox performance profile when this happens? Visit https://profiler.firefox.com/ for more information and to enable the profiling toolbar button. When capturing, please select the Media profile in the button drop down, upload the resulting profile and post the url here.

Comment 2

[Sam Johnson]

Hi Jim! Sure, here you go: https://share.firefox.dev/49L3T3I

Comment 3

[connor.mccaffrey]

despite common believe a 2019 16'' macbook pro does not support HDR, it does support wide gamut P3 and have decent brightness but its an 8 bit display - "16‑inch (diagonal) LED‑backlit display with IPS technology; 3072‑by‑1920 native resolution at 226 pixels per inch with support for millions of colors"

I am able to run 1440P HDR on a Hackintosh T480 Thinkpad with a 8250u and UHD 620 however it really heats my system up. im also able to reproduce this issue on a 2017 MBP 13''

In reality none of these devices support HDR, none of my displays support HDR, so i dont get why firefox is serving rec 2020

check https://www.wide-gamut.com/test and check P3

if you go to about:config then gfx.colour_management.mode = 0 it fixes the issue however it then shows my monitor does not support ICC, i guess this is because firefox is now just allowing MacOS to do the colour management.

despite the fix, chromium and firefox still look better on the image test for HDR on my device, however on the 2017 13'' MBP with P3 support the HDR looked good but P3 image still way off. i can post screenshots or explain better if needed.

Comment 4

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

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Brad Werth [:bradwerth]]

HDR behavior with multiple monitors was hopefully improved with the landing of Bug 1764201. Is this problem still happening for you?

Comment 6

[Sam Johnson]

(In reply to Brad Werth [:bradwerth] from comment #5)

HDR behavior with multiple monitors was hopefully improved with the landing of Bug 1764201. Is this problem still happening for you?

On external displays, there is no longer any problem (the video does not play as HDR). However, if I play the video on the internal display, the problem still reproduces--the video flickers and the system becomes mostly unresponsive.

Comment 7

[Brad Werth [:bradwerth]]

Thanks, I'll try to reproduce.

One way the video might flicker is if we are rebuilding the video layer while it is playing. There is an "about:config" pref that will generate some logging information in the Terminal as we rebuild video layers. 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 8

[Sam Johnson]

Attachment: videolog.txt

(In reply to Brad Werth [:bradwerth] from comment #7)

Thanks, I'll try to reproduce.

One way the video might flicker is if we are rebuilding the video layer while it is playing. There is an "about:config" pref that will generate some logging information in the Terminal as we rebuild video layers. 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?

No problem, here you go! I included the full log in case the extra details logged are useful.

Comment 9

[Brad Werth [:bradwerth]]

Perfect, thank you. This is showing that we're decoding video frames faster than the video layer is able to display them, and our response to that is to throw away the video layer and create a new one. That's a bad strategy that that introduces flickering. Probably a better strategy is to just ignore the decoded frame, reducing the frame rate but otherwise keeping the video coherent. I'll create a patch that does that.

Comment 10

[Brad Werth [:bradwerth]]

Attachment: Bug 1883946: Allow AVSampleBufferDisplayLayer to enqueue a sample even when it doesn't want one.

It is possible that we decode samples faster than the video layer can
display them. In such a case, we obviously won't display all the frames,
but we have to make a good decision of what to do with the extra
samples. One option is to drop them. This is safest, but runs the risk
of prevent an important sample from being displayed (for example, a
final frame markedly different from the preceding frames). It would be
better if we could enqueue all frames and let the video layer apply them
as it is able, eventually displaying the last frame enqueued.
Conveniently, the Apple documentation for AVQueuvedSampleBufferRendering
says "It is safe to call enqueueSampleBuffer: when readyForMoreMediaData
is NO, but don't enqueue sample buffers without bound." Probably the
steady frame rates of video content we send to video layers would not
qualify as being unbounded, since they are being processed at some
cadence and maybe maybe have their timestamps assessed as a group and
the last/most-recent "display immediately" frame is used, but we don't
know for sure.

If this leads to performance problems we can instead drop samples or try
to manipulate the internal algorithm a different way by supplying "real"
timestamps for each sample, as currently protected behind the pref
gfx.core-animation.specialize-video.spoof-timing.

Comment 11

[Brad Werth [:bradwerth]]

Since I can't reproduce this, I'll produce a build from https://treeherder.mozilla.org/jobs?repo=try&revision=875fc209c3c4d403260fbe4228cc75569e472564 and ask the reporter to try it out.

Comment 12

[Sam Johnson]

(In reply to Brad Werth [:bradwerth] from comment #11)

Since I can't reproduce this, I'll produce a build from https://treeherder.mozilla.org/jobs?repo=try&revision=875fc209c3c4d403260fbe4228cc75569e472564 and ask the reporter to try it out.

Nice, the try build works great! Thanks!

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/30a3bd2d9ce0
Allow AVSampleBufferDisplayLayer to enqueue a sample even when it doesn't want one. r=mac-reviewers,mstange

Comment 14

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/30a3bd2d9ce0