Open Bug 1608485 Opened 3 months ago Updated 2 months ago

1080p 60fps Fullscreen videos stutter

Categories

(Core :: Graphics, defect, P1)

defect

Tracking

()

Tracking Status
firefox-esr68 --- unaffected
firefox72 + disabled
firefox73 + disabled
firefox74 + disabled

People

(Reporter: jrmuizel, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Regressed by: 1580222
Keywords: regression
Priority: -- → P1

We don't know how wide spread this problem is, but we may want to consider doing a dot release or pushing a pref change for this.

Flags: needinfo?(jcristau)

There are multiple people experiencing the problem on reddit.

Micheal, is it possible for us to push pref changes that require a restart?

Flags: needinfo?(mcooper)

One of the reports is on:

Description: Intel(R) HD Graphics 5500
Vendor ID: 0x8086
Device ID: 0x1616
Driver Version: 20.19.15.5063

Tracking so we can keep an eye on this. A pref flip might be the fastest way to go but we also are likely planning a (non urgent) dot release for mid next week.

If a feature requires a restart, is in Native code, and doesn't have a special case for Normandy, we probably can't change it like this.

For large scale changes, features that require a restart are usually incompatible because we use the default preference branch. The default preference branch gets cleared and re-set each time Firefox starts. The process of Normandy re-setting preferences usually happens after the graphics stack has read the preferences, and so the feature never takes affect.

Webrender has some special code to handle this situation, as do some other features.

Flags: needinfo?(mcooper)

Another report is:

    "adapterDescription": "Intel(R) HD Graphics 620",
    "adapterVendorID": "0x8086",
    "adapterDeviceID": "0x5916",
    "adapterSubsysID": "14901043",
    "adapterRAM": 0,
    "adapterDrivers": "igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32",
    "driverVendor": "",
    "driverVersion": "21.20.16.4627",
    "driverDate": "3-9-2017",
    "adapterDescription2": "NVIDIA GeForce 940MX",
    "adapterVendorID2": "0x10de",
    "adapterDeviceID2": "0x134d",
    "adapterSubsysID2": "14901043",
    "adapterRAM2": 2048,
    "adapterDrivers2": "C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumdx.dll,C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumdx.dll,C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumdx.dll,C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumdx.dll C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumd.dll,C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumd.dll,C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumd.dll,C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\nvami.inf_amd64_b72356da889ff492\\nvldumd.dll",
    "driverVendor2": "",
    "driverVersion2": "26.21.14.4187",

Liz, it sounds like a remote pref flip won't work. Here's the change that we'd want landed for the dot release:
https://hg.mozilla.org/releases/mozilla-release/rev/2dd6b102980e

Can you file a new bug, attach the patch, and put an uplift request on it? That will help us keep everything in order.

Flags: needinfo?(jmuizelaar)

Done in bug 1608579.

Flags: needinfo?(jmuizelaar)
See Also: → 1608579

And another report on:

GPU #1
Active	Yes
Description	Intel(R) UHD Graphics 620
Vendor ID	0x8086
Device ID	0x3ea0
Driver Version	26.20.100.6860
Driver Date	4-30-2019
Drivers	igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32
Subsys ID	39eb17aa
RAM	0
GPU #2
Active	No
Description	NVIDIA GeForce MX250
Vendor ID	0x10de
Device ID	0x1d13
Driver Version	26.21.14.3091
Driver Date	5-26-2019
Drivers	C:\Windows\System32\Drive

Do we know if 73 and 74 are also affected?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

Do we know if 73 and 74 are also affected?

I would expect so, but haven't confirmed.

Andrei can you reproduce this issue on 72?

Flags: needinfo?(andrei.vaida)

FWIW, i got this on both of my Lenovo thinkpads. One has an Quadro P2000, using Nvidia driver: 26.21.14.3194. The other is a GeForce® GTX 1650. I'm really glad i was able to find the reddit post as the behavior was driving me nuts.

I hope this isn't spam and that you find the above information useful. Happy to supply you with anything else you may need.

I was successful in reproducing the issue on 72.0.1, 73.0b4 only on 4k 60fps fullscreen with greasemonkey addon installed. Couldn't seem to trigger it on latest Nightly 74.0a1 (2020-01-14). Here's an attachment on which the stutter can be seen at 4k 60fps on a Intel HD 630 graphics (venID 8086, devID 5912) with driver version 25.20.100.6576, Windows 10.

Please let me know if I can help with anything else.

Flags: needinfo?(andrei.vaida)

Can you also reproduce the problem on other systems?

Flags: needinfo?(catalin.sasca)

Jeff, are you referring to a system with different hardware or are you referring to try on macOS and Linux?

I just tried on a HP laptop with Intel HD 520, but it isn't able to render 4k 60fps (due to hardware limits), and on 1440p60 and 1080p60 I wasn't able to reproduce the issue.

Flags: needinfo?(catalin.sasca) → needinfo?(jmuizelaar)

Yeah, I meant separate hardware.

Flags: needinfo?(jmuizelaar)

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

Yeah, I meant separate hardware.

Do you have any other hardware you can try?

Flags: needinfo?(catalin.sasca)
Duplicate of this bug: 1607899

Wasn't able to reproduce the issue on 2 other different systems. One is a Dell laptop with Intel HD 4400 (20.19.15.4531 driver version), and the second is a desktop PC with integrated ATI Radeon HD 3000 graphics (8.970.100.9011 driver version). Both performed as expected either on 1080p60 or 1440p60, 4k60 was not testable due to hardware limits.

The only system on which I reproduced it had Intel HD 630 with latest driver installed and only on 4k60 (maybe there was a recent update for these gpu's which added an incompatibility and triggers this stutter).

Please let me know if I can help with anything else.

Flags: needinfo?(catalin.sasca)

This should be fixed for the upcoming 72.0.2 release via bug 1608579. Given where we are in the Beta73 cycle, we may want to consider landing the pref flip there as well.

Flags: needinfo?(jcristau)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #25)

This should be fixed for the upcoming 72.0.2 release via bug 1608579. Given where we are in the Beta73 cycle, we may want to consider landing the pref flip there as well.

I think it should be marked disabled not fixed.

Interesting, I was experiencing the shaking as well but I hadn't watched many videos since I reinstalled Windows and wasn't sure if it was just the source material being funky.

This bug can be reproduced with the Microsoft Wireless Display toolbar hidden.
Check here https://www.askwoody.com/forums/topic/microsoft-wireless-display-toolbar-banner-interfering-with-video-using-firefox/#post-2087984

(In reply to jorb from comment #28)

This bug can be reproduced with the Microsoft Wireless Display toolbar hidden.
Check here https://www.askwoody.com/forums/topic/microsoft-wireless-display-toolbar-banner-interfering-with-video-using-firefox/#post-2087984
Also scroll thread for fix.

Double buffering was disabled for 73+ in bug 1610912. Leaving this bug open as a blocker for re-enabling, however.

See Also: → 1598126

When I connect Microsoft Wireless Display, and not using Firefox browser I.E. playing videos through Movies & TV app.
I get a jerky playback. I'm on windows 10 version 1903. Windows media player works fine.

still having this issue with 72.0.2
here is an example of the issue side by side with chrome (FF on the right): https://streamable.com/z1kpl
here is my support dump: https://pastebin.com/Pgqv9aPB

I ran a mozilla regression and it was able to narrow it down to a single commit: https://hg.mozilla.org/integration/autoland/rev/f0dfc557b20c1dd9c2865df1db2a34dc783c92f8

Here's the regression output:

2020-01-31T21:38:12: INFO : Narrowed inbound regression window from [a0e0c81e, d25c3e10] (3 builds) to [a0e0c81e, f0dfc557] (2 builds) (~1 steps left)
2020-01-31T21:38:12: DEBUG : Starting merge handling...
2020-01-31T21:38:12: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=f0dfc557b20c1dd9c2865df1db2a34dc783c92f8&full=1
2020-01-31T21:38:13: DEBUG : Found commit message:
Bug 1596630 - Remove mSyncObject->Synchronize() in RenderCompositorANGLE::BeginFrame() r=nical

mSyncObject->Synchronize() was necessary to handle a case that D3D Texture was created on main thread of content process and the Texture does not have a keyed mutex. But with WebRender, the situation does not happen often. Further the Synchronize() is sometimes very slow. Therefore it is better to remove it from RenderCompositorANGLE::BeginFrame().

Canvas 2d does not use keyed mutex yet. Then the change adds keyed mutex usage for the canvas 2d.

D3D11DXVA2Manager still uses the Synchronize(). In this case, the Synchronize() is manually called in D3D11DXVA2Manager::CopyToImage(). Then RenderCompositorANGLE still needs to create SyncObjectHost.

Differential Revision: https://phabricator.services.mozilla.com/D53168

2020-01-31T21:38:13: DEBUG : Did not find a branch, checking all integration branches
2020-01-31T21:38:13: INFO : The bisection is done.

padamide, it's great that you were able to find a regression window. However, it seems like that is a separate issue. Do you mind filing a new bug that contains the information that you posted?

Flags: needinfo?(padamide)

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

padamide, it's great that you were able to find a regression window. However, it seems like that is a separate issue. Do you mind filing a new bug that contains the information that you posted?

Created Bug 1612665

Flags: needinfo?(padamide)
You need to log in before you can comment on or make changes to this bug.