Black frames on Youtube 1080@60fps with AMD graphics card

VERIFIED FIXED in Firefox 36

Status

()

P1
normal
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: theittol, Assigned: mattwoodrow)

Tracking

(Blocks: 1 bug)

36 Branch
mozilla38
x86_64
Windows 8.1
Points:
---
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox36 verified, firefox37 verified, firefox38 verified)

Details

(Whiteboard: [youtubetest])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150110004004

Steps to reproduce:

I am running Windows 8.1. I have AMD HD 5850 graphics card and I am using drivers of version 14.12 AMD Catalyst Omega Software (latest stable).

I am watching videos on Youtube using the HTML5 player and video setting 1080@60fps

Example: https://www.youtube.com/watch?v=7SRTEXSpcyI

Using IE to watch the same video works fine.


Actual results:

Video has a lot of black frames and some stuttering.


Expected results:

No black frames or stuttering
(Reporter)

Updated

4 years ago
Blocks: 778617
Whiteboard: [youtubetest]

Updated

4 years ago
Component: Untriaged → Video/Audio
Product: Firefox → Core
Tuomas, could you attach the graphics section from about:support?
Flags: needinfo?(theittol)
(Reporter)

Comment 2

4 years ago
Posted image aboutsupport_graphics.png (obsolete) —
Flags: needinfo?(theittol)
(Reporter)

Comment 3

4 years ago
I accidentally attached the info from FF34. This one is from FF36
Attachment #8548252 - Attachment is obsolete: true
David, let's see if this is the same cause as bug 1112331...
Flags: needinfo?(dvander)
(In reply to Tuomas Heittola from comment #0)

Tuomas, if you go to about:config and set "layers.d3d11.disable-warp" to true, does the problem persist?

If it does, could you also try "layers.acceleration.disabled" set to true?
Flags: needinfo?(dvander)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(theittol)
(Reporter)

Comment 6

4 years ago
(In reply to David Anderson [:dvander] from comment #5)
> "layers.d3d11.disable-warp" to true
Problem still persists with this setting

> "layers.acceleration.disabled" set to true?
With this setting the video plays fine. No black frames or stuttering.
Flags: needinfo?(theittol)
Is there a driver upgrade available for this card? If that fixed it we could disable acceleration for this particular version.
Flags: needinfo?(theittol)
(Assignee)

Comment 8

4 years ago
This user doesn't have blacklisted drivers, so won't be using WARP.

Unfortunately we don't (currently) have a way to blacklist only DXVA, so we might need to blacklist layers for this driver, especially for beta.
(Assignee)

Comment 9

4 years ago
Does setting media.windows-media-foundation.use-dxva=false fix the issue?
Catalyst Omega 14.12, is still the latest driver release for this card. (published 2014 December 8)

Could try downgrading, I guess? Milan, what do you think about Matt's layers disable suggestion?
(Reporter)

Comment 11

4 years ago
(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
> Does setting media.windows-media-foundation.use-dxva=false fix the issue?

This makes the video play fine.
Flags: needinfo?(theittol)
Flags: needinfo?(milan)
We don't really have the data if it's just this driver or a range or all of them on this card, right? It's a pretty big hammer, especially if this is the "only" (not that it's not a big one) problem.  I can see us doing this as a temporary solution, but what are the chances of adding DXVA blacklisting, and in what kind of timeframe would we be able to get that?

Including Bas, just in case this is fixed with some of the more recent work, or he has an idea as to whether there is a fix we can deploy on our side.  Not to mention the opinion on the blacklisting approach.
Flags: needinfo?(milan) → needinfo?(bas)
Right. This would be a regression if we ship MSE for YouTube, which we're planning to do in 36, so there's not much time. Of course 37 or 38 is still better than nothing.

But as you say, we have no data about how common this issue is.
(Assignee)

Comment 14

4 years ago
(In reply to Milan Sreckovic [:milan] from comment #12)
> We don't really have the data if it's just this driver or a range or all of
> them on this card, right? It's a pretty big hammer, especially if this is
> the "only" (not that it's not a big one) problem.  I can see us doing this
> as a temporary solution, but what are the chances of adding DXVA
> blacklisting, and in what kind of timeframe would we be able to get that?
> 
> Including Bas, just in case this is fixed with some of the more recent work,
> or he has an idea as to whether there is a fix we can deploy on our side. 
> Not to mention the opinion on the blacklisting approach.

I totally agree, especially since this is the latest stable driver.

Can we get QA to test a bunch of different driver version on this (and similar) hardware, to try narrow down a more precise range?

Adding code to blacklist DXVA in time to uplift to beta sounds scary, though it's probably something we should start working on to ride the trains.
(Assignee)

Comment 15

4 years ago
Who knows the blacklist code the best? I really have no idea how the downloadable part works, and I think we'll want that in case new issues appear on release.

I'm happy to do the work here if someone can point me to what needs to be done.
(Assignee)

Updated

4 years ago
Flags: needinfo?(milan)
I feel like this bug is evidence that we'll sadly need to add DXVA blacklisting.
Flags: needinfo?(bas)
(Assignee)

Comment 17

4 years ago
It appears that we can't actually use the downloadable blacklist for new features because of a bug in the original implementation.

We'll have to hardcode the drivers/devices to blacklist instead.

This patch blacklists DXVA for the given device, regardless of driver/OS version. If we can get more precise data on which drivers are affected we might be able to relax this.

Link to build for testing: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-6b378741c668/try-win32/
Assignee: nobody → matt.woodrow
(Reporter)

Comment 18

4 years ago
(In reply to Matt Woodrow (:mattwoodrow) from comment #17)
> Link to build for testing:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.
> com-6b378741c668/try-win32/
On this build the video works fine for me.
Comment on attachment 8554359 [details] [diff] [review]
Add blacklist for DXVA

This is a "large-ish" patch, but it I'd be comfortable recommending for uplift, as I don't see much of a risk in breaking existing functionality.  Once reviewed, let's ask for uplifts...
Flags: needinfo?(milan)
Attachment #8554359 - Flags: review?(bas)
Comment on attachment 8554359 [details] [diff] [review]
Add blacklist for DXVA

Review of attachment 8554359 [details] [diff] [review]:
-----------------------------------------------------------------

I don't know the blacklisted code that well. But this seems like it should be ok.
Attachment #8554359 - Flags: review?(bas) → review+
Comment on attachment 8554359 [details] [diff] [review]
Add blacklist for DXVA

Review of attachment 8554359 [details] [diff] [review]:
-----------------------------------------------------------------

I don't know the blacklisted code that well. But this seems like it should be ok.

::: gfx/thebes/gfxPlatform.cpp
@@ +2163,5 @@
>   * not have any effect until we restart.
>   */
>  static bool sLayersSupportsD3D9 = false;
>  static bool sLayersSupportsD3D11 = false;
> +static bool sLayersSupportsDXVA = false;

Can you make these 3 into members of the Singleton for the purposes of consistency?
(Assignee)

Comment 22

4 years ago
(In reply to Bas Schouten (:bas.schouten) from comment #21)

> 
> Can you make these 3 into members of the Singleton for the purposes of
> consistency?

Consistency with what? gfxPlatform doesn't have any other static data members, and we don't have access to the global gfxPlatform object at the time we initialize these values.
(Assignee)

Comment 24

4 years ago
(In reply to Tuomas Heittola from comment #18)
> (In reply to Matt Woodrow (:mattwoodrow) from comment #17)
> > Link to build for testing:
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.
> > com-6b378741c668/try-win32/
> On this build the video works fine for me.

Thanks for testing that!
(Assignee)

Comment 25

4 years ago
[Tracking Requested - why for this release]:
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
Looks like this was backed out without updating the bug. Build bustage.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ef01cebd1e07

Matt, it looks like you accidentally pushed a bunch of ResourceQueue changes when landing this patch.
Flags: needinfo?(matt.woodrow)
https://hg.mozilla.org/mozilla-central/rev/e097183cab30
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
status-firefox38: affected → fixed
Comment on attachment 8554359 [details] [diff] [review]
Add blacklist for DXVA

Approval Request Comment
[Feature/regressing bug #]: MSE
[User impact if declined]: Users with particular hardware will be unable to play youtube videos.
[Describe test coverage new/current, TreeHerder]: Landed on m-c.
[Risks and why]: Risk is lowish. The graphics changes are low risk, just adding another checkbox to the block list. Windows mp4 playback on matching systems will be forced to use software decoding, MSE or not, but that's confirmed to work.
[String/UUID change made/needed]: None.
Attachment #8554359 - Flags: approval-mozilla-beta?
Attachment #8554359 - Flags: approval-mozilla-aurora?

Comment 30

4 years ago
(In reply to Bas Schouten (:bas.schouten) from comment #16)
> I feel like this bug is evidence that we'll sadly need to add DXVA
> blacklisting.

IE uses DXVA too right? Then why doesn't it also have this issue on the same system?
Attachment #8554359 - Flags: approval-mozilla-beta?
Attachment #8554359 - Flags: approval-mozilla-beta+
Attachment #8554359 - Flags: approval-mozilla-aurora?
Attachment #8554359 - Flags: approval-mozilla-aurora+
Backport patch to beta branch, which doesn't have the WARP checking.
Attachment #8556643 - Flags: feedback?(matt.woodrow)
(Assignee)

Updated

4 years ago
Attachment #8556643 - Flags: feedback?(matt.woodrow) → feedback+
(In reply to Ralph Giles (:rillian) from comment #29)
> [String/UUID change made/needed]: None.

Umm, widget/nsIGfxInfo.idl says otherwise. And we changed an interface without revving the UUID?!
Flags: needinfo?(matt.woodrow)
I missed that this patch changed an idl file without changing the uuid, so we need to update that as well. Proposing for all branches, but Ryan tells me we need special ba+ because of the uuid change.

Approval Request Comment
[Feature/regressing bug #]: MSE
[User impact if declined]: As above, but abi compatibility issues.
[Describe test coverage new/current, TreeHerder]: Works locally. Fixed by clobber on m-i?
[Risks and why]: Low, I think. Add-ons could need updating?
[String/UUID change made/needed]: UUID changed on nsIGfxInfo.
Attachment #8556704 - Flags: review?(matt.woodrow)
Attachment #8556704 - Flags: approval-mozilla-beta?
(Assignee)

Updated

4 years ago
Attachment #8556704 - Flags: review?(matt.woodrow) → review+
(Assignee)

Updated

4 years ago
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 35

4 years ago
(In reply to Ralph Giles (:rillian) from comment #34)

> Approval Request Comment
> [Feature/regressing bug #]: MSE
> [User impact if declined]: As above, but abi compatibility issues.
> [Describe test coverage new/current, TreeHerder]: Works locally. Fixed by
> clobber on m-i?
> [Risks and why]: Low, I think. Add-ons could need updating?
> [String/UUID change made/needed]: UUID changed on nsIGfxInfo.

It shouldn't cause any compatibility issues since it's just adding a new constant. It's an entirely backwards compatible change.
Comment on attachment 8556704 [details] [diff] [review]
Update nsIGfxInfo uuid

You shouldn't bump the IID for constant additions, they have no ABI impact. Certainly not on beta.

If for some reason the build system doesn't like it you should use CLOBBER.
Attachment #8556704 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
I think that happened when we landed on m-c, but I can't push to beta, because there's a checkin hook. Should I put ba=gavin on the original patch, without changing the uuid?
Flags: needinfo?(gavin.sharp)
Assuming "original patch" means attachment 8556643 [details] [diff] [review], yes, you can land that on beta with ba=me.

(I can't read bugmail for the next few hours, best to email directly if something comes up.)
Flags: needinfo?(gavin.sharp)
Thanks Gavin, Ryan.
Flags: qe-verify+
Reproduced the initial issue using a AMD Radeon HD6450 card on a old Nightly build before the fix but I still see the bad behaviour (black screen frames) on latest Nightly, Aurora, 36 beta 7.

Setting media.windows-media-foundation.use-dxva=false fixes the issue.

Graphics
Adapter Description	AMD Radeon HD 6450
Adapter Drivers	aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM	1024
Device ID	0x6779
Direct2D Enabled	true
DirectWrite Enabled	true (6.3.9600.17111)
Driver Date	11-20-2014
Driver Version	14.501.1003.0
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	21251462
Vendor ID	0x1002
WebGL Renderer	Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Catalyst Version: 14.12 AMD Catalyst Omega Software

Does this fix only apply to AMD Radeon HD5800? Should I log a new bug about this?
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 43

4 years ago
Yes, please file a new bug for that. Sounds like we'll need to blacklist multiple AMD cards, we need to work out which ones are affected.
Flags: needinfo?(matt.woodrow)
(Reporter)

Comment 45

4 years ago
The video plays fine on all of them.

Except on the build 36 beta 8 media.mediasource.enabled was false by default. I had to change it to true before I was able to choose 1080@60.
Flags: needinfo?(theittol)
(In reply to Tuomas Heittola from comment #45)
> The video plays fine on all of them.
> 
> Except on the build 36 beta 8 media.mediasource.enabled was false by
> default. I had to change it to true before I was able to choose 1080@60.

Thanks Tuomas! I will go ahead and close this bug as verified fixed based on the comment from above.
Status: RESOLVED → VERIFIED
status-firefox36: fixed → verified
status-firefox37: fixed → verified
status-firefox38: fixed → verified
Do we still need to blacklist WARP with the new failure detection?
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 49

4 years ago
Yes. The failure detection catches (at least one type of) invalid textures. The WARP issue is that the compositor fails to draw with an otherwise perfectly valid texture.
Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.