Open Bug 1608485 Opened 10 months ago Updated 1 month ago

1080p 60fps Fullscreen videos stutter with double-buffering

Categories

(Core :: Graphics, defect, P3)

defect

Tracking

()

Tracking Status
firefox-esr68 --- unaffected
firefox72 + disabled
firefox73 + disabled
firefox74 + disabled
firefox81 --- disabled
firefox82 --- 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)

marking severity as minor because we unshipped this feature

Severity: normal → minor
Priority: P1 → P3

The self-hosted 60fps 720p HTML5 videos on my website are still lagging in Mac OS Firefox 80.0.1, even not in fullscreen mode, but also in a small 960x540 video frame!

Toggling gfx.direct3d11.use-double-buffering didn't help at all.
Add-ons are not what is causing this video stutter either.

How come Safari and Chrome don't have this problem?

[Tracking Requested - why for this release]:

(In reply to andy_nc from comment #36)

The self-hosted 60fps 720p HTML5 videos on my website are still lagging in Mac OS Firefox 80.0.1, even not in fullscreen mode, but also in a small 960x540 video frame!

Toggling gfx.direct3d11.use-double-buffering didn't help at all.
Add-ons are not what is causing this video stutter either.

How come Safari and Chrome don't have this problem?

Please file a new bug for your issue.

(In reply to Julien Cristau [:jcristau] from comment #38)

(In reply to andy_nc from comment #36)

The self-hosted 60fps 720p HTML5 videos on my website are still lagging in Mac OS Firefox 80.0.1, even not in fullscreen mode, but also in a small 960x540 video frame!

Toggling gfx.direct3d11.use-double-buffering didn't help at all.
Add-ons are not what is causing this video stutter either.

How come Safari and Chrome don't have this problem?

Please file a new bug for your issue.

Care to explain why do I need to file a new bug? It's all the same – the lagging of HTML5 videos in firefox – whether via Youtube or self-hosted. In my view it fits perfectly here.

This bug was related to double buffering. You say it doesn't make a difference for you, so it's a different issue, and should be tracked in a new bug.

(In reply to andy_nc from comment #39)

(In reply to Julien Cristau [:jcristau] from comment #38)

Please file a new bug for your issue.

Care to explain why do I need to file a new bug? It's all the same – the lagging of HTML5 videos in firefox – whether via Youtube or self-hosted. In my view it fits perfectly here.

In addition to what Julien said, note that this issue was for fullscreen videos, and reading the comments also seems to indicate the bug reports are largely focused on Windows machines. Neither of those things applies to your bugreport (although I think you say this video stutter also happens to fullscreen videos for you?), which suggests there is something else going wrong that may be Mac-specific.

(In reply to Nathan Froyd [:froydnj] from comment #41)

(In reply to andy_nc from comment #39)

(In reply to Julien Cristau [:jcristau] from comment #38)

Please file a new bug for your issue.

Care to explain why do I need to file a new bug? It's all the same – the lagging of HTML5 videos in firefox – whether via Youtube or self-hosted. In my view it fits perfectly here.

In addition to what Julien said, note that this issue was for fullscreen videos, and reading the comments also seems to indicate the bug reports are largely focused on Windows machines. Neither of those things applies to your bugreport (although I think you say this video stutter also happens to fullscreen videos for you?), which suggests there is something else going wrong that may be Mac-specific.

Yes, it's all the same in my case – both for fullscreen and small-framed playback. And it doesn't matter, if it's a 720p, 1440p or 1080p video – as long it is a 60 fps video – it stutters, regardless whether it is original self-hosted HTML5 video or a Youtube-recoded one.

Strangely, however, when using 720p or 1080p 60fps video as a slide in Revolution Slider for WordPress, there is almost no stutter, regardless of the size.
I doubt that it's Mac-specific, because that doesn't happen in Safari or Chrome for Mac. Unless you mean that it might specific to the Firefox for Mac, but not the Mac OS?

(In reply to andy_nc from comment #42)

Strangely, however, when using 720p or 1080p 60fps video as a slide in Revolution Slider for WordPress, there is almost no stutter, regardless of the size. I doubt that it's Mac-specific, because that doesn't happen in Safari or Chrome for Mac. Unless you mean that it might specific to the Firefox for Mac, but not the Mac OS?

The WordPress thing is an interesting datapoint, thanks for that. And yes, sorry for being unclear: not an issue with macOS generally, but specifically with Firefox for macOS. In any event, please file another bug!

Summary: 1080p 60fps Fullscreen videos stutter → 1080p 60fps Fullscreen videos stutter with double-buffering

The WordPress thing is an interesting datapoint, thanks for that. And yes, sorry for being unclear: not an issue with macOS generally, but specifically with Firefox for macOS. In any event, please file another bug!

Yes, I've already opened up another ticket here:

However, it turned out that it doesn't matter, whether the video is used in a Slider Revolution plugin or as a self-hosted HTML5 video.
The real difference is:
In a short 60fps 720p video (about 30sec) there is no stutter, but when the same video is part of a longer video (about 3:30), the stutter occurs at least every second playback and often, for no reason, when jumping back and forth on the timeline.

And it also turned out that it is specific for Firefox and Waterfox for Mac. No stutter in Firefox Developer Edition, Safari or Chrome on the same Mac.

You need to log in before you can comment on or make changes to this bug.