Make Windows Media Foundation decoders check for hardware support for codecs and profiles before using (enabling VP9 HDR, disabling all WMF software fallbacks)
Categories
(Core :: Audio/Video: Playback, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox101 | --- | fixed |
People
(Reporter: Zaggy1024, Assigned: Zaggy1024)
References
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
Steps to reproduce:
Play an HDR VP9 video, or play VP9 video on a device not supporting hardware decoding of VP9.
Actual results:
Currently, the WMF implementation will unnecessarily say that it does not support 10 or 12 bit video, by calling PlatformDecoderModule::SupportsColorDepth, which checks that the bit depth is always 8 bits.
Additionally, the VPX MFT has a software fallback that will be used in all cases where the VP9 decoder module is installed from the store, even when ffvpx will probably be faster.
Expected results:
WMFDecoderModule should rely always and completely on WMFVideoMFTManager to determine hardware support, which can use DXVA2Manager::SupportsConfig to determine whether a certain codec and profile will be hardware accelerated.
As another note, it seems like it might be worth removing PlatformDecoderModule::SupportsColorDepth, since it's not used anywhere outside child classes to PlatformDecoderModule, and is mostly ignored by those as well.
The exceptions I found are BlankDecoderModule, NullDecoderModule, EMEDecoderModule and GMPDecoderModule.
Is there any reason BlankDecoderModule and NullDecoderModule couldn't pretend to ingest >8bits?
For the plugins, it seems like it might be worth making them determine the bit depth they support some other way, maybe overriding PDM::Supports and passing more info to the plugin manager itself? My understanding of those modules is a pretty incomplete though, so I don't know if that's possible yet.
|
||
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
This will enable hardware decoding for 10-bit VP9 and AV1 on supported systems.
|
||
Updated•2 years ago
|
Pushed by zaggy1024@gmail.com: https://hg.mozilla.org/integration/autoland/rev/9958701c1640 Use D3D11 APIs to check specific video codec profiles on Windows to determine hardware support. r=alwu
|
||
Comment 5•2 years ago
|
||
Backed out for causing bustages.
Backout link: https://hg.mozilla.org/integration/autoland/rev/17d94894a53a39e46f1877587f01d7719d7b927d
Failure log: https://treeherder.mozilla.org/logviewer?job_id=376034798&repo=autoland&lineNumber=14139
Odd, it seems like the compiler flag for switch fallthrough must not be enabled on try. https://treeherder.mozilla.org/jobs?repo=try&revision=34518532744dd7363357753a27f4a49b6f59e0c1
Fixing the issue and re-pushing.
Pushed by zaggy1024@gmail.com: https://hg.mozilla.org/integration/autoland/rev/fe0e4a38498c Use D3D11 APIs to check specific video codec profiles on Windows to determine hardware support. r=alwu
|
||
Comment 8•2 years ago
|
||
| bugherder | ||
Description
•