YouTube 1080p/60 H.264 video massively drops frames

VERIFIED FIXED in Firefox 40

Status

()

--
major
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: lh.bennett, Assigned: mattwoodrow)

Tracking

(Blocks: 1 bug, {regression})

40 Branch
mozilla41
x86_64
Windows 8.1
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39 unaffected, firefox40+ verified, firefox41+ verified)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
Blocks: 778617
Does this still occur after restarting the browser?
(Reporter)

Comment 2

4 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

4 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

4 years ago
For what its worth, YouTube MSE WebM/VP9 playback does not seem to be affected by this issue.
[Tracking Requested - why for this release]: Regression
Blocks: 875247, 1083588
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.
tracking-firefox40: ? → +
tracking-firefox41: ? → +
(Assignee)

Comment 9

4 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)
(Reporter)

Comment 11

4 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.
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)
(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

4 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

4 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

4 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

4 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

4 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.
https://hg.mozilla.org/mozilla-central/rev/c80271e9f1c2
https://hg.mozilla.org/mozilla-central/rev/6c05b6375d9f
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Matt, can we have an uplift request to 40/aurora? thanks
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 25

4 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

4 years ago
Assignee: nobody → matt.woodrow
Comment on attachment 8621720 [details] [diff] [review]
Disable D3D11 DXVA

Improve the quality, taking it.
Attachment #8621720 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: qe-verify+
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
status-firefox40: fixed → verified
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).
Status: RESOLVED → VERIFIED
status-firefox41: fixed → verified
Flags: qe-verify+
(Assignee)

Updated

3 years ago
Blocks: 1248496

Comment 30

3 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

3 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.