I noticed the problem recently during working for Bug 1766282. Last month, when I run reftest on CI, dom/media/test/reftest/short.mp4.lastframe.html test used hardware video decoder. But this week, when I tested it, it did not use hardware video decoder on Windows.

D3D11DXVA2Manager::CreateDecoder() was failed. "videoDevice->GetVideoDecoderConfigCount(&aDesc, &configCount)" returned failure.

https://treeherder.mozilla.org/jobs?repo=try&revision=8c2b6e52a8930a7979cb25b6c497ccae5fc330bb&selectedTaskRun=UjeSu5aaSP2MN1b-KhMelQ.0

D3D11DXVA2Manager::CreateDecoder() was called from D3D11DXVA2Manager::SupportsConfig() and Bug 1757823 did a lot of change recently. Then I wonder if Bug 1757823 might cause the regression.

Zaggy1024, alwu, the regression could happen by Bug 1757823?

Set release status flags based on info from the regressing bug 1757823

Look very possible. Maybe the D3D11_VIDEO_DECODER_DESC we setup was incorrect?

I noticed that I had lost H264/AVC1 acceleration a few days ago and just did a mozregression run, which brought up bug 1757823 as the regressor, so it's good to know this has already been noticed.

By the way, is VP8 supposed to be hardware accelerated? about:support shows it as available by default, but there's no video engine load when watching a VP8 clip.

(In reply to laszlo from comment #5)

I noticed that I had lost H264/AVC1 acceleration a few days ago and just did a mozregression run, which brought up bug 1757823 as the regressor, so it's good to know this has already been noticed.

By the way, is VP8 supposed to be hardware accelerated? about:support shows it as available by default, but there's no video engine load when watching a VP8 clip.

VP8 will likely not be hardware accelerated on most modern platforms, as the hardware path seems to either be disabled by hardware vendors or the Microsoft decoder.

(In reply to Sotaro Ikeda [:sotaro] from comment #2)

Zaggy1024, alwu, the regression could happen by Bug 1757823?

I believe so, I'll take a look. There is one mistake I made in the previous patch, not sure if it's what's causing this, but it should be a quick fix either way.

https://hg.mozilla.org/mozilla-central/rev/e15164d8b4c6

The patch landed in nightly and beta is affected.
:Zaggy1024, 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.

Comment on attachment 9274895 [details]
Bug 1767467 - Fix hardware H264 decoding support detection on Windows. r=alwu

Beta/Release Uplift Approval Request

• User impact if declined: D3D11 H264 hardware decoding will be unavailable
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Change is a minor correction to a previous patch.
• String changes made/needed:
• Is Android affected?: No

Comment on attachment 9274895 [details]
Bug 1767467 - Fix hardware H264 decoding support detection on Windows. r=alwu

Approved for 101.0b4.

https://hg.mozilla.org/releases/mozilla-beta/rev/f4d344fb8f7a

== Change summary for alert #34085 (as of Mon, 09 May 2022 15:50:40 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=34085