Closed Bug 1527811 Opened 8 months ago Closed 8 months ago

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

Categories

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

ARM64
Windows 10
enhancement

Tracking

()

VERIFIED FIXED
mozilla67
Tracking Status
firefox67 --- verified

People

(Reporter: cpearce, Assigned: cpearce)

References

Details

Attachments

(6 files, 1 obsolete file)

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...).

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.

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

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

Depends on D19898

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

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

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

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

Priority: -- → P2
Blocks: 1528661
Attachment #9044107 - Attachment is obsolete: true
Pushed by cpearce@mozilla.com:
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
Depends on: 1531376
Depends on: 1532578

Hi Chris, is there something we can test here?

Flags: needinfo?(cpearce)

(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. :)

Flags: needinfo?(cpearce)
Flags: qe-verify+

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.

Flags: needinfo?(cpearce)

(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.

Flags: needinfo?(cpearce)
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.