Overlay of hardware-decoded video results in stuttering video on RTX 4090
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox122 | --- | wontfix |
| firefox123 | --- | fixed |
| firefox124 | --- | fixed |
People
(Reporter: avekifes, Assigned: sotaro, NeedInfo)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(3 files)
|
17.22 KB,
text/plain
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta-
dmeehan
:
approval-mozilla-release-
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
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•3 years ago
|
||
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•3 years ago
|
||
Can you attach the contents of the graphics section of about:support?
Comment 4•3 years ago
|
||
Can you also post the Window version from about:support? It should be up near the top.
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
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Updated•3 years ago
|
Comment 6•3 years ago
|
||
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?
(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-winand restart?
Video playback appears to be normal after gfx.webrender.dcomp-video-overlay-win is re-enabled.
Updated•3 years ago
|
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.
This problem has returned. Disabling gfx.webrender.dcomp-video-overlay-win doesn't work for me, but turning off hardware acceleration does.
Comment 10•2 years ago
|
||
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•2 years ago
|
||
Mike, does avekifes' solution in comment 10 work for you as well?
Comment 12•2 years ago
|
||
I was not sure which option Hardware Acceleration was. Is that in about:config or in regular Firefox settings?
Comment 13•2 years ago
•
|
||
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•2 years ago
|
||
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•2 years ago
|
||
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•2 years ago
|
||
Any chance you could perform a mozregression and see if you can pinpoint the release where you started to see the stuttering?
| Reporter | ||
Comment 17•2 years ago
|
||
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•2 years ago
|
||
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.
| Assignee | ||
Comment 19•2 years ago
•
|
||
Hi avekifes, can you get firefox profiler with media settings when the problem happens? Thank you.
Comment 20•2 years ago
|
||
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'"
| Assignee | ||
Comment 21•2 years ago
|
||
profile data from #media channel.
https://share.firefox.dev/4bjjBE4
| Assignee | ||
Comment 22•2 years ago
•
|
||
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
| Assignee | ||
Comment 23•2 years ago
|
||
I confirmed the problem of comment 22 with my Win11 PC with NVIDA GPU. I am going to look into it.
| Assignee | ||
Comment 24•2 years ago
|
||
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.
| Assignee | ||
Comment 25•2 years ago
|
||
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 26•2 years ago
|
||
Bug 1851625 enabled video overlay on release with NVIDIA GPUs.
| Assignee | ||
Comment 27•2 years ago
|
||
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].
Updated•2 years ago
|
Comment 28•2 years ago
|
||
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.
| Assignee | ||
Comment 29•2 years ago
|
||
When I tested locally mSyncObject->Synchronize(true) also worked with compositor device. If it works without problem, it is better than D200041.
| Assignee | ||
Comment 30•2 years ago
|
||
(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.
| Assignee | ||
Comment 31•2 years ago
•
|
||
One thing we could do for D200041 is deferring ID3D11Query wait from D3D11DXVA2Manager::CopyToImage(). Current implementation blocks thread of D3D11DXVA2Manager::CopyToImage() long time.
Updated•2 years ago
|
Comment 32•2 years ago
|
||
Comment 33•2 years ago
|
||
| bugherder | ||
Comment 34•2 years ago
|
||
Set release status flags based on info from the regressing bug 1851625
| Assignee | ||
Comment 35•2 years ago
|
||
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•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 37•2 years ago
•
|
||
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.
Updated•2 years ago
|
Comment 38•2 years ago
|
||
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•2 years ago
|
||
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•2 years ago
|
||
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
Updated•2 years ago
|
Comment 41•2 years ago
|
||
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•2 years ago
|
||
Kelsey, could you review today https://phabricator.services.mozilla.com/D201007 which is the beta uplift request? Thanks
Updated•2 years ago
|
Comment 43•2 years ago
|
||
| uplift | ||
Updated•2 years ago
|
Comment 44•2 years ago
|
||
(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!
Description
•