1930001 - Twitch video freeze Firefox 132 Windows

Status: NEW

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

Description

[Karl Tomlinson (:karlt back Feb 10)]

Reported in bug 1922848 comment 9:

I believe I'm running into this issue too. Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0, using an Nvidia RTX 4070 Super and 4K@120Hz screen.

In Firefox 131, Twitch streams would eventually start stuttering (video only, audio was always fine), with the Twitch player's Video Stats showing Skipped Frames rapidly increasing every second (by at least 50% of the video's framerate) until pausing and resuming the player or refreshing the page.

In 132 this escalated to the video freezing entirely after a momentary stutter (again, audio is fine), with the Skipped Frames increasing by the video's framerate every second. I can pretty reliably reproduce this in under a minute on new profile by doing the following:

1. Install FrankerFaceZ addon from AMO (not actually required, but makes reproduction a lot faster and more reliable)
2. Open any Twitch stream (though I think higher bitrates/framerates might make reproduction easier?)
3. In the bottom right of the player next to the volume slider, click the Audio Compressor button to enable it (you may need to click it twice to get it to actually enable it)
   • This button is added by the FFZ addon and uses a Web Audio API DynamicsCompressorNode. No idea why this would impact video rendering or make this easier to reproduce, but the addon's source is on Github if that's helpful.
4. Mash the Windows and/or Alt keys, switch back and forth between tabs, switch between apps, etc, until the video stutters and freezes

Importantly, step 4 also reliably triggers brief stuttering on other video players (including YouTube, with YouTube's Stats For Nerds reporting dropped frames), but they almost always recover and resume smooth playback. Only once did I manage to get a Video.js demo to break with the above method during the relatively short time I attempted to reproduce this outside of Twitch, and FFZ doesn't touch any of those sites.

Here is the logging profile I captured using the steps in bug 1922848 comment #2, the tab was associated with process 2396 https://share.firefox.dev/4eptAYS

Comment 1

[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 2

[SpencerHakim]

Not sure what changed in 133 that would cause this (maybe something related to the WebCodecs API work mentioned in the release notes?) but the behavior has now reverted back to what I described as occurring in 131, where the majority but less than 100% of frames seem to get dropped. Reproduction technique remains the same, and I can take another profile if necessary.

Comment 3

[Karl Tomlinson (:karlt back Feb 10)]

In the profile in comment 0, There is a 492 ms "RequestDecode:V:720<h<=1080:hw,h264" marker at around 12 seconds, and from there VideoSinkDroppedFrame markers indicate that decoded video is consistently 200-300ms too late.

Changes for bug 1316571 would mean that some of these late frames are now rendered, which would explain the change in 133.
I don't know what caused the change in 132, but sounds like things were already pretty bad before then.

Does setting "media.hardware-video-decoding.enabled" to false in about:config improve the behavior?

Comment 4

[SpencerHakim]

(In reply to Karl Tomlinson (:karlt) from comment #3)

Does setting "media.hardware-video-decoding.enabled" to false in about:config improve the behavior?

It does, can't get it to drop frames at all using my repro method

Comment 5

[SpencerHakim]

I realized the behavior in 133 is not quite the same as the behavior in 131. In 131, the stuttering would manifest as half a second or less of smooth playback and then a frozen image for maybe 1-1.5 seconds before another short period of smooth playback (jumping ahead, not resuming from whatever frame it was stuck on; a/v sync appeared to be maintained). In 133, the rendered frames are much more evenly distributed, making the video appear as though it was simply at a low framerate (again, a/v sync appears to be maintained).