2016063 - Video freeze when opening or refreshing X(Twitter)

Status: REOPENED

(Core :: Graphics: WebGPU, defect)

Description

[Kitsu]

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

Steps to reproduce:

1. Open any video site(e.g. YouTube) and run any video
2. Open X(Twitter) in another tab
3. Keep these two tabs side by side OR keep the video running in pip mode
4. Now refresh X and Observe the video

Actual results:

The video freezes for a second every time you refresh X.

Expected results:

Video should run smoothly irrespective of other tabs.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Picture-in-Picture' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

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

[Jim Mathies [:jimm]]

I will prioritize this in the other bug.

Bug 2016063 — "Video freeze when opening or refreshing X(Twitter)"

Status: UNCONFIRMED | Component: Core → Audio/Video: Playback | Firefox: 147 | Platform: Windows 10 x64

Issue: Video in one tab (e.g. YouTube, PiP) freezes for ~1 second every time X/Twitter is refreshed in another tab.

STR: Clear and specific — open YouTube video, open X in second tab (side-by-side or PiP), refresh X, observe freeze.

Key Related Bugs

Bug	Summary	Status	Relevance
1955839	Disruption in music playback when switching tab to X/Twitter	UNCONFIRMED, S3	Very likely duplicate — same root symptom; log shows audio stream stopped/drained when X/Twitter loads
1956979	9s jank in PContent::Msg_CreateAudioIPCConnection (win10)	ASSIGNED, S3/P3	Audio IPC connection jank on Windows; fix tracked in bug 1899317
1954546	[meta] Twitch audio/video playback freezes/stutters	NEW, meta	Broader meta bug for streaming video freeze/stutter

Key Finding

Bug 1955839 is a near-duplicate (same X/Twitter + media disruption pattern). Its reporter noted Firefox Nightly 137.0a1 (Feb 24, 2025) did not reproduce the issue, suggesting a fix landed in 137 that may have regressed by Firefox 147. The 1955839 log shows audio streams being stopped and drained at the moment of disruption, pointing to X/Twitter's heavy JS/resource loading triggering audio session reinitialization on Windows.

Comment 4

[Matthew Gregan [:kinetik]]

Reopening. Bug 1955839 is understood, but it's Linux specific and relates to audio glitches. This report is for Windows and relates to video glitches, so not a duplicate.

@Kitsu provided a media logging profiler run in https://bugzilla.mozilla.org/show_bug.cgi?id=1955839#c8 - that's https://share.firefox.dev/4c0T8h4

Comment 5

[Matthew Gregan [:kinetik]]

@Kitsu, thanks again for the profile! In that recording, did you capture a single case of video freezing or more than one?

I can see a clear case of video decode starvation around 11.5s into the recording and recovery at around 12.1s. There's an explanation for why that is happening, but I think it only makes sense as a one-off glitch triggered by first initialization. You mentioned the video freezes every time you refresh X, so I might be missing something.

If the profile recording did only capture a single case of video freezing, it'd be useful to have another recording where you capture it happening several times. Also, can you attach a copy of about:support to this bug, please?

Comment 6

[Matthew Gregan [:kinetik]]

I think this is actually a graphics issue, but I'll check a profile recording with multiple video freezes to confirm I've understood what's happening.

Here's what I can see from the provided profile:

• 11.392: x.com process creates WebGL context
• 11.507: GPU process CanvasRenderer thread starts loading NVIDIA DLLs
• 11.559: GPU process Compositor thread starts a composite that takes 579ms to complete
• 11.602: GPU process MediaPDecoder #2 thread submits a video decode request (AV1 1920x1080, NV12, via WMFVideoMFTManager)
  • This shows up as a RequestData:V:720<h<=1080 in the youtube.com content process MDSM thread at the same timestamp, taking 577ms to complete
• 12.179: Slow composite completes, video decode request completes (actually 12+ decodes were queued, they all complete)
• 12.179: youtube.com process MDSM thread logs "Video falling behind" several times

There's also slow looking CanvasRenderer activity at 4.9s and 16.9s, but these don't cause the video decode to starve for some reason.

Comment 7

[Matthew Gregan [:kinetik]]

There's 3 x.com reloads in the profile: starting at 3.7s, 10.3s, and 15.9s. Only the one at starting 10.3s causes the video decode to starve at 11.6s, but all 3 reloads cause compositor stalls (duration: 1.5s, 0.9s, and 0.7s) which will look like frozen video to the user, so the video decode starvation is a secondary issue.

This seems to be the same underlying issue as bug 1674262. Moving bug to appropriate component.

Comment 8

[Kitsu]

Yeah I refreshed X 3 times just to make sure to have enough evidence of video freezing. And yes it freezes everytime I refresh.

Comment 9

[Kitsu]

Attachment: About support.txt

Comment 10

[Kitsu]

@kinetik I digged up a bit more and when I turn off hardware acceleration, the bug goes away, there is no video freezing. Hope this helps.

Comment 11

[Kitsu]

More details : The bug happens only when Firefox uses integrated intel GPU for hardware acceleration not when I set Firefox to use dedicated NVIDIA GPU.

Comment 12

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

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

For more information, please visit BugBot documentation.

Comment 13

[Teodor Tanasoaia [:teoxoy]]

Looking at the profile: X.com is sending a single requestAdapter message to the WebGPU parent, wgpu calls D3D12CreateDevice for both GPUs and most of the time is spent in the D3D12 runtime/GPU driver for one of the calls. There are quite a few kernel calls that go to the kernel mode driver, including: ZwSignalAndWaitForSingleObject which the sampling profiler can't tell how long it took to complete. I suspect all this work the KMD is doing is blocking the decoder.

More details : The bug happens only when Firefox uses integrated intel GPU for hardware acceleration not when I set Firefox to use dedicated NVIDIA GPU.

That's interesting all the work that I see in the profiler seems to be due to the D3D12 runtime creating some sort of special device (calls D3D12CoreCreateLayeredDevice, call to CCreateDeviceCache::LoadUMD, creates extra compute and graphics pipelines, fn call uses _D3D12_DEVICE_SINGLE_ADAPTER_HYBRID_MDOE).

I would be interested in knowing more about how/where you setup Firefox to use the Nvidia GPU. Also, is the Nvidia GPU your main GPU? Do you know which GPU is connected to your display? Is the laptop battery powered or plugged in when this issue appears?

Comment 14

[Kitsu]

In Windows's display settings(Settings->System->Display->Graphics) I could set which gpu Firefox can use. By default it is set to "Let windows decide" which basically uses integrated gpu(Could tell by activity in task manager). If I set it to NVIDIA gpu then the bug does not happen(Or I should say the freezing still happens but for a very short duration that it is hard to notice).

No NVIDIA is not my main GPU, I think laptop defaults to integrated GPU for most tasks, it is only gaming when the dedicated GPU kicks in.
The bug does happen irrespective of whether I am plugged in or not.