Firefox 47 Supports Hardware H264 Decoding = No; Failed to create H264 decoder Firefox 46 Supports Hardware H264 Decoding = Yes [Tracking Requested - why for this release]: Regression

Regression window (mozilla-central) Good: https://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64/1456954764/ Bad: https://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64/1456955964/ Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ae5567d429b03861360bde907d0203b2f1228597&tochange=77043e528b0bfd3fbb272ffd398381d811b8908f Probably caused by: 90f70787de03 Gerald Squelart — Bug 1242343 - p2. Blacklist msmpeg2vdec.dll 12.0.9200.16426 & .17037 - r=cpearce

Graphic section from about:support Adapter Description NVIDIA GeForce GTX 750 Ti Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM 2048 Asynchronous Pan/Zoom none Device ID 0x1380 Direct2D Enabled true DirectWrite Enabled true (6.2.9200.17568) Driver Date 2-23-2016 Driver Version 10.18.13.6200 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 36811458 Supports Hardware H264 Decoding No; Failed to create H264 decoder Vendor ID 0x10de windowLayerManagerRemote true AzureCanvasAccelerated 0 AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo

It would make perfect sense, if you have one of the blacklisted DLLs (see bug 1242343). Could you please have a look at your msmpeg2vdec.dll (it should be in c:\Windows\System32), right-click -> Properties -> 'Details' tab -> File version. If it is 12.0.9200.16426 or 12.0.9200.17037, congratulations, you've exercized bug 1242343! If not, please let us know, it would mean there is something wrong with the patch. As per bug 1242343, we have decided to blacklist these DLL versions because they were showing up in many crashes, with no particular reason to crash. And later versions are available, which do not exhibit these crashes. I've got 12.0.10547.1000 on my system. If you do have one of the blacklisted DLL versions, please try a Windows Update, and/or display driver update. Please let us know how it goes.

Yes, my version of msmpeg2vdec.dll is 12.0.9200.17037 and I didn't have any crashes related to it in the past. I'm using Windows 7 (64bit) with Service Pack 1 and with all latest patches available on Windows Update. GPU drivers are also latest (362.00). Firefox Nightly 47.0a1 (2016-03-03) is 64bit. So is this means that there will be no more video hardware acceleration in Firefox?

Thank you for the report and details so far, I'll look into this in the next few days. I'll contact you if I need more information from you...

I want to add that for some amount of movies on YouTube and other websites, I'm no longer able to watch them without Flash in HTML5 A/V mode. Flash is set "Ask to Activate". It's also big performance hit for high-definition videos.

Please revert the changes that caused this, now HTML5 videos don't play on Youtube or has high CPU usage for HD videos, killing battery life on notebooks running Windows 7 SP1, there's no newer msmpeg2vdec.dll than 12.0.9200.17037 on Win7 SP1. Please don't ask to use OpenH264 from Cisco that's included in Nightly because there's no hardware decoding support or Adobe Flash plugin, that thing is extremely buggy and a massive security risk.

Next thing I want to add that "media.hardware-video-decoding.force-enabled" set to "true" isn't working at all and properly, as it didn't bypasses the blacklist and it didn't forcing hardware acceleration in this case. Should I report a new bug about it? (In reply to NVD from comment #7) > Please don't ask to use OpenH264 from Cisco that's included in Nightly > because there's no hardware decoding support OpenH264 is only used for WebRTC as far I remember properly. I would also like real fix, not workaround blacklisting, as these crashes are somethings regression looking on crashes stats.

(In reply to Gerald Squelart [:gerald] from comment #3) > As per bug 1242343, we have decided to blacklist these DLL versions because > they were showing up in many crashes, with no particular reason to crash. > And later versions are available, which do not exhibit these crashes. I've > got 12.0.10547.1000 on my system. > > If you do have one of the blacklisted DLL versions, please try a Windows > Update, and/or display driver update. Please let us know how it goes. There are no such crashes using this file with Firefox 44 or 45, which indicates your code is the problem rather then the Microsoft decoder. Blacklisting files that have otherwise worked for months is poor form and a lazy resolution.

simple backout of patch from bug 1242343

(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #8) > Next thing I want to add that "media.hardware-video-decoding.force-enabled" > set to "true" isn't working at all and properly, as it didn't bypasses the > blacklist and it didn't forcing hardware acceleration in this case. > Should I report a new bug about it? FYI - I reported it here - Bug #1253923

Some data from the crash reports in the last 28 days: - @0x25a487: 42 reports, all with msmpeg2vdec.dll version 12.0.9200.16426, win7-64-sp1, affecting FF 42.0a1, 43.0a1, 43.0.4, 45.0a1, 46.0a1, 47.0a1. - @0x1230b2: 446 reports, all with msmpeg2vdec.dll version 12.0.9200.17037, win7-64-sp1, affecting FF 42.0, 42.0a1, 42.0a2, 42.0b1, 42.0b2, 42.0b3, 42.0b4, 42.0b5, 42.0b6, 42.0b7, 42.0b8, 42.0b9, 42.0b99, 43.0a1, 43.0a2, 44.0a1, 47.0a1. - @0x17229d: 2 reports, all with msmpeg2vdec.dll version 12.0.9200.17037, win7-64-sp1, affecting FF 47.0a1. So we have lots of crashes from these two DLL versions, all affecting win7-64-sp1 users with FF from 42 to 47. Reports shed little light as to what combination of factors induce these crashes. Unless a developer we can reproduce a crash locally, a "lazy" solution is unfortunately the best at the moment, crashes should be avoided, at the price of lower performance in other situations. Of course this regression for people who didn't experience crashes is not ideal, and we will work on this to get to a better solution that will hopefully please everybody. Just like I don't want to reject the bad experience reported by 3 people here (so far), I cannot reject bad/worse experience that crash reports indicate happen to many other people now.

Interestingly, there are no crashes in plain FF 44 (the current release), but there are in 44a. This could be due to e10s being enabled by default in the alpha channel (thanks cpearce for the suggestion). Something to investigate...

Tracking this regression with assignee

(In reply to Gerald Squelart [:gerald] from comment #12) > at the price of lower performance in other situations. The point is that this patch blocked completely decoding of H264 video in Firefox.

(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #15) > Created attachment 8727299 [details] > no support for H264.png > > (In reply to Gerald Squelart [:gerald] from comment #12) > > at the price of lower performance in other situations. > The point is that this patch blocked completely decoding of H264 video in > Firefox. We will keep looking for a fix, and uplift it. In the meantime, you should by default automatically get decoding of H.264/AAC/MP4 using the Adobe Primetime plugin in Firefox 46 and later. If you're not seeing MP4 playback working, then must have disabled that. You can re-enable the Adobe Primetime plugin in about:addons > Plugins, and ensure that "Play DRM Content" is enabled in about:preferences#content.

Gerald: Athony pointed out that Matt Woodrow enabled DXVA via D3D11 about 10 days ago. Did that affect the crash rates of the original crash? Before this we used DXVA via D3D9, so it may be that taking the D3D11 path doesn't tickle the bug that caused this original problem.

Gerald: Turns out we've blacklisted the most up to date version of msmpeg2vdec on Win64, so we should back this out and try again. Sorry, I should have realised this when you proposed backing out during the weekend.

Disable the blacklisting introduced in bug 1242343, as it was having a negative effect on many working configurations. Review commit: https://reviewboard.mozilla.org/r/38523/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/38523/

Comment on attachment 8727156 [details] [diff] [review] backout of patch from bug 1242343.patch Thank you very much for submitting this patch. It doesn't quite conform to our format (missing check-in comment), and since it's a bit urgent I've just rewritten a quick patch and I'm marking this one as obsolete.

Comment on attachment 8727591 [details] MozReview Request: Bug 1253395 - Disable msmpeg2vdec.dll blackslisting - r?cpearce https://reviewboard.mozilla.org/r/38523/#review35227

Comment on attachment 8727591 [details] MozReview Request: Bug 1253395 - Disable msmpeg2vdec.dll blackslisting - r?cpearce Approval Request Comment [Feature/regressing bug #]: Bug 1242343 [User impact if declined]: No H.264 decoding on win7-64 [Describe test coverage new/current, TreeHerder]: Going back to known working state, try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=eb82bafef38b [Risks and why]: None that I can see, as this patch just disables the regressing code that was added in bug 1242343 [String/UUID change made/needed]: None

about:support "Supports Hardware H264 Decoding: No; Hardware video decoding disabled or blacklisted" Still doesn't work despite running the latest Nightly hourly builds with the blacklist reverted.

Nevermind, media.hardware-video-decoding.failed was the cause of that, needed to reset it in about:config. "Supports Hardware H264 Decoding Yes" Works now.

I am a bit concerned about this uplift as we originally noticed crashes and our fix was to block this dll in bug 1242343. Will this fix worsen the stability situation? Gerald pointed out that the crash signatures from that bug have not occurred in recent weeks (which I also confirmed) so that is reassuring.

In the worst case we'd just go back to the way things were before bug 1242343, meaning some crashes per day, but millions of win7-64 users being able to play H.264, which I think is more important at this time. Also, as you've noticed, it seems this issue has recently lessened, for reasons yet-unknown. In any case I will keep monitoring the situation (in bug 1254389), and if needed will work on a better solution. So I really think this patch here should be uplifted as soon as possible to lessen the unwanted impact of bug 1242343.

Comment on attachment 8727591 [details] MozReview Request: Bug 1253395 - Disable msmpeg2vdec.dll blackslisting - r?cpearce The fix has been verified and we really do not want to stop using H264 on win7 x64. Taking it in Aurora47.

Tracking belatedly for 48, already fixed in 47 and 48.

I've the same problem too on XP because currently this codification it is supported only by drd11. Is it possible to match both drd9 and drd11 so to make FF more versatile ? To play h264 videos I've to use a chromium derivative. What will happen with 48 ff release? thanks

Hem... Can I ask WHY my GPU is blacklisted once again? And by once again, I mean that now firefox even adds the version of the DLL to block... (atiumd64.dll v7.14.10.903, to be more specific). This is kinda tiresome... I have to override new stuff everytime I update FF... and now I had to remove my DLL from the blacklist manually... I'm sorry, but my GPU is CLEARLY cappable of running hardware accelerated H264 videos, I never had any crashes, as the code changes from Nightly say. Would you be so kind to remove that blacklist adittion? Well, unless there are many other people having problems, using this exact driver, in this exact Radeon HD 3200 card (256 MB)... At least, don't add more stuff to prevent poeple that knows what they do, to override the blacklist... Chrome doesn't make it that hard to do... I'm still amazed that IE11, an ancient piece of ****, is able to handle hardware ccelerated videos without blacklisting anyone... But well, they know their own tricks, while you struggle with DX API (OpenGL anyone?). I hope I can still use FF to watch videos...

(In reply to ferline2000mx from comment #34) > Hem... Can I ask WHY my GPU is blacklisted once again? And by once again, I > mean that now firefox even adds the version of the DLL to block... > (atiumd64.dll v7.14.10.903, to be more specific). This bug is about removing some blacklisting, so your comment doesn't make sense here. I'm guessing you are referring to bug 1265281, which blacklisted atiumd64 7.14.10.903 and others, due to hundreds of crash reports -- while we are still working on other better solutions if possible. If you haven't experienced this issue, feel free to clear 'media.wmf.disable-d3d9-for-dlls' in about:config to re-enable your driver.

(In reply to Gerald Squelart [:gerald] from comment #35) > (In reply to ferline2000mx from comment #34) > > Hem... Can I ask WHY my GPU is blacklisted once again? And by once again, I > > mean that now firefox even adds the version of the DLL to block... > > (atiumd64.dll v7.14.10.903, to be more specific). > > This bug is about removing some blacklisting, so your comment doesn't make > sense here. > > I'm guessing you are referring to bug 1265281, which blacklisted atiumd64 > 7.14.10.903 and others, due to hundreds of crash reports -- while we are > still working on other better solutions if possible. > If you haven't experienced this issue, feel free to clear > 'media.wmf.disable-d3d9-for-dlls' in about:config to re-enable your driver. It's funny, I've read the bug, seems there are crashes... but not in my case, Firefox runs smooth and video playback is even better than it was in previous releases prior to 47... (less prone to revert to software decoding). In fact, I did change that key in Firefox to get DXVA back to working properly using user.js. Honestly, I think this is much of a hasle for you, I feel OpenGL would be a better and faster option for you to decode videos (well, in case I'm missing something and OpenGL cannot be used to decode H264 videos...). Ever since Firefox is hardware accelerated, we are experiencing problems regarding this feature and DirectX, and well, I cannot say it's entirely Mozilla's fault, as Windows is a closed source ecosystem, and "shortcuts" may be hidden only for them to fix expected issues. Anyway... probably is a good time to see if OpenGL is a good alternative to Microsoft's stuff? OpenGL is sometimes even faster than DirectX... Thanks for your answer :D