1923697 - After update from 130 to 131 after switching windows video picture hangs but audio still playing with NVIDIA GPU

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[abubaca4]

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

Steps to reproduce:

Open video/stream in YouTube or other site. Then switch to other app(in my case it's fullscreen game). Than return back to Firefox.

Actual results:

Have static picture from video, audio continue playing. Start stop button not help. Sometime rewind video help, sometime no. Page refresh always help, but after window switch problem can appear again.
I can't reproduce this bug in firefox with enabled profiler with YouTube but recorded in live.vkplay.ru.
https://share.firefox.dev/3zSagFu
https://share.firefox.dev/3YiqNfw
Also see message about this problem in https://www.reddit.com/r/firefox/comments/1fyalt6/youtube_videos_freeze_but_keep_playing_audio/
I see this problem in both my pc, 5600x+1050ti and 1135g7 notebook. Last win 10 version.

Expected results:

Video should play normal like before.

Comment 1

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

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

Comment 2

[abubaca4]

Add record for YouTube
https://share.firefox.dev/3zUQYiS

Comment 3

[Mayank Bansal]

1. Can you test this on the latest Firefox Nightly and see if this is fixed?
2. Please type "about:support" in the browser and copy-paste its contents on this bug
3. Please capture a media log. Steps are:

• In Firefox, ideally freshly started with no other tabs, go to about:logging in a new tab
• Select the Media preset and 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
  -These steps are demonstrated in this video: https://paul.cx/public/about-logging-presentation.webm

Comment 4

[abubaca4]

Attachment: about support

(In reply to Mayank Bansal from comment #3)
> 1. Can you test this on the latest Firefox Nightly and see if this is fixed?
> 2. Please type "about:support" in the browser and copy-paste its contents on this bug
> 3. Please capture a media log.  Steps are: 

1. I do this later.
2.

Comment 5

[abubaca4]

(In reply to Mayank Bansal from comment #3)

1. Can you test this on the latest Firefox Nightly and see if this is fixed?
2. Please type "about:support" in the browser and copy-paste its contents on this bug
3. Please capture a media log. Steps are:

1. I do this later.
2. added to attachments
3. all share.firefox.dev links made like this. one more link with YouTube record https://share.firefox.dev/3BAXHPj

Comment 6

[abubaca4]

1. Yes problem also exist in 133.0a1
   https://share.firefox.dev/4gY6HOO

Comment 7

[Erich Gubler [:ErichDonGubler] (he/him)]

Hard to tell if this is a Graphics issue, or an A/V issue. Looping in :padenot, :gw, and :nical so we have both sides of the bridge here. Tentatively triaging as S2, since this seems like an issue that might make somebody drop FF.

I'm otherwise not sure how to triage this, so I'm escalating to gfx-triage.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

This seems more like a media issue to me.

Comment 9

[Paul Adenot (:padenot)]

Reporter, thanks for opening a bug. Did this work correctly before? If this is the case, can you find a regression range using MozRegression ?.

Does this work as expected in an other web browser, such as Chrome or Edge?

From your profile: https://share.firefox.dev/4dKINUe, we see that at some point we stop decoding video, and that's it. Alastor, can you use your new tool to quickly understand what's going on?

Comment 10

[abubaca4]

(In reply to Paul Adenot (:padenot) from comment #9)

Reporter, thanks for opening a bug. Did this work correctly before?

In 130 and earlier video start playing again after opening firefox in 2-3s. For me problem appeared in 131 but someone in reddit says that he had it earlier.

If this is the case, can you find a regression range using MozRegression ?.

I try to do this later, wrote if succeed.

Does this work as expected in an other web browser, such as Chrome or Edge?

Yes, it continue play without delay, or with delay like 0.5s. In my Edge installed extensions like in firefox, I use it when something not work in firefox.

Some thoughts on this issue:

1. I don't think it has anything to do with specific hardware. The problem is both on a computer with 5600x and 1050ti and on a laptop with 1135g7. The only thing they have in common is my Firefox profile with the same set of extensions.
2. It's likely that the problem is caused by a combination of extensions, but I'm not the only one with it and I doubt our extension sets are the same.
3. I have a problem much easier to reproduce on sites that give high bitrate video (12 mbit for qhd). And more difficult on YouTube, which gives 7-8 mbit for qhd. Also possible connection with codecs, the site giving video in 12 mbit sends h264 stream, and youtube usually vp9.
4. Considering that earlier in 130 version the picture was restored longer than in Chromium-based browsers, perhaps there is also a decoding error but some mechanism restores playback. And in 131 version this mechanism is broken. Sometimes on YouTube in 131 playback is restored after ~20 seconds, but on another site it does not happen.

Comment 11

[Alastor Wu [:alwu]]

Hi, abubaca4,

I wonder if your profile in the comment6 was captured from about:logging? because it lacks some important debug logging information, which can only be captured via about:logging (however, we do see some buggy behaviors in our profiler though, eg. bug 1906756)

In addition, there are some points I'd like to confirm with you. Is this freezing issue only happening after you switch a tab/Firefox back from the background? or it happens on the foreground tab as well? And how long would the issue happen when putting Firefox on the background? If you switch it back quick enough, will the issue still happen? Does setting media.suspend-background-video.enabled to false help on this issue or not? Also, would you mind to try to disable the pref media.hardware-video-decoding.enabled and then restart the Firefox to see whether the issue still persists or not?

Does this issue happen on all videos on vkplay.ru? or on only specific videos? if it's latter, could you provide some examples?

From the profile in the comment6, I found that it took too long to decode this video frame. There was a weird long wait for WMF decoder.

Thanks!

Comment 12

[abubaca4]

(In reply to Alastor Wu [:alwu] from comment #11)

I wonder if your profile in the comment6 was captured from about:logging? because it lacks some important debug logging information, which can only be captured via about:logging (however, we do see some buggy behaviors in our profiler though, eg. bug 1906756)

I open https://profiler.firefox.com/ click enable profiler button, select media and start record.
I made one more but from about:logging https://share.firefox.dev/3U8jxQF

In addition, there are some points I'd like to confirm with you. Is this freezing issue only happening after you switch a tab/Firefox back from the background? or it happens on the foreground tab as well?

If I switch between tabs within Firefox the problem does not occur. Only when the browser is fully minimized.

And how long would the issue happen when putting Firefox on the background? If you switch it back quick enough, will the issue still happen?

Look like if I switch back in ~5s problem does not occur. But in ~10s problem occur.

Does setting media.suspend-background-video.enabled to false help on this issue or not?

Not helping.

Also, would you mind to try to disable the pref media.hardware-video-decoding.enabled and then restart the Firefox to see whether the issue still persists or not?

It's help. Work like in 130. Video start in 2-3s after I switch to firefox.

Does this issue happen on all videos on vkplay.ru? or on only specific videos? if it's latter, could you provide some examples?

I not sure about all video but for example in https://live.vkplay.ru/kk_krabiwe/record/8efbd21f-3472-40f7-839f-0b8e6e558b39/records it's occur(1440p).

Comment 13

[Alastor Wu [:alwu]]

Hi, abubaca4,

Sorry for late reply. I'd like to confirm with you, so for your profile in the comment12, you had started playing the video first, then started profiling and immediately put the Firefox to background? Is my assumption correct? I can see the issue happened around on 6.28s, which I suppose it was around the time after you put Firefox to background.

Does this issue happen related with another application you put on the foreground? or you can easily reproduce this issue by putting Firefox on background, and no other application on the foreground? does this issue happen on a private browsing mode or on a fresh Firefox profile?

The current issue is the HW decoding was completely stuck with no reason... I can't think of any possibilities right now. If you said it's a regression from Fx131, would you mind using this tool to find out a culprit?

Thank you so much!

Comment 14

[Alastor Wu [:alwu]]

Hi, sotaro,

I wonder if you have any idea about this issue. From what I observed, the hw decoding was stuck completely when the Firefox is on the background. The user said this issue won't happen when Firefox is on the foreground. Do you have any idea what could possibly cause this kind of issues? Would it be possible we reduce the thread priority or something similar when Firefox is on the background?

Thank you so much!

Comment 15

[Sotaro Ikeda [:sotaro]]

(In reply to Alastor Wu [:alwu] from comment #14)

Hi, sotaro,

I wonder if you have any idea about this issue. From what I observed, the hw decoding was stuck completely when the Firefox is on the background.

The symptom looks similar to Bug 1905022 that happened with zero video frame copy. When Bug 1905022 happened, hardware video decoder waited video frame recycled.

Then when the problem happened, the video frames might be held somewhere on the client side.

And Bug 1920061 might be similar symptom.

Comment 16

[Sotaro Ikeda [:sotaro]]

Since Bug 1768495 fix, compositor stops to composite when window is occluded. The check is done in WebRenderBridgeParent::MaybeGenerateFrame().

This means that video frames held for WebRender will continue to be held by the AsyncImagePipelineManager. The amount is 2-3 video frames. WMFVideoMFTManager::InitInternal() requests enough amount of output buffers

Comment 17

[Sotaro Ikeda [:sotaro]]

Hmm, I could not reproduce the problem with my Win 11 PCs.

Comment 18

[abubaca4]

(In reply to Alastor Wu [:alwu] from comment #13)

Hi, abubaca4,

Sorry for late reply. I'd like to confirm with you, so for your profile in the comment12, you had started playing the video first, then started profiling and immediately put the Firefox to background? Is my assumption correct? I can see the issue happened around on 6.28s, which I suppose it was around the time after you put Firefox to background.

Maybe I not immediately put to background, it's can be in 1-2s. Your assumption correct.

Does this issue happen related with another application you put on the foreground? or you can easily reproduce this issue by putting Firefox on background, and no other application on the foreground? does this issue happen on a private browsing mode or on a fresh Firefox profile?

Only when I open game with high gpu load. Works with different games, on unity, unreal engine, etc.
States:
Game not run, open desktop. No problem.
Game not run, open vs code/edge/etc. No problem.
Game run, open desktop. No problem.
Game run, open vs code/edge/etc. No problem.
Game run, open game. Problem exist.
Games with low gpu load like Dead Cells does not cause a problem.
All tested game work in dx11 mode. I can try with vulcan game if needed.

In private mode problem also exist.

The current issue is the HW decoding was completely stuck with no reason... I can't think of any possibilities right now. If you said it's a regression from Fx131, would you mind using this tool to find out a culprit?

It's strange but when I try to reproduce this problem by this tool I also find in old version like 125.
Most likely the problem existed before but I did not have the conditions for its manifestation.
And now I can not cause the problem on my 1135g7 laptop.
Of the recent changes I changed my monitor from full hd 75hz to quadhd 165hz in month ago.
For the test, I hooked up my old monitor and displayed firefox with video on it. On my main monitor I opened the game. The problem did not occur.
Then I moved the browser window to a new monitor and opened the game there as well. The problem still didn't occur. And in this form after unfolding firefox video plays without lag that occurred before and now if you turn on decoding on the CPU.
After disconnecting the old monitor and rebooting, the problem exists again.

Now I'm starting to think the problem might be in my hardware. But it doesn't show up in chrome based browsers. Perhaps the simplest solution would be to add a mechanism that detects decoding hangs and force restart the process.
Also a multi-monitor configuration somehow prevents the problem from occurring even if Firefox and the game are on the same monitor.

Comment 19

[abubaca4]

I tested the game on vulkan. The problem does not occur. Firefox uses dx11 via ANGLE. Maybe it's a problem of interaction between two dx11 applications.

Comment 20

[Alastor Wu [:alwu]]

So this sounds more like a graphic issue, I will move it to another component and let them keep investigating this issue.

Comment 21

[Sotaro Ikeda [:sotaro]]

I wonder if WebRender native compositor(with Windows DirectComposition) usage on Windows10 or video overlay usage might affect to the problem.

(In reply to abubaca4 from comment #18)
Also a multi-monitor configuration somehow prevents the problem from occurring even if Firefox and the game are on the same monitor.

From the above comment, I wondered if WebRender native compositor or video overlay usage might affect to the problem. On Windows 10, "multiple monitor with > 60 fps" blocks WebRender native compositor(with Windows DirectComposition). See Bug 1638709.

• https://searchfox.org/mozilla-central/rev/b9e7c4300ba972a4c98bf463fc046e8cd9367175/gfx/config/gfxConfigManager.cpp#277

Comment 22

[Sotaro Ikeda [:sotaro]]

Hi, abubaca4,

Can you check if any of the followings address the problem?

• [1] set pref gfx.webrender.dcomp-video-hw-overlay-win = false in about:config and restart Firefox.
• [2] set pref gfx.webrender.compositor = false in about:config and restart Firefox.
• [3] set pref gfx.webrender.dcomp-win.enabled = false in about:config and restart Firefox.

Comment 23

[abubaca4]

(In reply to Sotaro Ikeda [:sotaro] from comment #22)

Hi, abubaca4,

Can you check if any of the followings address the problem?

• [1] set pref gfx.webrender.dcomp-video-hw-overlay-win = false in about:config and restart Firefox.

Not help

• [2] set pref gfx.webrender.compositor = false in about:config and restart Firefox.

Help

• [3] set pref gfx.webrender.dcomp-win.enabled = false in about:config and restart Firefox.

Help

Comment 24

[Sotaro Ikeda [:sotaro]]

Thank you for the quick check!

Then it seems better to disable WebRender native compositor with the GPU. In Firefox on Windows, WebRender native compositor uses a lot of IDCompositionVisual in one window. It might affect to the problem. chromium basically uses one IDCompositionVisual for each window except video overlay.

Comment 25

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1923697 - Block FEATURE_WEBRENDER_COMPOSITOR on Pascal-architecture NVIDIA GPUs on Windows 10

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/710973287320
Block FEATURE_WEBRENDER_COMPOSITOR on Pascal-architecture NVIDIA GPUs on Windows 10 r=win-reviewers,handyman

Comment 27

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/710973287320

Comment 28

[Ciprian Georgiu, Desktop QA]

Hi, abubaca4! Can you please help us verifying this issue on latest Beta 133? I'm not able to reproduce the problem using the STR from comment 0, I've tried on a NVidia GPU, but without success on Win 10 x64.

Comment 29

[abubaca4]

(In reply to Ciprian Georgiu, Desktop QA from comment #28)

Hi, abubaca4! Can you please help us verifying this issue on latest Beta 133? I'm not able to reproduce the problem using the STR from comment 0, I've tried on a NVidia GPU, but without success on Win 10 x64.

No issue on Beta 133

Comment 30

[Ciprian Georgiu, Desktop QA]

Thanks, abubaca4! Closing this as verified fixed per comment 29.