1540226 - Brief video and audio interruptions on YouTube when tab is focused after it was in the background

Status: NEW

(Core :: Graphics, defect, P2)

Description

[Dennis Schubert [:denschub]]

On YouTube, when the tab was in the background for a bit (a couple of seconds, usually), or when the browser was minimized/unfocused, coming back to the tab sometimes results in a brief interruption of audio and video.

I can't reproduce 100% of the time, and I don't know what exactly triggers this. It may be related to YouTube reducing the video quality when the tab is in the background, and attempting to scale back up when back in the foreground.

This happens on 2019-03-27's Nightly, macOS 10.14.4, with a YouTube Premium account.

Comment 1

[Michael Kohler [:mkohler]]

(In reply to Dennis Schubert [:denschub] from comment #0)

This happens on 2019-03-27's Nightly, macOS 10.14.4, with a YouTube Premium account.

Same Nightly for me, same OS for me, without Premium account.

Comment 2

[Alex Thayer [:alexical] (she/her)]

Moving this to Tabbed Browser for now as it seems correlated with tab switching. However, Dennis (or anyone experiencing this), could you try to keep the Gecko Profiler running and post a profile if you see this happen again?

Comment 3

[Dennis Schubert [:denschub]]

This is me switching the tab from about:addons to YouTube (around the 1.4s mark, but there is a marker), PID 27994 was the content process rendering YouTube. That tab change resulted in the interruption reported here. https://perfht.ml/2I9zX7m

Comment 4

[Alex Thayer [:alexical] (she/her)]

https://perfht.ml/2FOhytV

We're spending a huge chunk of time in TextureClient::CreateForRawBufferAccess. Markus, any thoughts? Punting this to Graphics.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

I don't think this is a graphics problem. It seems like there's something going very wrong with the system at the time of the profile. Dennis, it looks like there's something slowing down everything when this happens. I wonder if you're hitting swap or something like that. If you can figure out better steps to reproduce that might help us understand what's happening here.

Also, do you think this is a regression?

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

Gecko's media stack detects when a video is in the background, and shuts down the video decoder in order to conserve resources for use by foreground tabs. When you move the tab back to the foreground, we restart the video decoding pipeline and seek the video to the position of the audio stream. I think you may be seeing fallout from this.

You probably want to include the "Media" threads in your profile, and there may be some interesting work in the Remote Data Decoder process (I didn't see anything in your profile; maybe because the "Media" threads weren't captured).

I'd be surprised that this causes an audio glitch. It's entirely reasonable that you might get black video frames for a few frames while the video decoder starts up and catches up to the audio stream. We try to alleviate this by restarting the decoder when the user mouses-over the tab in the tab bar. If you switch to the tab using a keyboard shortcut, we aren't able to predict that the tab is about to be foregrounded, so you'll be more likely to catch the decoding pipeline cold.

Comment 7

[Dennis Schubert [:denschub]]

Okay, I gave it a couple more tries over the last few days, and couldn't reproduce at all. So maybe this was a temporary issue on YouTube's side, or a Nightly thing, but it's been just fine over the last week.

Michael, since you could reproduce as well, do you still experience this issue?

Comment 8

[Michael Kohler [:mkohler]]

I can still reproduce this on my work laptop as well as my private one. On my work laptop (more power), currently it feels better than a when this bug was reported, but it still happens when I leave the YouTube tab in the background for 5 minutes or more. In my personal laptop I left the tab in the background for about 2 minutes and went back and instantly had this issue. Both laptops are running the latest version of macOS and latest Nightly.

Here's the profile: https://profiler.firefox.com/public/4ceed29f699f49ba7de335ce2c6d799398a1d26e/calltree/?profileName=&published&v=3

If you would like me to enable more profile things or gather any other info, happy to help out.

Comment 9

[Michael Kohler [:mkohler]]

.. and to make it clear: when I switch to the YouTube tab, I see the video being white and then starting again. At the same time the audio cuts out and continues the same time when the video does.

Comment 10

[Dennis Schubert [:denschub]]

Okay, nevermind, I can still reproduce occasionally (probably just watched less YouTube last weekend...)

cpearce, here is a profile of me switching tabs several times (here the zoom-in of only one tab switch back to YouTube), each time experiencing a short interruption. This profile includes Media threads, like Michael's profile above. Maybe this is helpful.

It's entirely reasonable that you might get black video frames for a few frames while the video decoder starts up and catches up to the audio stream.

During the tab switching, you can see several milliseconds of black frames, yes, you can even see those on the profiler screenshots. However, while there are black frames, there also is no audio, and the audio comes back when the video frames are rendered again, and it's a very harsh mid-sinewave transition (i.e. it's often causing the speakers to crack). I have no easy way to capture that, though, as for some reason, I can never reproduce when a screen capture software is running. In this profile, I am switching tabs by clicking on the tab, not with keyboard shortcuts.

It seems like there's something going very wrong with the system at the time of the profile. Dennis, it looks like there's something slowing down everything when this happens. I wonder if you're hitting swap or something like that.

Unlikely. Although there are several applications running that use a browser engine eating a lot of RAM (Slack, VSCode, you name it), at the time of recording that profile, I had 18 GiB of free memory. I didn't run anything CPU extensive, and the CPU fan wasn't even spinning (at least not in the typical MacBook jet fan fashion). Also, Firefox itself only had 4 pinned tabs, YouTube, and this bug opened, so Firefox itself shouldn't be overwhelmed. FWIW, this is on the 2018 MacBook Pro with the 2.9 GHz i9 and 32 GiB of RAM, so resources really shouldn't be an issue. The laptop was plugged in and at 95% battery, so CPU throttling due to low battery states can also be ruled out.

It's probably worth nothing that others, like :mccr8, have seen the same issue as indicated on Slack (Mozilla-internal link, sorry), so I fear this might be something more widespread. Also, just for the record, this seems to be unrelated to YouTubes Polymer v2/v3 rollout, as this also happens when window.Polymer.version is 1.11.3.

Comment 11

[Dennis Schubert [:denschub]]

Also, do you think this is a regression?

I don't know. I don't remember seeing this issue before the end of March, but given how unreliably this reproduces, it's hard to run mozregression on this...

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

I note that:

• The WebExtensions process gets a spike in memory and CPU at the start of network requests from the content process.
• When the black frame glitch happens, we don't see much action on the Media threads on WebContent7 process until the network traffic which was started at around 2s in the profile finishes. We then see a surge in processing on the Media threads as decoding happens and then shortly after we get frames displayed. This suggests to me the problem is that the decode pipeline didn't have the data required to produce frames.

Dennis: Can you try disabling all your extensions and trying to repro again?

What are the spec's of the machines on which this repro's?

I cannot repro on my 2015 13" MBP (I'm running uBlock Origin there too).

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

I am seeing something very similar on Windows with two different machines one desktop and other is a laptop. Just about any media playback can be affected. I just had a local news channel's media player, Google Music and YouTube. Both are using recent DevEdition builds 67.0b17. Laptop is a Dell XPS 13 9370 i7-8550U 16 GB of ram. Desktop is i7-Haswell with 16 GB ram.

Comment 15

[Chris Pearce [:cpearce (Not reading bugmail)]]

I was able to repro this on my 2015 13" MBP on YouTube over the weekend on this page: https://www.youtube.com/watch?v=g6iDZspbRMg . I think I also sometimes saw this when YouTube up-shifted to a higher bandwidth stream.

Comment 16

[Dennis Schubert [:denschub]]

Sorry for my slow needinfos here, but reproducing this always is a bit tricky because it involves me watching YouTube videos for extended periods of time... :)

Dennis: Can you try disabling all your extensions and trying to repro again?

Still reproducible.

What are the spec's of the machines on which this repro's?

This is a 2018 MacBook Pro, with the 2.9GHz i9 and 32 GiB of RAM.

From looking closer at the profile zoom-in linked in comment 10, I don't think this actually related to the encoder waking up after switching tabs. In the screenshots, you can clearly see several milliseconds of visible video frames before it goes to black, and a significant spike of JS activity in the content just before that. This, and what Chris wrote in comment 15, looks more like this is related to YouTube switching to a low-res video when the tab is in the background to conserve bandwidth, and attempting to go back to high-res footage again, failing to do so seamlessly.

This might be something we should just contact Google folks about. What would be interesting to know before getting in touch with them is if someone with the Polymer 3 interface can reproduce this? For me, window.Polymer.version still shows 1.11.3, despite YouTube apparently rolling out the new code...