No longer force enable HWA video decoding on legacy HD6450. Steps To Reproduce: 1. Set the following preferences media.hardware-video-decoding.force-enabled=true media.wmf.disable-d3d11-for-dlls="" media.wmf.disable-d3d9-for-dlls="" or media.hardware-video-decoding.force-enabled=true media.wmf.disable-d3d9-for-dlls="" 2. Observe about:support Actual Results: Hardware H264 Decoding : No; Hardware video decoding disabled or blacklisted Expected Results: Hardware H264 Decoding : Yes; Using D3D11 API OR Hardware H264 Decoding : Yes; D3D11 blacklisted with DLL atidxx32.dll (8.17.10.648); Using D3D9 API Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6cf09a35f5295baef0706f63a80c308abdfd4594&tochange=29f80f1769fc66ca5cc390183f3b49eec160ad4f Triggered by: Bug 1288618

[Tracking Requested - why for this release]:

It even breaks H264 decoding on supported GPUs.

What makes you think that HW decoding no longer works? you mean just that about:support says that it doesn't right? That doesn't mean HW decoding no longer works.

(In reply to Jean-Yves Avenard [:jya] from comment #3) > What makes you think that HW decoding no longer works? > you mean just that about:support says that it doesn't right? > > That doesn't mean HW decoding no longer works. At least for me, Prior landing Bug 1288618, overall CPU usage is less than 10% during playback a video. After landing Bug 1288618, overall CPU usage is almost full a core(25%) during playback a video. So, I think that HW decoding would not work even if force enabled it.

Steps To Reproduce: 1. Enable HW decorder 2. Open https://www.youtube.com/watch?v=1YnlX4CkPDY and playback with 720p 3. Observe CPU usage 4. about:media Actual Results: High CPU ** Prior landing Bug 1288618 ** overall CPU usage: 20-40% HTMLMediaElement debug data https://www.youtube.com/watch?v=1YnlX4CkPDY blob:https://www.youtube.com/c5c3652b-2e77-4552-8917-5590f5bcc8b9 currentTime: 7204.103187 Quality: 72% (total:499 dropped:139 corrupted:0) Buffered ranges: [(7196, 7208)] SourceBuffer 0 start=7196 end=7208.010666 SourceBuffer 1 start=7196 end=7208 Internal Data: audio decoder: wmf audio decoder audio frames decoded: 467 audio state: ni=0 no=0 ie=0 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:8 out:7 qs=1 pending:0 waiting:0 sid:13 video decoder: wmf hardware video decoder hardware video decoding: enabled video frames decoded: 486 (skipped:0) video state: ni=0 no=1 ie=1 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:19 out:6 qs=13 pending:0 waiting:0 sid:10 Dumping data for demuxer 14231980: Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 7206.176000 NumSamples:563 Size:290688 NextGetSampleIndex:477 NextInsertionIndex:563 Buffered: ranges=[(7196.000000, 7208.010666)] Dumping Video Track Buffer(video/avc) - mLastVideoTime: 7204.316666 NumSamples:720 Size:2511251 NextGetSampleIndex:499 NextInsertionIndex:720 Buffered: ranges=[(7196.000000, 7208.000000)] ** After landing Bug 1288618 ** overall CPU usage: aroud 60% HTMLMediaElement debug data https://www.youtube.com/watch?v=1YnlX4CkPDY blob:https://www.youtube.com/c1bc8b57-d8f2-4a83-a683-f0fd37d334bd currentTime: 7204.994645 Quality: 100% (total:614 dropped:0 corrupted:0) Buffered ranges: [(7198, 7214)] SourceBuffer 0 start=7196 end=7214 SourceBuffer 1 start=7198 end=7214 Internal Data: audio decoder: wmf audio decoder audio frames decoded: 690 audio state: ni=0 no=0 ie=0 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:52 out:51 qs=1 pending:0 waiting:0 sid:24 video decoder: wmf software video decoder hardware video decoding: disabled video frames decoded: 580 (skipped:0) video state: ni=0 no=0 ie=0 demuxr:0 demuxq:0 tt:-1.000000 tths:-1 in:92 out:75 qs=17 pending:0 waiting:0 sid:21 Dumping data for demuxer 227ea800: Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 7207.109333 NumSamples:843 Size:435578 NextGetSampleIndex:520 NextInsertionIndex:843 Buffered: ranges=[(7196.000000, 7214.000000)] Dumping Video Track Buffer(video/avc) - mLastVideoTime: 7205.533333 NumSamples:960 Size:6244123 NextGetSampleIndex:452 NextInsertionIndex:960 Buffered: ranges=[(7198.000000, 7214.000000)]

(In reply to Jean-Yves Avenard [:jya] from comment #3) > What makes you think that HW decoding no longer works? > you mean just that about:support says that it doesn't right? > > That doesn't mean HW decoding no longer works. Don't insult our intelligence, if we're reporting bugs we know how to determine whether our graphics processors VPU engine is in use or not.

(In reply to Danial Horton from comment #6) > Don't insult our intelligence, if we're reporting bugs we know how to > determine whether our graphics processors VPU engine is in use or not. Oh, I'm sorry, I had missed your previous report and contribution to this bug, oh wait... The reporter is using a blacklisted GPU. For him to get accelerated decoding he must set a preference. Following bug 1288618, where decoding is done in another process (so that when the graphic drivers crash, it won't crash the whole browser or tabs, but instead will be able to seamlessly recover) Reading the preferences in the new process doesn't work for now, which is why forcing the GPU decoding doesn't work. However, for people that do not have blacklisted drivers, it should still allow decoding. However that may not be showing in about:media or about:support, and that doesn't indicate in any ways that GPU decoding no longer works. Prior bug 1212323, about:support was always reporting the hardware H264 wasn't available on mac, we got dozens of bugs that GPU decoding wasn't working on mac, even though it did...

On a fresh profile* on Windows 10 x64 with the latest (2016-09-24) 64-bit Nightly, about:support also shows "No; Hardware video decoding disabled or blacklisted" for me. My GPU is a NVIDIA GeForce GTX 970 and I have the latest WHQL drivers (372.90). * with accessibility disabled in order to enable e10s

(In reply to Jean-Yves Avenard [:jya] from comment #7) > (In reply to Danial Horton from comment #6) > > Don't insult our intelligence, if we're reporting bugs we know how to > > determine whether our graphics processors VPU engine is in use or not. > > Oh, I'm sorry, I had missed your previous report and contribution to this > bug, oh wait... > > The reporter is using a blacklisted GPU. For him to get accelerated decoding > he must set a preference. Following bug 1288618, where decoding is done in > another process (so that when the graphic drivers crash, it won't crash the > whole browser or tabs, but instead will be able to seamlessly recover) > Reading the preferences in the new process doesn't work for now, which is > why forcing the GPU decoding doesn't work. > > However, for people that do not have blacklisted drivers, it should still > allow decoding. However that may not be showing in about:media or > about:support, and that doesn't indicate in any ways that GPU decoding no > longer works. > > Prior bug 1212323, about:support was always reporting the hardware H264 > wasn't available on mac, we got dozens of bugs that GPU decoding wasn't > working on mac, even though it did... Again, Don't insult our intelligence, we know how to check for usage of the VPU engine with available tools. Hardware Acceleration is not working after this bug on any device, whether supported or forced. Belittling users when they report issues seems to be the thing to do at mozilla these days, no wonder bugs go left unreported.

@Jean-Yves Avenard why so defensive? At the very least the message in about:support "Hardware video decoding disabled or blacklisted" is erroneous and should be fixed or at most HVD did get broken by a patch. I also have the issue on my AMD R390 with the latest AMD Crimson drivers. I haven't done extensive testing as Alice has done but I do notice my CPU usage is higher when watching videos and I also get some stuttering at times.

(In reply to Gary [:streetwolf] from comment #10) > @Jean-Yves Avenard why so defensive? At the very least the message in > about:support "Hardware video decoding disabled or blacklisted" is erroneous > and should be fixed or at most HVD did get broken by a patch. did I ever stated that there wasn't such problem? All I stated was that outcome B (about:support saying one thing) does not automatically imply cause A (GPU decoding is actually disabled). If someone wants to feel "insulted" because of this ... well, so be it.

There is no need to be upset, as it all started probably with simply misinterpretation.

gfxWindowsPlatform::CanUseHardwareVideoDecoding uses DeviceManagerDx, but we initialize the cached value in gfxPlatform::InitAcceleration, before DeviceManagerDx is initialized.

Danial, I manage the media playback team at Mozilla so I'm responsible for all Audio/Video:Playback bugs. I'm at a loss to understand why you feel that comment 3 was directed at you. My reading of it is that it was addressed to the reporter of the bug. Perhaps I'm missing some background. Why do you feel that it was directed at you? What relationship do you have to the reporter? I can also see that the question can have multiple interpretations. However the purpose of the question is to understand if it is a reporting issue or a HW acceleration issue. Often there is a significant amount of background assumed, especially with people who file a lot of bugs, such as Alice. I'm sorry if the communication between Jean-Yves and Alice was a little terse.

I took offence to the "What makes you think" opening of Jean-Yves comment, when put into context of the rest of his comment it seemed belittling and rude. Alice does a lot of work rooting out and identifying changes where issues were introduced and knows how to identify when something is clearly not working - not to mention he only posted this bug because it was brought up by multiple people using a range of graphics devices and device drivers. Anyone with an nvidia gpu for instance can monitor the activity of the VPU engine via NVAPI, when hardware decoding is actually functioning you will see activity on this engine. I might have taken Jean wrong, but i've seen other incidences from mozilla contributors and developers recently that smacks of arrogance.

> I might have taken Jean wrong, but i've seen other incidences from mozilla > contributors and developers recently that smacks of arrogance. Jean-Yves' reply in comment 3 was terse. I don't think it was intended to be aggressive, but I can see how it could be read that why, and I understand why you took offence. However, when he apologised and gave a more detailed explanation in comment 7, your response was to repeat your "Don't insult our intelligence" statement, which was not helpful. I'm sorry that you have had poor interactions with other Mozilla developers recently. We all want the same outcome here, which is to fix whatever problems are present in the code, so let's please try to do that together in a constructive fashion.

So was HVD actually broken by Bug 1288618 and not just a cosmetic problem with the message in about:support?

Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c33c1775fe24 Make sure the cached CanUseHardwareVideoDecoding value is updated when DeviceMangerDx is initialized. r=dvander

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/280175619413 for (at least) e10s marionette crashes like https://treeherder.mozilla.org/logviewer.html#?job_id=36501377&repo=mozilla-inbound I think, though it's not doing a very good job of saying what's failing, that this will also prove to be what's breaking make check on Windows, a la https://treeherder.mozilla.org/logviewer.html#?job_id=36492620&repo=mozilla-inbound, and e10s w-p-t, https://treeherder.mozilla.org/logviewer.html#?job_id=36501372&repo=mozilla-inbound

Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b82da770e632 Make sure the cached CanUseHardwareVideoDecoding value is updated when DeviceMangerDx is initialized. r=dvander

I'm running on the latest inbound, which should contain this patch, yet about:support still says "No; Hardware video decoding disabled or blacklisted". https://hg.mozilla.org/integration/mozilla-inbound/rev/d217f8dd78d65ae5c90d98fb7191879d12d9ff14

Per Comment 21 this patch is not working for me. I really doubt that I'm on a blocklist. Application Basics ------------------ Name: Firefox Version: 52.0a1 Build ID: 20160928033001 Update Channel: default User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 OS: Windows_NT 10.0 Multiprocess Windows: 1/1 (Enabled by user) Safe Mode: false Graphics -------- Features Compositing: Direct3D 11 Asynchronous Pan/Zoom: wheel input enabled; touch input enabled WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0) WebGL2 Renderer: Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding: No; Hardware video decoding disabled or blacklisted Audio Backend: wasapi Direct2D: true DirectWrite: true (10.0.14393.0) GPU #1 Active: Yes Description: AMD Radeon (TM) R9 390 Series Vendor ID: 0x1002 Device ID: 0x67b1 Driver Version: 21.19.137.1 Driver Date: 9-16-2016 Drivers: aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Subsys ID: 00000000 RAM: 8192 Diagnostics ClearType Parameters: DISPLAY1 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 0 Enhanced Contrast: 100 ] DISPLAY2 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 100 Enhanced Contrast: 100 ] AzureCanvasAccelerated: 0 AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo ClearType Parameters: DISPLAY1 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 0 Enhanced Contrast: 100 ] DISPLAY2 [ Gamma: 2.2 Pixel Structure: BGR ClearType Level: 100 Enhanced Contrast: 100 ]

Yep, nothing changed. High CPU usage. about:support and about:media also report that HW decading is disabled. https://hg.mozilla.org/integration/mozilla-inbound/rev/b82da770e632654ed0b001a1fa4e4986c8be4f74 Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 ID:20160927153519

(In reply to Gary [:streetwolf] from comment #23) > Per Comment 21 this patch is not working for me. I really doubt that I'm on > a blocklist. Same problem, Nightly 28-09-16. Here is about:support : Compositing Direct3D 11 Asynchronous Pan/Zoom wheel input enabled; touch input enabled WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D11 vs_4_1 ps_4_1) WebGL2 Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D11 vs_4_1 ps_4_1) Hardware H264 Decoding No; Hardware video decoding disabled or blacklisted Audio Backend wasapi Direct2D true DirectWrite true (6.3.9600.18123) GPU #1 Active Yes Description Intel(R) HD Graphics Vendor ID 0x8086 Device ID 0x0102 Driver Version 9.17.10.4229 Driver Date 5-28-2015 Drivers igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32 Subsys ID 00000000 RAM Unknown Diagnostics AzureCanvasAccelerated 0 AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo

(In reply to ajfhajf from comment #25) > Same problem, Nightly 28-09-16. Here is about:support : @ajfhajf Nightly 28-09-16 build is not include this patch.

Oops, this needed to be after InitializeDevices()

Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/16219621894e Initialize CanUseHardwareDecoding after we've created d3d11 devices. r=dvander

Verified as fixed in 52.0a1 (2016-09-29). Thank you very much! \o/

As this is verified fixed in 52, no need to track further. Thanks :Virtual!