User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

I get no hardware video decoding at all with Firefox. I have tried AVC (H264), VP9, AV1.
Chromium is able to do hardware decoding without any issues.
If I set "media.hardware-video-decoding.force-enabled" to "true", then Firefox can do AVC (H264), but still no VP9 or AV1.

The hardware is capable of decoding all these three codecs: Intel i7-11800h and NVIDIA 3080 (notebook). OS is x64 Windows 10 Enterprise LTSC 21h2 (19044.1586). I use the latest drivers, all software is up to date.

I am attatching some screenshots, their names should be self-descriptive. They contain screenshots of Firefox, Chromium, TaskManager and DXVAchecker while these browsers are running video files using the aforementioned codecs. There is a screenshot of MPV as well which shows the video metadata, including MPV's own pseudo-UI confirming it is using HW decoding. DXVAchecker is also confirming Chromium is able to use HW dec for both VP9 and AV1.

I have tested Firefox ESR, Firefox Stable and the current Nightly, they behave.

Actual results:

No HW video decoding, resulting in high CPU usage.

Expected results:

Firefox should be capable of using HW decoding.

ESR, Stable and Nightly behave the same. I must have truncated the message by mistake.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Would you mind to provide your about:support?
Also, why you think Firefox didn't use HW decoding? In your screenshot, there did have GPU usage. A way to verify what decoder you're using is to install this add-on and see videoDecoderName description.
Thanks!

I will attach the about:support.
I can tell it is not using HW decoding based in resource usage. Disabling HW decoding in MPV will result in the same usage as Firefox. Enabling HW decoding in MPV will result in a significantly lower resource usage, and is in line with Chromium.
I have also tried that extension.

Also two screenshots:
h264_default_no_hw_accel.png -> Firefox in its default state, does nnot use HW decoding. H264 codec.
h264_hw_accel_forced.png -> pref. "media.hardware-video-decoding.force-enabled" set to "true". Same video file, H264 codec.

Do note that setting "media.hardware-video-decoding.force-enabled" to "true" will only get Firefox to use HW acceleration for H264. VP9 and AV1 are still done in software.

VP9 and AV1 will only be decoded in software, regardless of "media.hardware-video-decoding.force-enabled" state. Top screenshots are Nightly 100 in its default config. Bottom ones have only the aforementioned change.

AV1 HW decoding is only supported on Intel Gen 12, your graphic card is Tiger Lake (gen11) which doesn't support that. But for VP9, your setup should be enough for HW decoding.

Bug 1760804 is going to change how we would query HW decoder on Windows, we could wait for it landing and see if that helps or not.

Well, this particular iGPU on i7-11800h does support HW AV1 decoding. Both Chromium and MPV are capable of doing it. I hope Mozilla won't artificially limit the AV1 decoding to AlderLake.
That said, I can run Firefox off the RTX 3080, and the results are the same. Firefox simply won't use HW decoding.

oh, ok. Let's wait for Bug 1760804 and revisit this bug if the issue still presents.

Ashely's work in Bug 1754239 - Add hardware accelerated media encode/decode information to about:support should help as well.

Follow up on this once we have more hardware support information.

Could you help me again try the Nightly to see if you could use HW for VPX and AV1 decoding?
Thank you.

No changes. h264, VP9 and AV1 are all soft decoded.
Nightly 101.0.0.8132 2022-04-07

dragos, on that Nightly release, could you run some logs? Navigate to your Firefox folder in a command prompt and run firefox using this command:
firefox -MOZ_LOG="MediaSource:5,MediaFormatReader:5,MediaDemuxer:5,PlatformDecoderModule:5,MediaDecoder:5,sync,timestamp" -MOZ_LOG_FILE="%userprofile%\Documents\firefox_log"
That will write log files to your Documents folder, the relevant one should be firefox_log.child-1.moz_log most likely. It will have lines starting with [GPU XXXXXX: Main Thread] if it's the correct file.

Also, judging by the fact that media.hardware-video-decoding.force-enabled is only used once to override FEATURE_HARDWARE_DECODING, I would guess there must be something causing that feature status to be disabled. Is there any way to determine why that is being turned off yet?

I attempted to run the VP9 video in the newest Nightly, using a clean profile.

It looks like GetCanUseHardwareVideoDecodingOrDefault() is returning false when WMFDecoderModule.cpp initializes:

2022-04-07 21:36:38.359000 UTC - [GPU 13900: Main Thread]: D/PlatformDecoderModule sDXVAEnabled: true, CanUseHardwareVideoDecoding: false
2022-04-07 21:36:38.364000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule H264 is enabled
2022-04-07 21:36:38.365000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule VP8 MFT requires DXVA
2022-04-07 21:36:38.365000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule VP9 MFT requires DXVA
2022-04-07 21:36:38.365000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule AV1 MFT requires DXVA
2022-04-07 21:36:38.366000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule MP3 is enabled
2022-04-07 21:36:38.367000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule AAC is enabled
2022-04-07 21:36:38.367000 UTC - [GPU 13900: Main Thread]: D/PlatformDecoderModule WMFDecoderModule::Init finishing

Might this be caused by some blocklist entry? I'm not sure if there's something else that could cause FEATURE_HARDWARE_VIDEO_DECODING not to be OK here:
https://searchfox.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#2420

HW decoding seems being blocked by this. Reporter's driver is 30.0.101.1404 (2-18-2022) which is pretty new.

Jeff, is this blocking list correct? Should we specify a concrete version?

Thanks.

Newer Intel drivers break our assumptions about the bottom four digits
being the build id and we end up blocking newer drivers with build ids
like 11404. This reverts the change in bug 1295902 which changed this
blocklist rule to only look at the build number. I think bug 1295902 was
just trying to be more correct and I don't know that it actually blocks
important crashes. Decoding now mostly happens in the GPU process
so the impact of these crashes is reduced from what it originally was.

The information on how to interpret Intel driver version is from:
https://www.intel.ca/content/www/ca/en/support/articles/000005654/graphics.html

The proper fix is to have Intel specific driver version parsing.

This query suggests that's we're blocking 13% of our Intel users from getting hardware video decoding instead of the .4% that would've been blocked if we didn't have bug 1295902.

https://sql.telemetry.mozilla.org/queries/85227/source

I was able to reproduce this locally. Twitch at 1080p was unplayable on a Intel Xe laptop with a recent driver.

Here are the most common driver versions that are blocked by the current rule and would be unblocked by my change on this bug:

25,673	8.15.10.1749
13,882	8.15.10.2702
12,984	30.0.101.1122
11,992	8.15.10.1930
8,819	30.0.101.1191
6,601	8.15.10.2697
4,194	8.15.10.2302
4,165	10.0.19041.868

There are a bunch of 8.15.x.x drivers that we might still want blocked. It's probably safer to also block those if we decide to uplift this to release.

Keeping 8.15.x.x blocked would bump the .4% back up to 9%

I'll try to get a graph over time tomorrow to get a sense for how rapidly users are updating their drivers to affected versions.

[Tracking Requested - why for this release]:
Potentially a dot release driver

https://hg.mozilla.org/mozilla-central/rev/806873368d4c

https://www.intel.com/content/www/us/en/download/19344/intel-graphics-windows-dch-drivers.html

Mozilla should test their Intel driver version detection code on the latest Intel 30.0.101.1660 graphics driver or later versions.

https://www.intel.com/content/www/us/en/download/726609/intel-arc-graphics-windows-dch-driver.html

This will also affect Intel Arc discrete GPUs which uses the 30.0.101.1xxx driver version schema also, although Intel Arc driver is currently 300 build number version behind. In the future the driver version will also probably roll over to 102.xxxx driver version schema.

This bug needs to be fixed before Firefox 100.0 and ESR 102.0 ships.

The patch landed in nightly and beta is affected.
:jrmuizel, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Here's a graph in problem over time: https://sql.telemetry.mozilla.org/embed/query/85240/visualization/211044?api_key=jwBQpKHV7DM6mpNQotFOQXLvLZZpHvvsfXntiN1O&

Newer Intel drivers break our assumptions about the bottom four digits
being the build id and we end up blocking newer drivers with build ids
like 11404. This reverts the change in bug 1295902 which changed this
blocklist rule to only look at the build number. I think bug 1295902 was
just trying to be more correct and I don't know that it actually blocks
important crashes. Decoding now mostly happens in the GPU process
so the impact of these crashes is reduced from what it originally was.

The information on how to interpret Intel driver version is from:
https://www.intel.ca/content/www/ca/en/support/articles/000005654/graphics.html

The proper fix is to have Intel specific driver version parsing.

This is a more conservative fix that also adds blocking for drivers
earlier or equal to 8.15.10.2849.

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Beta/Release Uplift Approval Request

• User impact if declined: Intel users on Windows with newer video drivers will not get hardware accelerated video decoding
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Get the newest Intel driver (something with the last set of digits of the version number < 2849), go to Twitch and start a video. Confirm that the "Video Decoding" graph in Process Manager under the GPU pane has 0% without this change and some non-zero % with it.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This removes an accidental driver block. If we need to add it back we can use a downloadable blocklist entry to block it without having to spin a new dot release.
• String changes made/needed:

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Approved for 99.0.1

https://hg.mozilla.org/releases/mozilla-release/rev/7bd0f12e4810

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Approved for 100.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/2f6cc1354b9c

Trying the latest Nightly, 101.0.0.8136, 2022-04-11, using the latest Intel driver, 30.0.101.1660, I get no HW acceleration for VP9 or AV1. Only h264 seems to work.

Would you mind to capture the debug log like what comment 19 described again?
Thank you.

I will do it again in one moment. One more thing, this laptop can disable the iGPU and completely bypass it, usinng the dedicated GPU, which in this case is a Nvidia 3080, for both processing and output.
It can also only decode h264.

Nightly 101 2022-04-11

Nightly 101 2022-04-11 NVIDIA only

Per your log, it showed that we couldn't find the correct MFT on your computer for VPX (MF_E_TOPO_CODEC_NOT_FOUND, 0xC00D5212) and couldn't find the correct component for AV1 (WINCODEC_ERR_COMPONENTNOTFOUND, 0x88982F50).

I have tested Firefox ESR, Firefox Stable and the current Nightly, they behave.

Did you say on ESR and Release, you also couldn't get the hw decoding, right? But I suppose Chromium also uses MFT for VPX decoding, we would need to figure out why we couldn't find MFT on your system.

Indeed, it was a misspell on my part. ESR and Stanble behave the same way as Nightly 100 at the time of writing the initial report.

Let's track this issue on bug 1764200. Use this bug for gfx blocklist error.

Hello,
Since we don't have the necessary hardware in order to verify this issue, could you please take a look and see if the issue was fixed on the latest available builds: 99.0.1 RC, 100.0b4, Nightly 101?
Ty!

Well, this bug was indeed solved, and my driver is no longer blocked ny Firefox.
The second part, described here in comments https://bugzilla.mozilla.org/show_bug.cgi?id=1764200 was on my end. My install was lacking certain codecs. After installing them everything works fine. Chromium seems to work around this issue.

100.0b4 still has this problem. No HW dec on this build.

99.0.1 RC is working fine. Both h264 and VP9 use HW decoding.

Latest 101 build also working properly. Uses HW decoding on all h264, VP9 and AV1.

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: 4% of our Intel users are not getting hardware video decoding because their drivers are too new.
• User impact if declined: Intel users on Windows with newer video drivers will not get hardware accelerated video decoding
• Fix Landed on Version: 99
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This removes an accidental driver block. If we need to add it back we can use a downloadable blocklist entry to block it without having to spin a new dot release.

Backed out changeset 2f6cc1354b9c (bug 1762125) to uplift different patch on ticket
Backout link: https://hg.mozilla.org/releases/mozilla-beta/rev/c39a2cdfd2d2718c36b1fdec5a4187cade15559a

D143362 will go out in 100.0b6

https://hg.mozilla.org/releases/mozilla-beta/rev/63b4ec3eb651

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Approved for 91.9esr

https://hg.mozilla.org/releases/mozilla-esr91/rev/fb4046e17433

Hello,
Could you please verify that the issue is also fixed on Firefox 91.9ESR (https://archive.mozilla.org/pub/firefox/candidates/91.9.0esr-candidates/build1/)?
Thank you!

Yes, the issue is fixed on ESR 91.9.0 as well as on 100.0b9,.

Based on comments 52, 53 and comment 63, marking this as verified.