Open Bug 1418748 Opened 7 years ago Updated 2 years ago

Playing certain types of videos crashes graphic driver after upgrading to FF 57

Categories

(Core :: Audio/Video: Playback, enhancement, P2)

57 Branch
x86_64
Windows 8.1
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: TheDcoder, Unassigned)

Details

Attachments

(5 files)

I would like to apologize in advance for my way of writing this bug report, I am not really sure if it is really the place to report this. Moving on to the actual description of the bug.

Certain types of videos glitch while playing and the graphic driver also crashes occasionally. It is not a hard crash, windows will show (screenshot attached) a tray notification that the driver has crashed and windows has successfully recovered it. Firefox shows no errors and the video will go blank or display a solid colour like green, nothing else is effected.

I say certain type of videos because I have only had this issue while I was browsing Imgur. (relevant media attached)
The image isn't taken by me but it is very identical. My notification shows "Windows 8.1" instead of "Windows 8"
Attached file System Information
This report was generated by Intel HD Graphics's control panel
Component: General → Audio/Video: Playback
Product: Firefox → Core
Try setting media.wmf.dxva.d3d11.enabled to false and see if it improves thing...
(In reply to Jean-Yves Avenard [:jya] from comment #5)
> Try setting media.wmf.dxva.d3d11.enabled to false

I just added a setting called "media.wmf.dxva.d3d11.enabled" as a boolean in "about:config", set it to false and finally restart Firefox. Didn't improve the playback :-/
My bad, with 57 you need to use media.windows-media-foundation.allow-d3d11-dxva
Miraculous! I toggled the setting and restarted Firefox, the video rendered like a charm! I played the video multiple times to make sure. Can anyone explain this? :)
Bug in the drivers that don't properly handle d3d11 hardware decoder.
We will add it to our blacklist (there's a rather long list of blacklisted Intel drivers already)

https://searchfox.org/mozilla-central/rev/c9214daa09e3eb8246b1448e469df1652a140825/modules/libpref/init/all.js#376

:bwu, can we add this driver version to the d3d11 decoder blacklist?
Flags: needinfo?(bwu)
You may try to upgrade your drivers as well. D3d11 decoder allows for much higher decoding rate as painting the decoded image can be more efficiently drawn by our code.
Thanks for the explanation. I have the latest drivers from my laptop's manufacturer and Windows keeps it up to date with Intel.
(In reply to Jean-Yves Avenard [:jya] from comment #9)
> Bug in the drivers that don't properly handle d3d11 hardware decoder.
> We will add it to our blacklist (there's a rather long list of blacklisted
> Intel drivers already)
> 
> https://searchfox.org/mozilla-central/rev/
> c9214daa09e3eb8246b1448e469df1652a140825/modules/libpref/init/all.js#376
> 
> :bwu, can we add this driver version to the d3d11 decoder blacklist?
Yes. We can. 
But I am not quite sure we should block this since our recovery mechanism should work well, which means it should fall back to SW decoder after a crash and users still can continue their watching. IIRC, next time when users restart Firefox, HW decoder will be used again and if it does not cause crash, users could have a better performance with powerful HW.
Flags: needinfo?(bwu)
From my personal experience, the graphic driver crashed multiple times when I was browsing imgur, does that mean the fall back mechanism is not working?
Ah. I think I misunderstood. It is Windows crashed, not Firefox..
Yes, Firefox didn't detect it at all, I have attached an image of what Windows shows after recovering from crash.
(In reply to Damon from comment #15)
> Yes, Firefox didn't detect it at all, I have attached an image of what
> Windows shows after recovering from crash.
Got it. Thanks!
We should check why Firefox didn't detect that. I would like to prefer fallback mechanism over blocking it since users would not be able to enjoy their powerful HW anymore.
(In reply to Blake Wu [:bwu][:blakewu] from comment #12)
> (In reply to Jean-Yves Avenard [:jya] from comment #9)
> > Bug in the drivers that don't properly handle d3d11 hardware decoder.
> > We will add it to our blacklist (there's a rather long list of blacklisted
> > Intel drivers already)
> > 
> > https://searchfox.org/mozilla-central/rev/
> > c9214daa09e3eb8246b1448e469df1652a140825/modules/libpref/init/all.js#376
> > 
> > :bwu, can we add this driver version to the d3d11 decoder blacklist?
> Yes. We can. 
> But I am not quite sure we should block this since our recovery mechanism
> should work well, which means it should fall back to SW decoder after a
> crash and users still can continue their watching. IIRC, next time when
> users restart Firefox, HW decoder will be used again and if it does not
> cause crash, users could have a better performance with powerful HW.

The aim of the GPU process is to recover when *we* crash.
Not recover when Windows drivers themselves crash. Firefox isn't crashing here. There's nothing to recover from.

The only way to prevent the drivers from restarting is disabling the d3d11 HW decoder.
We finally removed the blacklist on 57.. I don't want to have it back unless we really have to..
Peter, 
Do you know if there is anything we can do to detect this windwos crash?
Flags: needinfo?(howareyou322)
(In reply to Blake Wu [:bwu][:blakewu] from comment #16)
> (In reply to Damon from comment #15)
> > Yes, Firefox didn't detect it at all, I have attached an image of what
> > Windows shows after recovering from crash.
> Got it. Thanks!
> We should check why Firefox didn't detect that. I would like to prefer
> fallback mechanism over blocking it since users would not be able to enjoy
> their powerful HW anymore.

It seems to me that you are confused about the use of the d3d11 dxva blacklist and what it's there for.

There's nothing to fall-back from. Windows crashes, not Firefox.

How old Intel drivers fail or crashes when using the d3d11 decoder vary a lot.
At the end of the day, they were developed for working with d3d9 at a time d3d11 didn't even exist.

Now maybe we could detect that a specific driver restart was due to the use of the d3d11 decoder, but that would be a very hard thing to do.

We've taken the decision a long time ago that we wouldn't worry about those old drivers, the benefits are too small compare to the magnitude of the task to detect those problems.
Blacklisting is easier, those drivers and graphic cards will eventually disappear over time.
I agree that blacklist would be better and easier instead of making a new mechanism which will detect Windows driver crashes.
(In reply to Blake Wu [:bwu][:blakewu] from comment #19)
> Peter, 
> Do you know if there is anything we can do to detect this windwos crash?

We probably had some gfx error log, but it didn't send out if there was no crash.
For windows crashes, there is nothing we can do.

(In reply to Jean-Yves Avenard [:jya] from comment #20)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #16)
> > (In reply to Damon from comment #15)
> > > Yes, Firefox didn't detect it at all, I have attached an image of what
> > > Windows shows after recovering from crash.
> > Got it. Thanks!
> > We should check why Firefox didn't detect that. I would like to prefer
> > fallback mechanism over blocking it since users would not be able to enjoy
> > their powerful HW anymore.
> 
> It seems to me that you are confused about the use of the d3d11 dxva
> blacklist and what it's there for.
> 
> There's nothing to fall-back from. Windows crashes, not Firefox.
> 
> How old Intel drivers fail or crashes when using the d3d11 decoder vary a
> lot.
> At the end of the day, they were developed for working with d3d9 at a time
> d3d11 didn't even exist.
> 
> Now maybe we could detect that a specific driver restart was due to the use
> of the d3d11 decoder, but that would be a very hard thing to do.
> 
> We've taken the decision a long time ago that we wouldn't worry about those
> old drivers, the benefits are too small compare to the magnitude of the task
> to detect those problems.
> Blacklisting is easier, those drivers and graphic cards will eventually
> disappear over time.

I think GPU process will help for some unexpected crashes from gfx or media side.
But for these consistent crashes because of some drivers/graphic cards, users will always switch to SW backend if they watch the video. I think we also need to address this issue.
Flags: needinfo?(howareyou322)
Hi Damon,
Do you start to see this problem when upgrading old Firefox version to Firefox 57? You didn't see this crash on old Firefox version?
After jya explained my confusion about different blacklists via irc, I agree blacklisting it would be easier and quicker. Just still wonder why users start to see this problem from 57 if users didn't see this problem on the old Firefox version.
That is correct Blake, I didn't have this problem in Firefox 56... It could have been that something changed the way Firefox requests the hardware decoder to render it that might be triggering the glitch/bug. Or maybe it was a really bad coincidence that Imgur started using that specific type of video *just* after I upgraded to 57.
By any chance can you help try to use Firefox 56 to see if you can see the same problem with the same environment? Have you done some windows update recently?
I am wondering if there is something changed in 57 to cause this problem.
I downloaded the portable version of Firefox 56.0.2 (which I believe what I was using before the upgrade) from here: https://sourceforge.net/projects/portableapps/files/Mozilla%20Firefox%2C%20Portable%20Ed./Mozilla%20Firefox%2C%20Portable%20Edition%2056.0.2/FirefoxPortable_56.0.2_EnglishGB.paf.exe/download

I hope that is okay. I couldn't find the `media.wmf.dxva.d3d11.enabled` setting in `about:config` so I didn't touch the default configuration and the video rendered fine.

I tried this on the same computer, the only difference is that I used Firefox portable version this time. I did not do any windows update recently.
Damon,
Thanks for your help. 

Peter, 
Since it looks like 56 can work well but 57 cannot, my guess is some thing changed in 57 causes display driver hang (comment 1) and Windows decides to restart it? 
Do you know what can we do to debug this bug further? Any kind of logs could be helpful?
Flags: needinfo?(howareyou322)
My pleasure Blake.

I would like to clarify something that I just noticed, in my attachment of the Windows Tray Notification, it says "the driver has stopped responding", but my recollection is that it said "the driver has crashed"... but I am not too sure about that, just wanted to let you guys know.
Blake, as I mentioned in comment 22, I'm afraid that we don't have too much to do if there is a crash from windows in gfx side.

Damon, there is event viewer app on windows system. You can use the windows+R keys and then type 'eventvwr'.
You can find some related logs from windows Logs\Application(related to Firefox) or WindowsLogs\System(related to display driver) at the timestamp when issues happen.
Flags: needinfo?(howareyou322)
I cannot find anything related to the driver crash in the Event Viewer, I have checked all of the events on that day multiple times now.
Very strange, after updating to Firefox 58 this bug has appeared again.

I can confirm that `media.windows-media-foundation.allow-d3d11-dxva` is still set to `false` :-/

I make it for my blog at this address. check this so
https://spy24.app/
thanks

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: