1817617 - Overlay of hardware-decoded video results in stuttering video on RTX 4090

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P2)

Description

[avekifes]

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

Steps to reproduce:

Streaming video at certain websites (e.g., Streamate.com [NSFW]) stutter in the latest version of Firefox, which introduces the following: "Enables overlay of hardware-decoded video with non-Intel GPUs on Windows 10/11, improving video playback performance and video scaling quality."

Setting "gfx.webrender.dcomp-video-overlay-win" to false in about:config addresses the issue.

Actual results:

Stuttering and other anomalies with playback of streaming video.

Expected results:

Smooth playback.

Comment 1

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

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

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Can you attach the contents of the graphics section of about:support?

Comment 3

[avekifes]

Attachment: Graphics

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Can you also post the Window version from about:support? It should be up near the top.

Comment 5

[avekifes]

Application Basics

Name: Firefox
Version: 110.0
Build ID: 20230214051806
Distribution ID:
Update Channel: release
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
OS: Windows_NT 10.0 19045
Launcher Process: Enabled
Multiprocess Windows: 1/1
Fission Windows: 1/1 Enabled by default
Remote Processes: 10
Enterprise Policies: Inactive
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false
Memory Size (RAM): 31.9 GB
Disk Space Available: 201 GB

Comment 6

[Jeff Muizelaar [:jrmuizel]]

I block list rule has been added that blocks this feature on Nvidia hardware in 110. Do you still see the problem if you reset gfx.webrender.dcomp-video-overlay-win and restart?

Comment 7

[avekifes]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)

I block list rule has been added that blocks this feature on Nvidia hardware in 110. Do you still see the problem if you reset gfx.webrender.dcomp-video-overlay-win and restart?

Video playback appears to be normal after gfx.webrender.dcomp-video-overlay-win is re-enabled.

Comment 8

[Mike]

I was having stuttering issues after the latest Firefox update when watching Discord streams. I disabled gfx.webrender.dcomp-video-overlay-win and the stuttering instantly stopped.

I don't know what that is but it's causing issues.

Comment 9

[avekifes]

This problem has returned. Disabling gfx.webrender.dcomp-video-overlay-win doesn't work for me, but turning off hardware acceleration does.

Comment 10

[Mike]

I also have stuttering again. It makes using Discord to screen share (see someone else's screen) impossible. And it gives major headaches if you try.

Comment 11

[Bob Hood [:bhood]]

Mike, does avekifes' solution in comment 10 work for you as well?

Comment 12

[Mike]

I was not sure which option Hardware Acceleration was. Is that in about:config or in regular Firefox settings?

Comment 13

[Bob Hood [:bhood]]

Settings -> General -> Performance. Turn off both checkboxes (not sure if you need to, but just to be sure...) and restart Firefox.

When it starts, about:support should show that WebRender is in "Software" mode.

Comment 14

[Mike]

Thank you, I just wanted to make sure I was disabling the right thing.

Yes, with Hardware Acceleration turned off the Discord video is no longer jittering.

Comment 15

[Mike]

Oh and let me add, I read the topic title - I am using a NVIDIA GeForce GTX 1050 Ti. Which looking back, is a bit old now isn't it??

I did not have the stuttering until recently.

Comment 16

[Bob Hood [:bhood]]

Any chance you could perform a mozregression and see if you can pinpoint the release where you started to see the stuttering?

Comment 17

[avekifes]

This problem started with the latest version, 119.0. But I'm not seeing anything on the changelog that might be related.

And the only other major things I've done with my PC over the last few days was install the most recent Windows 10 updates and NVIDIA's latest driver.

Comment 18

[Bob Hood [:bhood]]

mozregression would help us locate the actual commit (or group of commits) that correlate to the issue, so it would move things a bit more quickly if you could run that.

Comment 19

[Sotaro Ikeda [:sotaro]]

Hi avekifes, can you get firefox profiler with media settings when the problem happens? Thank you.

https://profiler.firefox.com/

Comment 20

[Andrew]

Hi all, We have several users of our web application running into this issue with Firefox. We are also able to reproduce it on our Windows machines with nvidia cards, as well. Using mozregression, we believe that we've narrowed it to this 1 day range:
mozilla-central 2022-11-21 (good)
mozilla-central 2022-11-22 (bad)
Here's a screenshot of the mozregression run: https://i.imgur.com/8ZC6xaZ.png

Unfortunately, when mozregression tries to narrow the range further within 2022-11-21 - 2022-11-22, it gives an error like "Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.shippable.revision.bd8c9b741d01c77c5b52087717032ecbbfcafcf3.firefox.win64-opt'"

Comment 21

[Sotaro Ikeda [:sotaro]]

profile data from #media channel.
https://share.firefox.dev/4bjjBE4

Comment 22

[Sotaro Ikeda [:sotaro]]

STR from #media.

Prerequisites: Use Windows 11 with a discrete nvidia GPU, preferrably 4000 series like RTX 4060, RTX 4090, etc since we know these are impacted. Hardware acceleration enabled in FF.

Go to https://garbage.nira.app/a/1a9akm9rTCO6Mf1xaCuN6w/1
Click "View in 3D" button
After 1-2 seconds of loading, you should see a teapot. Now press Alt+L and the teapot should start rotating.

Expected result:
the teapot should rotate quite smoothly

Actual result:
the rotation of the teapot is very jerky every 1-3 seconds, similar to the jerkiness shown in this video

Comment 23

[Sotaro Ikeda [:sotaro]]

I confirmed the problem of comment 22 with my Win11 PC with NVIDA GPU. I am going to look into it.

Comment 24

[Sotaro Ikeda [:sotaro]]

Normally when D3D11Texture2D is copied by ID3D11DeviceContext::CopySubresourceRegion() with compositor device, WebRender does not need to wait copy complete, since WebRender also uses compositor device.

But with NDIVIA GPUs, the copy complete need to be wait explicitly even with compositor device during using video overlay.

Comment 25

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1817617 - Wait ID3D11Query of D3D11Texture2D copy complete just before blitting for video overlay with non Intel GPUs

Comment 26

[Sotaro Ikeda [:sotaro]]

Bug 1851625 enabled video overlay on release with NVIDIA GPUs.

Comment 27

[Sotaro Ikeda [:sotaro]]

This problem was resolved for me in each of the followings.

• [1] Apply D200041
• [2] pref gfx.direct3d11.reuse-decoder-device = false
• [3] pref media.wmf.zero-copy-nv12-textures-force-enabled = true

[2] always happens on AMD GPUs in DeviceManagerDx::CreateDecoderDevice()

Even when [3] avoid D3D11DXVA2Manager::CopyToImage() with compositor device with the STR.
The CopyToImage() with compositor device will be enabled when video is rendered to WebGL.

Then [1] seems better solution in [1]-[3].

Comment 28

[Andrew]

FWIW, if/when D200041 is merged, an uplift into 123 and even an uplift for a 122 point release would be great, if it at all possible. This will fix a video stuttering issue that is happening on websites in the wild.

Comment 29

[Sotaro Ikeda [:sotaro]]

When I tested locally mSyncObject->Synchronize(true) also worked with compositor device. If it works without problem, it is better than D200041.

Comment 30

[Sotaro Ikeda [:sotaro]]

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

When I tested locally mSyncObject->Synchronize(true) also worked with compositor device. If it works without problem, it is better than D200041.

When video overlay is disabled, mSyncObject->Synchronize(true) caused to freeze renderer thread as before. Then we could not use it.

Comment 31

[Sotaro Ikeda [:sotaro]]

One thing we could do for D200041 is deferring ID3D11Query wait from D3D11DXVA2Manager::CopyToImage(). Current implementation blocks thread of D3D11DXVA2Manager::CopyToImage() long time.

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a6f8b76ccc84
Wait ID3D11Query of D3D11Texture2D copy complete just before blitting for video overlay with non Intel GPUs r=media-playback-reviewers,padenot

Comment 33

[Serban Stanca [:SerbanS]]

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

Comment 34

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

Set release status flags based on info from the regressing bug 1851625

Comment 35

[Sotaro Ikeda [:sotaro]]

Comment on attachment 9377226 [details]
Bug 1817617 - Wait ID3D11Query of D3D11Texture2D copy complete just before blitting for video overlay with non Intel GPUs

Beta/Release Uplift Approval Request

• User impact if declined: video rendering could become stuttering with non-Intel GPUs when video overlay is used.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It add wait of ID3D11Query just before blitting for video overlay . Code change is relatively simple.
• String changes made/needed: none
• Is Android affected?: No

Comment 36

[Donal Meehan [:dmeehan]]

Comment on attachment 9377226 [details]
Bug 1817617 - Wait ID3D11Query of D3D11Texture2D copy complete just before blitting for video overlay with non Intel GPUs

Rejecting release uplift request:

• This has not been uplifted to beta yet, so it has not gotten any coverage in the beta population.
• This has an S3 severity and is not new in Fx122.
• This did not make the Fx122 planned dot release. Any further releases in Fx122 would be for a critical release, we wouldn't take any ride-alongs.

Comment 37

[Pascal Chevrel:pascalc]

Comment on attachment 9377226 [details]
Bug 1817617 - Wait ID3D11Query of D3D11Texture2D copy complete just before blitting for video overlay with non Intel GPUs

This is an old regression and we are nearing the end of the beta cycle, I think this should ride the 124 train.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Per Matrix discussion, here's a link to Try builds of this patch grafted on top of Beta 123. Would be great if people affected by this issue could test them out to confirm that they work as expected.
Win32: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fuB80ySeSz2sKdTikX0_8A/runs/0/artifacts/public/build/target.zip
Win64: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Tylmrqu7QceLCD9MRsgNAA/runs/0/artifacts/public/build/target.zip

Comment 39

[Ryan VanderMeulen [:RyanVM]]

Try push for said builds:
https://treeherder.mozilla.org/jobs?repo=try&revision=5a4e78bedf20b6fd63d81f47ff7907c3ee5412f7

I received confirmation via email from one person who could reproduce the problem that the Try builds work as expected.

Comment 40

[Ryan VanderMeulen [:RyanVM]]

Attachment: Bug 1817617 - Wait ID3D11Query of D3D11Texture2D copy complete just before blitting for video overlay with non Intel GPUs

Normally when D3D11Texture2D is copied by ID3D11DeviceContext::CopySubresourceRegion() with compositor device, WebRender does not need to wait copy complete, since WebRender also uses compositor device.

But with Non-intel GPUs(like NDIVIA), there is a case that the copy complete need to be wait explicitly even with compositor device

mSyncObject->Synchronize() could not be used with compositor device.

Wait of the query is not called in D3D11DXVA2Manager::CopyToImage(), since the wait could take long time. Then the Wait of the query is deferred to just before blitting for video overlay.

Original Revision: https://phabricator.services.mozilla.com/D200041

Comment 41

[Phabricator Automation]

Uplift Approval Request

• Risk associated with taking this patch: Low
• Needs manual QE test: no
• Explanation of risk level: It add wait of ID3D11Query just before blitting for video overlay . Code change is relatively simple.
• Code covered by automated testing: yes
• String changes made/needed: none
• Fix verified in Nightly: yes
• User impact if declined: video rendering could become stuttering with non-Intel GPUs when video overlay is used.
• Is Android affected?: no
• Steps to reproduce for manual QE testing: n/a

Comment 42

[Pascal Chevrel:pascalc]

Kelsey, could you review today https://phabricator.services.mozilla.com/D201007 which is the beta uplift request? Thanks

Comment 43

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/98cb75795f83

Comment 44

[Kelsey Gilbert [:jgilbert]]

(In reply to Pascal Chevrel:pascalc from comment #42)

Kelsey, could you review today https://phabricator.services.mozilla.com/D201007 which is the beta uplift request? Thanks

Please ping me on Matrix next time if you need me same-day!