1527811 - Use x86 plugin-container.exe for x86 Widevine and ClearKey on aarch64 builds

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, enhancement, P2)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

In order to run Widevine on Windows on ARM64, we will load the x86 Widevine in an x86 plugin-container.exe child process of an aarch64 Firefox parent process.

This bug covers instantiating the x86 plugin-container.exe process for Widevine and ClearKey, and making it visible. We'll do this for ClearKey so that can test this too (once we have tests on Windows aarch64 builds...).

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1527811 - Make Widevine visible in Firefox UI for aarch64 Windows builds. r?glandium

Whether Widevine is visible or not depends on the media.gmp-widevinecdm.visible
pref, whose default is set at configure time, based on target platform. Add
Windows on aarch64 to the platforms Widevine targets.

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1527811 - Execute plugin-container.exe for CDM GMP child process in "i686" subdir on Windows on ARM. r?bobowen

This patch assumes that "the build" places plugin-container.exe, xul.dll, and
their dependencies in the "i686" subdirectory of the aarch64 firefox package
directory.

Depends on D19897

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1527811 - Add GMPUtils._isWindowsOnARM64(). r?Gijs

Allows subsequent patches to special case behavior when running on
Windows on ARM64.

Depends on D19898

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1527811 - On Windows on ARM64, add ClearKey GMP to the GMPService in i686 subdir. r?Gijs

We need to tell the GMPService where to find the ClearKey GMP, and in Windows
on ARM64 builds we should run the x86 ClearKey so that we test the same x86
emulation path that Widevine uses.

This patch assumes that the ClearKey GMP and its appropriate directory
structure are placed in the "i686" subdir of the aarch64 firefox dir by
the build.

Depends on D19899

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1527811 - Ensure we write the ABI of the GMP we expect to have installed. r?Gijs

We write the ABI of the plugin we installed to preferences so that if the ABI
stored in the profile of a previously installed plugin differs to the ABI of
the Firefox build we're runnning, we can uninstall the plugin and re-install
one with the correct ABI.

Since we're downloading a plugin of a different ABI than the parent process,
we need to modify the ABI written to preferences here.

This mechanism was added to handle Firefox profiles transitioning from running
in an x86 Firefox to an x64 Firefox on Windows. We can use the same mechanism
to handle transitioning from an x86 to aarch64 Widevine here.

When we eventually get an aarch64 version of Widevine, we can
rollback this changeset, and the ABI mismatch will be detected, and we'll
uninstall the x86 CDM, and download the new aarch64 CDM.

Depends on D19900

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1527811 - Don't pass appdir and omnijar path to GMP processes. r?bobowen

GMP shouldn't need them anyway, and this reduces the dependencies from the x86
build we need to package in the "i686" subdir.

Depends on D19901

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1527811 - Hide OpenH264 by default on Windows on ARM. r?dminor,Gijs

We don't have an aarch64 build of OpenH264 yet, and WebRTC on aarch64 is
blocked by DirectShow support from MS, so just hide OpenH264 from the addons
manager UI for now.

We achieve this by moving the isEME() check in GMPUtils.isPluginHidden() down
to after the isPluginSupported()||isPluginVisible() check, so we can use
the media.gmp-gmpopenh264.visible pref to hide OpenH264 in the addons
manager.

When we are ready to enable WebRTC, we can flip the pref.

Depends on D19902

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c1e05d18c18e
Execute plugin-container.exe for CDM GMP child process in "i686" subdir on Windows on ARM. r=bobowen
https://hg.mozilla.org/integration/mozilla-inbound/rev/83b6c1e3d898
Add GMPUtils._isWindowsOnARM64(). r=Gijs
https://hg.mozilla.org/integration/mozilla-inbound/rev/aae2bb67624e
On Windows on ARM64, add ClearKey GMP to the GMPService in i686 subdir. r=Gijs
https://hg.mozilla.org/integration/mozilla-inbound/rev/ad0dfa4133e6
Ensure we write the ABI of the GMP we expect to have installed. r=Gijs
https://hg.mozilla.org/integration/mozilla-inbound/rev/4afca6b3252e
Don't pass appdir and omnijar path to GMP processes. r=bobowen
https://hg.mozilla.org/integration/mozilla-inbound/rev/56d438156078
Hide OpenH264 by default on Windows on ARM. r=dminor,r=Gijs

Comment 9

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/c1e05d18c18e
https://hg.mozilla.org/mozilla-central/rev/83b6c1e3d898
https://hg.mozilla.org/mozilla-central/rev/aae2bb67624e
https://hg.mozilla.org/mozilla-central/rev/ad0dfa4133e6
https://hg.mozilla.org/mozilla-central/rev/4afca6b3252e
https://hg.mozilla.org/mozilla-central/rev/56d438156078

Comment 10

[Catalin Sasca, Desktop QA [:csasca]]

Hi Chris, is there something we can test here?

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Catalin Sasca, QA [:csasca] from comment #10)

Hi Chris, is there something we can test here?

Sure, you can test whether Netflix, and other EME streaming audio/video services work in Nightly on Windows on ARM64. As of a couple of days ago, they should work. :)

Comment 12

[Anca Soncutean, Desktop QA]

I’ve run a spot check testing (Netflix, Amazon Prime, Hulu, Shaka Player) with Fx 68.0a1(2019-04-21) and Fx 67.0b12 - aarch64 builds on Windows ARM64.

All worked properly, except a one time issue I’ve encounter on Nightly (on Amazon) see screenshot; I was not able to reproduce it again (clean or dirty profile, beta aarch build or regular one); the issue was triggered once I opened the video, after clicking on the seekbar and immediately on the fast-forwarding button. Note that audio worked fine and after a while (a minute or so) the issue was fixed. This seems related to bug 1521172.

Not sure if this intermittent onetime issue could be problematic for what was implemented here.

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #12)

All worked properly, except a one time issue I’ve encounter on Nightly (on Amazon) see screenshot; I was not able to reproduce it again (clean or dirty profile, beta aarch build or regular one); the issue was triggered once I opened the video, after clicking on the seekbar and immediately on the fast-forwarding button. Note that audio worked fine and after a while (a minute or so) the issue was fixed. This seems related to bug 1521172.

I've seen the green frame issue on non-EME video, so I don't think that issue is specific to EME video. Given it happens on EME and non-EME video, I wonder if that issue is graphics related.

We can investigate further in bug 1521172.