1080p 60fps Fullscreen videos stutter with double-buffering
Categories
(Core :: Graphics, defect, P3)
Tracking
()
People
(Reporter: jrmuizel, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
From https://www.reddit.com/r/firefox/comments/emltuf/1080p_60fps_fullscreen_videos_stutter/
Disabling double buffering fixes the problem.
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
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.
Reporter | ||
Comment 2•5 years ago
|
||
There are multiple people experiencing the problem on reddit.
Reporter | ||
Comment 3•5 years ago
|
||
Micheal, is it possible for us to push pref changes that require a restart?
Reporter | ||
Comment 4•5 years ago
|
||
One of the reports is on:
Description: Intel(R) HD Graphics 5500
Vendor ID: 0x8086
Device ID: 0x1616
Driver Version: 20.19.15.5063
Comment 5•5 years ago
|
||
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.
Comment 6•5 years ago
|
||
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.
Reporter | ||
Comment 7•5 years ago
•
|
||
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",
Reporter | ||
Comment 8•5 years ago
|
||
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
Comment 9•5 years ago
|
||
Can you file a new bug, attach the patch, and put an uplift request on it? That will help us keep everything in order.
Reporter | ||
Comment 11•5 years ago
|
||
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
Comment 12•5 years ago
|
||
Do we know if 73 and 74 are also affected?
Reporter | ||
Comment 13•5 years ago
|
||
(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.
Reporter | ||
Comment 14•5 years ago
|
||
Andrei can you reproduce this issue on 72?
Comment 15•5 years ago
|
||
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.
Comment 16•5 years ago
•
|
||
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.
Updated•5 years ago
|
Reporter | ||
Comment 17•5 years ago
|
||
Can you also reproduce the problem on other systems?
Comment 18•5 years ago
•
|
||
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.
Reporter | ||
Comment 20•5 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #19)
Yeah, I meant separate hardware.
Do you have any other hardware you can try?
Updated•5 years ago
|
Comment 21•5 years ago
|
||
Some more reddit reports:
https://www.reddit.com/r/firefox/comments/eokyhd/video_shaking/ (4 users)
https://www.reddit.com/r/firefox/comments/en4x47/videos_unplayable_n_fullscreen_now_in_firefox/ (3 users, h264ify)
https://www.reddit.com/r/firefox/comments/eoif3p/screen_tearing_on_fullscreen_videos_as_of_version/ (4 users, freesync)
https://www.reddit.com/r/firefox/comments/enr3ol/i_found_that_my_video_is_shaking_when_watching/ (2 users)
https://www.reddit.com/r/firefox/comments/elkx85/ff_720_videos_on_youtube_at_least_sometimes/ (6 users, h264ify)
There are two mentions of h264ify extension and h264 itself contributing to the problem. Try setting media.webm.enabled = false
to force fallback to h264.
Comment 23•5 years ago
•
|
||
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.
Comment 24•5 years ago
|
||
Comment 25•5 years ago
|
||
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.
Comment 26•5 years ago
|
||
(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.
Comment 27•5 years ago
|
||
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.
Comment 28•5 years ago
|
||
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
Comment 29•5 years ago
|
||
(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.
Comment 30•5 years ago
|
||
Double buffering was disabled for 73+ in bug 1610912. Leaving this bug open as a blocker for re-enabling, however.
Comment 31•5 years ago
|
||
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.
Comment 32•5 years ago
|
||
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.
Reporter | ||
Comment 33•5 years ago
|
||
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?
Comment 34•5 years ago
|
||
(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
Comment 35•5 years ago
|
||
marking severity as minor because we unshipped this feature
Comment 36•4 years ago
|
||
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?
Comment 37•4 years ago
|
||
[Tracking Requested - why for this release]:
Comment 38•4 years ago
|
||
(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.
Comment 39•4 years ago
|
||
(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.
Comment 40•4 years ago
|
||
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.
Comment 41•4 years ago
|
||
(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.
Comment 42•4 years ago
|
||
(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?
Comment 43•4 years ago
|
||
(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!
Updated•4 years ago
|
Comment 44•4 years ago
|
||
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.
Comment 45•4 years ago
|
||
forgot the link:
https://bugzilla.mozilla.org/show_bug.cgi?id=1663990
Comment 46•3 years ago
|
||
I am facing the same issue with Firefox 97.0.1
No issues while playing 1080p 60fps on chrome
Tried disabling double buffering- No go
Let me know any further information required
Reporter | ||
Comment 47•3 years ago
|
||
vishnukumar.mk can you attach your about:support to the bug?
Comment 48•3 years ago
|
||
about:support attached
Comment 49•3 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #47)
vishnukumar.mk can you attach your about:support to the bug?
Hello Jeff,
Attached the file.
Reporter | ||
Comment 50•3 years ago
|
||
vishnukumar.mk, what's the last version of Firefox that worked well for you?
Comment 51•3 years ago
|
||
I don't remember the last version which worked. no issues with 720p, i noticed this only when switched to 1080p
Reporter | ||
Comment 52•3 years ago
|
||
It may be better to track your issue in a separate bug then. Can you file one and link to it here?
Comment 53•3 years ago
|
||
Updated•2 years ago
|
Description
•