1763880 - Explicitly disable DXVA decoding in the RDD process.

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Zaggy1024]

The WMF decoders currently don't use DXVA in the RDD process, meaning that VP9 and AV1 decoding cannot be done there.

The cause seems to be a combination of two issues:

• RDDParent calls PDMFactory::Supported() at init, which in turn initializes WMFDecoderModule to determine which codecs are supported on the system. This takes place before DX devices are created for the video bridge, so WMFDecoderModule determines that the DX devices are unusable.
• PDMFactory on the Content process does not prioritize RDD PDMs, the PDM initialization order determines the order they are checked. This means that at least on Windows, the RDD process is only used for platform-agnostic decoders.

The simplest fix is:

• Make RDDParent::RecvInitVideoBridge reinitialize WMFDecoderModule, the same way RDDParent::RecvUpdateVar does. We may be able to also change the initialization order to only initialize decoder support when the bridge is set up, but we need to consider that the video bridge can be disabled if the RDD process crashes.
• Reorder content process PDM initialization to prioritize the RDD RemoteDecoderModule.
  I've confirmed these steps allow AV1 to be hardware decoded in the RDD process.

This comment a couple years ago seems to indicate that hardware decoding was not used in the RDD process, but WMFDecoderModule from that time indicates that it was intended to be enabled. It seems likely that it would have been supported at the time, considering that fixing this (regression?) is fairly simple.

Comment 1

[Zaggy1024]

I talked to :bryce about this in Matrix, but :alwu I'm wondering if you have any perspective on potential issues that could come up if we enable WMF HW in RDD. Could we fix this issue and enable this in Nightly or would it be risky?

Comment 2

[Alastor Wu [:alwu]]

What is the main point of using DXVA is the RDD process? On Windows, we expect HW decoding happening on the GPU process. If it's on GPU process, we could even enjoy the benefit of no need to copy the video data.

Comment 3

[Zaggy1024]

You may be right, although I had assumed that it partially defeated the purpose of the RDD existing to run decode in the GPU process, since a decoder crash will cause all the rendering to stop. Is it impossible to do zero-copy decoding with separate processes, as well?

If it is preferred to only use the GPU process, though, it seems to make sense to change WMFDecoderModule to explicitly disable DXVA in the RDD process here. Not sure why that line was added in the first place if the intention was never to do hardware decode there. Should it be allowed as a backup without zero-copy? Currently not even that is possible.

Comment 4

[Alastor Wu [:alwu]]

In term of the performance, let decoding happens in GPU process would be most benefitial (no matter hw & sw) because it could help to reduce the need of copying video as much as possible (Chrome already did that) But your concern also makes sense, I don't know how gfx team think about the decoding crash would also affect the rendering.

Jeff, I wonder what the thought from the gfx team's perspective is? Would gfx team want all video decoding happening in GPU?

Not sure why that line was added in the first place if the intention was never to do hardware decode there.

The zero-copying thing was added recently, so I guess we still wanted to use RDD as a backup place for HW decoding at that time. But as what you mentioned in the comment0, this didn't happened.

Should it be allowed as a backup without zero-copy?

I think it won't hurt to enable HW decoding on RDD as a back up plan on Windows.

Comment 5

[Zaggy1024]

Changing the bug title per discussion on Matrix. The intention is to keep hardware decoding in the GPU process, so DXVA should probably be explicitly disabled in the RDD process, and the comment removed referring to allowing DXVA when there is a video bridge:

https://searchfox.org/mozilla-central/rev/3269d4c928ef0d8310c2f57634e9b6057aa636e9/dom/media/platforms/wmf/WMFDecoderModule.cpp#108

Comment 6

[Jim Mathies [:jimm]]

Zaggy, were you going to take this or should we find someone in media? Also curious about the priority here. If this is something we need to prioritize please block this bug on the media-triage meta.

Comment 7

[Zaggy1024]

Anyone is free to take it, I have it on my back burner since it's a simple change.

If this affects things it should be an edge case, as the video bridge normally isn't initialized before that WMFDecoderModule code is hit, which causes PDMFactory on RDD to determine that it shouldn't attempt to send DXVA-requiring formats (VP8, VP9 and AV1) to WMFDecoderModule. Now that I think about it again, though, it will likely at least mean that H264 with DXVA will be used in the RDD process if it fails in the GPU process.

Comment 8

[Zaggy1024]

Attachment: Bug 1763880 - Explicitly disable WMF hardware video decoding in the RDD process, which was previously broken. r=alwu

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5e05f9cabd24
Explicitly disable WMF hardware video decoding in the RDD process, which was previously broken. r=alwu

Comment 10

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/5e05f9cabd24