Closed
Bug 1163454
Opened 9 years ago
Closed 9 years ago
YouTube 1080p/60 H.264 video massively drops frames
Categories
(Core :: Audio/Video, defect)
Tracking
()
VERIFIED
FIXED
mozilla41
Tracking | Status | |
---|---|---|
firefox39 | --- | unaffected |
firefox40 | + | verified |
firefox41 | + | verified |
People
(Reporter: lh.bennett, Assigned: mattwoodrow)
References
(Blocks 1 open bug, )
Details
(Keywords: regression)
Attachments
(1 file)
1.83 KB,
patch
|
ajones
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
YouTube MSE H264 has a regression in which it massively drops frames at 1080p60. Whether e10s is enabled or not makes no difference. Firefox 37 with MSE enabled shows zero regression. Internet Explorer and Google Chrome also plays these correctly. Adapter Description AMD Radeon HD 5700 Series Adapter Description (GPU #2) Intel(R) HD Graphics 4000 Adapter Drivers aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter Drivers (GPU #2) igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32 Adapter RAM 1024 Adapter RAM (GPU #2) Unknown Asynchronous Pan/Zoom none ClearType Parameters D [ Gamma: 2200 Pixel Structure: R ClearType Level: 50 Enhanced Contrast: 100 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] Device ID 0x68be Device ID (GPU #2) 0x0162 Direct2D Enabled true DirectWrite Enabled true (6.3.9600.17415) Driver Date 3-31-2015 Driver Date (GPU #2) 12-18-2014 Driver Version 14.502.1014.0 Driver Version (GPU #2) 10.18.10.4061 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 29801682 Subsys ID (GPU #2) 0000000c Supports Hardware H264 Decoding true Vendor ID 0x1002 Vendor ID (GPU #2) 0x8086 WebGL Renderer Google Inc. -- ANGLE (AMD Radeon HD 5700 Series Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote true AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0
Does this still occur after restarting the browser?
Reporter | ||
Comment 2•9 years ago
|
||
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #1) > Does this still occur after restarting the browser? Yes. It does.
Can you try getting a regression range using mozregression? That would help us narrow down the cause. http://harthur.github.io/mozregression/
Reporter | ||
Comment 4•9 years ago
|
||
Not sure if done correctly. I have zero experience with mozregression. According to mozregression: MainThread Bisector INFO Last good revision: 9684ebd911b4 MainThread Bisector INFO First bad revision: 09f1edec24b6 MainThread Bisector INFO Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9684ebd911b4&tochange=09f1 edec24b6 https://bugzilla.mozilla.org/show_bug.cgi?id=875247
Reporter | ||
Comment 5•9 years ago
|
||
For what its worth, YouTube MSE WebM/VP9 playback does not seem to be affected by this issue.
Comment 6•9 years ago
|
||
[Tracking Requested - why for this release]: Regression
Blocks: 875247, youtube-mse
Severity: normal → major
Status: UNCONFIRMED → NEW
status-firefox39:
--- → unaffected
status-firefox40:
--- → affected
status-firefox41:
--- → affected
tracking-firefox40:
--- → ?
tracking-firefox41:
--- → ?
Ever confirmed: true
Keywords: regression
Summary: [Regression] YouTube 1080p/60 H.264 video massively drops frames in Nightly → YouTube 1080p/60 H.264 video massively drops frames
Version: Trunk → 40 Branch
In reply to Leman Bennett [Omega] from comment #4) > https://bugzilla.mozilla.org/show_bug.cgi?id=875247 Thanks for tracking down the commit. Matt - looks like DXVA2 is causing some grief.
Flags: needinfo?(matt.woodrow)
In the team triage meeting, Liz and I looked at this and adding a tracking flag for Firefox 40 and 41 so we fix this issue.
Assignee | ||
Comment 9•9 years ago
|
||
Is there any noticeable difference in CPU usage between the good/bad builds? I haven't been able to reproduce this, but my current theory is that our attempts to use DXVA-D3D11 are failing and we're not falling back to DXVA-D3D9 and end up worse off.
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 10•9 years ago
|
||
Try run with better fallback to d3d9: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3cf09c817bcf
Reporter | ||
Comment 11•9 years ago
|
||
Ok, so I took the opportunity to do another mozregression run with a wider scope and it still lead me to the same revisions posted above. I also kept an eye on CPU usage. - CPU usage on bad builds barely breaks 11%. (2-6% main process, 6-9% content process) - CPU usage on good builds will bounce between 20-35%. (5-8% main process, 14-19% content process) Also, I've ran the Try build revision and saw worse results. The video drops frames more consistently than intermittent. From here: ftp://ftp.mozilla.org/pub/firefox/try-builds/mwoodrow@mozilla.com-3cf09c817bcf/try-win32/ In current nightly builds a few 1080p60 videos will attempt to play normally and then slow to a crawl. Afterward, it stalls for about 5-10 seconds, and then speeds back up to normal and then quickly degenerate again. This pattern will repeat until it settles into a constantly choppy video.
Comment 12•9 years ago
|
||
Reproduced with latest 40.0a2 (from 2015-06-08) and 41.0a1 (from 2015-06-08) under Window 8 32-bit (Graphics: NVIDIA GeForce 210 and nVIDIA GeForce 620) and Windows 8.1 64-bit (Graphics: AMD Radeon HD 7700 Series). With dxva disabled (media.hardware-video-decoding.enabled set to false), the drop frames rate is considerably lower.
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #12) > Reproduced with latest 40.0a2 (from 2015-06-08) and 41.0a1 (from 2015-06-08) > under Window 8 32-bit (Graphics: NVIDIA GeForce 210 and nVIDIA GeForce 620) > and Windows 8.1 64-bit (Graphics: AMD Radeon HD 7700 Series). With dxva > disabled (media.hardware-video-decoding.enabled set to false), the drop > frames rate is considerably lower. Can you try with the build in comment 10?
Flags: needinfo?(matt.woodrow)
Comment 14•9 years ago
|
||
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #13) > (In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #12) > > Reproduced with latest 40.0a2 (from 2015-06-08) and 41.0a1 (from 2015-06-08) > > under Window 8 32-bit (Graphics: NVIDIA GeForce 210 and nVIDIA GeForce 620) > > and Windows 8.1 64-bit (Graphics: AMD Radeon HD 7700 Series). With dxva > > disabled (media.hardware-video-decoding.enabled set to false), the drop > > frames rate is considerably lower. > > Can you try with the build in comment 10? With hope that the needinfo flag was meant for me, I managed to get access to the same try build (the link from comment 11 didn't work): http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-3cf09c817bcf/try-win32/ and the video drops frames more consistently on it. Tested under Windows 8.1 64-bit.
Assignee | ||
Comment 15•9 years ago
|
||
What do you think Anthony? I don't have any machines that will reproduce this issue, and I can't find any interesting differences between what we do and what blink does. Without any way of moving forward, we're probably better off to go back to d3d9 and regress the colour conversion.
Flags: needinfo?(matt.woodrow)
Attachment #8621720 -
Flags: review?(ajones)
Reporter | ||
Comment 16•9 years ago
|
||
Is there any way for us to provide more information about the issue that will help illuminate the problem, such as a performance profile?
Assignee | ||
Comment 17•9 years ago
|
||
A performance profile would definitely be interesting! Given that you said the CPU usage is much lower on broken builds than working ones, then I'm assuming we're blocking waiting for something, so it would ideally be a profile that shows idle time. I don't believe the gecko profiler does that unfortunately. Getting a gecko profile for both the good/bad builds would be a great start though, comparing them might be useful.
Reporter | ||
Comment 18•9 years ago
|
||
http://people.mozilla.org/~bgirard/cleopatra/#report=fa931a42c6e88e6e1f6d843c9c6213ea62b6c780 This is an April 11th, 2015 build before the DX11 push. I didn't use the exact build from mozregression but this one performs similarly. -------------------------------------- http://people.mozilla.org/~bgirard/cleopatra/#report=af6709755787641706d19c807738009529dc68ed This is from the latest Nightly as of today.
Comment on attachment 8621720 [details] [diff] [review] Disable D3D11 DXVA Review of attachment 8621720 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/media/platforms/wmf/WMFVideoMFTManager.cpp @@ +135,5 @@ > + static bool initialized = false; > + static bool d3d11Allowed = false; > + if (!initialized) { > + Preferences::AddBoolVarCache(&d3d11Allowed, "media.windows-media-foundation.allow-d3d11-dxva", false); > + initialized = true; Suggestion: there should be a class to do this tidily. I even wrote one but I can't recall if it ever got landed. In the meanwhile it looks like an unnecessary micro-optimisation . You could just check the pref directly inline.
Attachment #8621720 -
Flags: review?(ajones) → review+
Assignee | ||
Comment 20•9 years ago
|
||
(In reply to Leman Bennett [Omega] from comment #18) > http://people.mozilla.org/~bgirard/cleopatra/ > #report=fa931a42c6e88e6e1f6d843c9c6213ea62b6c780 > > This is an April 11th, 2015 build before the DX11 push. I didn't use the > exact build from mozregression but this one performs similarly. > > -------------------------------------- > > http://people.mozilla.org/~bgirard/cleopatra/ > #report=af6709755787641706d19c807738009529dc68ed > > This is from the latest Nightly as of today. Thanks for doing that. Unfortunately the gecko profiler only profiles the main thread and compositor thread, and neither of those appear to be the issue here. The frame rate drop is very visible, but both of the profiled threads are sitting idle during this period.
Comment 23•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c80271e9f1c2 https://hg.mozilla.org/mozilla-central/rev/6c05b6375d9f
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Comment 24•9 years ago
|
||
Matt, can we have an uplift request to 40/aurora? thanks
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 25•9 years ago
|
||
Comment on attachment 8621720 [details] [diff] [review] Disable D3D11 DXVA Approval Request Comment [Feature/regressing bug #]: Bug 875247 [User impact if declined]: Slow video decode performance [Describe test coverage new/current, TreeHerder]: [Risks and why]: Low risk, just disabling the new code. [String/UUID change made/needed]: None
Flags: needinfo?(matt.woodrow)
Attachment #8621720 -
Flags: approval-mozilla-aurora?
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → matt.woodrow
Comment 26•9 years ago
|
||
Comment on attachment 8621720 [details] [diff] [review] Disable D3D11 DXVA Improve the quality, taking it.
Attachment #8621720 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•9 years ago
|
Flags: qe-verify+
Comment 28•9 years ago
|
||
Verified fixed with 40.0b6 (Build ID: 20150720220238), under Windows 7 64-bit (Graphics: NVIDIA GeForce 210), Windows 8.1 32-bit (Graphics: ATI Radeon 3000) and Windows 10 32-bit (AMD Radeon HD 7700 Series): * with 40.0a2 (before this fix): around 1400 dropped frames out of 6000 * with 40.0b6 → 10 dropped frames out of 6000
Comment 29•9 years ago
|
||
Also verified fixed with 41.0b2 (Build ID: 20150817163452) under Windows 7 64-bit (2 different machines, NVIDIA GeForce 210 and AMD Radeon HD 6450) and Windows 10 32-bit (AMD Radeon HD 7700 Series).
Comment 30•8 years ago
|
||
I have the problem of dropped frames with Firefox versions 44 and 45. I'm currently using 43.0.4 where the problem does not occur. In about:support i see this: (#0) Error Too many dropped/corrupted frames, disabling DXVA (#1) Error Too many dropped/corrupted frames, disabling DXVA
(In reply to giovanninolol from comment #30) > I have the problem of dropped frames with Firefox versions 44 and 45. > I'm currently using 43.0.4 where the problem does not occur. Try nightly 48.
Comment 32•8 years ago
|
||
The 47.0 version seems to have solved the problem in my case.
You need to log in
before you can comment on or make changes to this bug.
Description
•