1932529 - VP09 1080p60fps Videos - Play smoothly but random moments of freeze + dropped frames throughout

Status: UNCONFIRMED

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

Description

[Chobits1717]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

Just watch any 60fps VP09 video, it'll play smoothly but at random points, usually every couple of minutes, it'll freeze for a moment a d drop anywhere from 10-150 frames. Haven't been able to find any other patterns, but its odd that it would just drop like that.

13th Gen Intel i5
Iris XE G7 Graphics

Profile of the problem, dropped 10 or so frames, it happens towards the end of the timeline: https://share.firefox.dev/4eEs9pJ

Actual results:

Frames dropped at random

Expected results:

Even decent iGPUs should be able to play Youtube videos at 1080p60fps with no drops or issues like that.

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Mayank Bansal]

1. Type "about:support" in Firefox and copy-paste its contents here
2. Capture a log when the issue occurs:

• In Firefox, ideally freshly started with no other tabs, go to about:logging in a new tab
• Select the Media preset
• Enable "stack traces for log messages"
• Click on "Set Log Modules"
• Click Start Logging
• Reproduce the bug
• Back on about:logging, click Stop Logging
• In the new tab that appears with the Firefox Profiler web application, in the top right click the button to upload the profile
• Make sure hidden threads are included and upload, then share the link here or send privately to a Mozilla developer
• https://paul.cx/public/about-logging-presentation.webm

3. If this used to work in an earlier version of Firefox, please do a bisection to find the exact change that caused this (https://mozilla.github.io/mozregression/)

Comment 3

[Chobits1717]

Attachment: About:Support

Comment 4

[Chobits1717]

about:support is attached, here's the profile!
https://share.firefox.dev/412WDi9

For whatever reason I managed to make it happen consistently at a specific point in a specific video, around 17 seconds into this one (when Alolan Ninetales is using the move Freeze-Dry): https://www.youtube.com/watch?v=6ZOaX_3YQgM

In fact, here's a video! https://imgur.com/FiEdhzQ

Comment 5

[Chobits1717]

Here's another profile, this time of the bug happening during a livestream:
https://share.firefox.dev/4fBC6oZ

Also noticed it happening on avc1 videos as well, not just VP09 :(

Comment 6

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 7

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 8

[Jim Mathies [:jimm]]

Just watch any 60fps VP09 video, it'll play smoothly but at random points, usually every couple of minutes, it'll freeze for a moment a d drop anywhere from 10-150 frames. Haven't been able to find any other patterns, but its odd that it would just drop like that.

(In reply to Chobits1717 from comment #5)

Here's another profile, this time of the bug happening during a livestream:
https://share.firefox.dev/4fBC6oZ

Also noticed it happening on avc1 videos as well, not just VP09 :(

I can totally see the moment this happens in this profile. But the browser is not under stress, it looks more like the system is doing something that's robbing cpu cycles.

Comment 9

[Chobits1717]

(In reply to Jim Mathies [:jimm] from comment #8)

Just watch any 60fps VP09 video, it'll play smoothly but at random points, usually every couple of minutes, it'll freeze for a moment a d drop anywhere from 10-150 frames. Haven't been able to find any other patterns, but its odd that it would just drop like that.

(In reply to Chobits1717 from comment #5)

Here's another profile, this time of the bug happening during a livestream:
https://share.firefox.dev/4fBC6oZ

Also noticed it happening on avc1 videos as well, not just VP09 :(

I can totally see the moment this happens in this profile. But the browser is not under stress, it looks more like the system is doing something that's robbing cpu cycles.

Which spot in the profile is it?

Comment 10

[John]

I noticed on 2 computers (desktop and laptop), with AMD RX 560 and AMD R5 + Intel UHD 620 exactly 1 frame dropped every 100 frames on both computers, which are running Debian 14 (Forky) + Plasma 6.7 on Wayland.
On various 4K @ 60 videos on Youtube that I try from time to time and look at the stats for nerds thing.
The desktop even has a Ryzen 7 Zen 2 CPU, 32 GiB RAM and a fast SSD, so the problem must be in software somewhere.
Every time the video passes the 100 frames, the dropped counter increases, like:
1 dropped of 105
2 dropped of 211
3 dropped of 323
And so on.

Comment 11

[media-triaging-bot]

Thank you for the three profiles. They show the freeze clearly.

Analysis

All three profiles show the same pattern. The GPU process creates a new hardware video decoder, and this blocks the decode of the video that plays. The playing video runs out of decoded frames and drops them, while audio continues. The profiles show steady sampling and a busy Firefox thread, so the system does not take the CPU (this answers comment 8).

• Profile in comment 0: another YouTube tab loads its next video at about 100.1 s. Its decoder creation keeps the GPU MediaSupervisor thread busy for 215 ms. The 1080p60 decode requests wait, and 10 frames drop. Six more create and shutdown cycles of 60 to 90 ms follow, with 10 more dropped frames.
• Profile in comment 4: at about 17 s of the video, YouTube switches from 720p60 to 1080p60. MediaChangeMonitor sees the VP9 resolution change and creates a new decoder. The creation takes about 100 ms, no frame comes out for about 140 ms, and 7 frames drop.
• Profile in comment 5: a hidden YouTube tab creates and destroys VP9 decoders many times. Each creation takes 70 to 230 ms on the same GPU thread. The livestream drops frames in two bursts, at about 82 s and 87.5 s.

Cause

The GPU process uses one task queue ("RemVidParent") for all remote video decoders of all tabs, in RemoteMediaManagerParent.cpp. RecvDecode runs on this queue, in RemoteDecoderParent.cpp. RemoteVideoDecoderParent also calls CreateDecoder on it, in RemoteVideoDecoder.cpp. WMFDecoderModule::AsyncCreateDecoder does the work synchronously, in WMFDecoderModule.cpp. It calls WMFVideoMFTManager::Init, which blocks in InitInternal, in WMFVideoMFTManager.cpp.

The profiles show the time in MFTEnumEx, D3D11DXVA2Manager::ConfigureForSize, SetDecoderMediaTypes and D3D11CreateDevice. This GPU (Intel Gen12) is blocklisted for decoder device reuse, so each creation also makes a new D3D11 device. The cause does not depend on the decoder, so it also explains the H.264 (avc1) freezes in comment 5.

Fix direction

Move the WMF video decoder creation off the shared "RemVidParent" queue, for example to a separate task queue for each decoder. Then a new decoder does not block the decode of other videos. For the resolution change in the comment 4 profile, decoder reuse across a resolution change can also help. Bug 1685099 and bug 1694485 track the decoder recreation for YouTube live streams.

This bug blocks bug 1416090 (dropped video frames) and bug 1445470 (video playback performance).

Comment 10

Comment 10 describes a different pattern on Linux: exactly one dropped frame every 100 frames. Linux does not use this WMF path, so this bug does not cover that problem.

Workaround

1. Close other YouTube tabs while a video plays.
2. Select a fixed quality in the YouTube player settings, not "Auto".

---

If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.