Closed Bug 1214425 Opened 9 years ago Closed 9 years ago

[EME] Partition GMP storage by platform and x86/x64

Categories

(Core :: Audio/Video: MediaStreamGraph, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox42 --- fixed
firefox43 --- fixed
firefox44 --- verified

People

(Reporter: cpearce, Assigned: cpearce)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Adobe need to ensure GMP storage written by Win32 Firefox is not used by the same profile run under Win64 Firefox. The simplest way to do that is to add the platform and whether we're x86/x64 to the GMP storage base path.

We also need to handle upgrading the storage from before this change, and handling what happens if the Gecko version downgrades and then upgrades again.
Attached patch PatchSplinter Review
* Include OS+Arch in the GMP storage dir.
* Handle upgrade of old storage records to new storage location, overwriting any records already in the new location so that we handle the case of upgrade, downgrade, followed by upgrade again.
Attachment #8673362 - Flags: review?(gsquelart)
Comment on attachment 8673362 [details] [diff] [review]
Patch

Review of attachment 8673362 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with doc nit.

::: dom/media/gmp/GMPServiceParent.cpp
@@ +211,5 @@
> +static nsresult
> +GMPPlatformString(nsAString& aOutPlatform)
> +{
> +  // Append the OS and arch so that storage if the profile if copied or used
> +  // under a different bit-ness or copied to another platform, we don't reuse it.

Did you mean "Append the OS and arch so that we don't reuse the storage if the profile is copied or used under a different bit-ness, or copied to another platform."?
Attachment #8673362 - Flags: review?(gsquelart) → review+
Thanks Masatoshi.

https://hg.mozilla.org/mozilla-central/rev/e24e0684b0b3
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Uplift needed.
Flags: needinfo?(cpearce)
Approval Request Comment
[Feature/regressing bug #]: EME
[User impact if declined]: Adobe's 64 bit EME plugin will crash if run with a Firefox profile that's had Adobe EME used under 32 bit Firefox/EME.
[Describe test coverage new/current, TreeHerder]: We have lots of EME mochitests
[Risks and why]: Low, just changes the directory we store EME storage in.
[String/UUID change made/needed]: None.
Attachment #8673906 - Flags: review+
Attachment #8673906 - Flags: approval-mozilla-beta?
Attachment #8673906 - Flags: approval-mozilla-aurora?
Comment on attachment 8673906 [details]
Patch: Aurora & Beta rebase

Prevent a crash, taking it.
Is there a way for QE to test that?
Thanks
Attachment #8673906 - Flags: approval-mozilla-beta?
Attachment #8673906 - Flags: approval-mozilla-beta+
Attachment #8673906 - Flags: approval-mozilla-aurora?
Attachment #8673906 - Flags: approval-mozilla-aurora+
Should be in 42 beta 7
Thanks for the quick approval!

QE should be able to test this once we get the next EME plugin/CDM drop from Adobe. I believe these STR will work:

1. Play Netflix video in 32bit Firefox 42 beta<7 with Adobe Primetime CDM v15
2. Close Firefox.
3. Play Netflix video in 64bit Firefox 42 beta<7 with Adobe Primetime CDM v15, CDM should crash and playback should fail.

You should be able to substitute Nightly from before 2015-10-14 for 42beta<7 in the above steps.

When builds with this patch is used, we shouldn't get the CDM crash.

We won't get Adobe Primetime CDM v15 for a day or so I believe.
Perfect, thanks!
Flags: qe-verify+
Flags: needinfo?(cpearce)
With 42.0b6 under Windows 7 64-bit and the STR from comment 9 I only get an error → https://goo.gl/c0NT8y, no crash encountered.
Verified fixed with 42.0RC build 2 (Build ID: 20151029151421), under Windows 7 64-bit.

Regarding 44.0a2 and 45.0a1, I encountered 2 issues:
1.1. At step 3 from comment 9: after 8-9 minutes, the plugins (both openh and drm) are not installed, "..will be installed shortly." message is displayed; the plugins are reinstalled if I manually select Find updates or reset the 'media.gmp-manager.lastCheck' pref (reinstalled in 1 minute); 
1.2. this issue is not reproducible when launching 44.0a2 32-bit build and 45.0a1 32-bit build with the same profile  → both plugins are already installed; same result with 64-bit.

2.1. With e10s on/off, at step 3 from comment 9 I get the following error on Netflix → https://goo.gl/xHzIB8 (Note that the plugin was installed via Find updates option)
2.2. Browser console output: 
MediaKeys::Init() promise rejected 0x8053000b 'GetGMPDecryptor failed to return a CDM'

What's your input regarding the above, Chris? Thanks!
Flags: needinfo?(cpearce)
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #13)
> With 42.0b6 under Windows 7 64-bit and the STR from comment 9 I only get an
> error → https://goo.gl/c0NT8y, no crash encountered.
> Verified fixed with 42.0RC build 2 (Build ID: 20151029151421), under Windows
> 7 64-bit.
> 
> Regarding 44.0a2 and 45.0a1, I encountered 2 issues:
> 1.1. At step 3 from comment 9: after 8-9 minutes, the plugins (both openh
> and drm) are not installed, "..will be installed shortly." message is
> displayed; the plugins are reinstalled if I manually select Find updates or
> reset the 'media.gmp-manager.lastCheck' pref (reinstalled in 1 minute); 
> 1.2. this issue is not reproducible when launching 44.0a2 32-bit build and
> 45.0a1 32-bit build with the same profile  → both plugins are already
> installed; same result with 64-bit.

This is expected behaviour. We'll update within 24 hours.


> 2.1. With e10s on/off, at step 3 from comment 9 I get the following error on
> Netflix → https://goo.gl/xHzIB8 (Note that the plugin was installed via Find
> updates option)
> 2.2. Browser console output: 
> MediaKeys::Init() promise rejected 0x8053000b 'GetGMPDecryptor failed to
> return a CDM'
> 
> What's your input regarding the above, Chris? Thanks!

I can't reproduce this with Nightly 46 using the steps in comment 7, but would like to be able to.

Alexandra: can you still reproduce this? If so, any idea what's different about your setup to mine? Any special steps you're taking that I am not?
Flags: needinfo?(cpearce) → needinfo?(alexandra.lucinet)
(In reply to Chris Pearce (:cpearce) from comment #14)
> I can't reproduce this with Nightly 46 using the steps in comment 7, but
> would like to be able to.
> 
> Alexandra: can you still reproduce this? If so, any idea what's different
> about your setup to mine? Any special steps you're taking that I am not?

No, I am not able to reproduce; Verified fixed with 44.0RC build 1 (Build ID: 20160118143821) and latest Nightly 46.0a1 (from 2016-01-19), under Windows 7 64-bit and Windows 10 64-bit.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(alexandra.lucinet)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: