[Widevine] DRM_NO_KEY_SYSTEM when building with mingw-w64
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
People
(Reporter: alexboy94, Unassigned)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0 Waterfox/91.0a1
Steps to reproduce:
Built Firefox with mingw-w64. Since GMP recognises the system type as WINNT_x86_64-gcc3-x64
, I added the following to widevincdm.json
to make sure it would download/install the plugin:
"WINNT_x86_64-gcc3-x64": {
"alias": "WINNT_x86_64-msvc"
}
Actual results:
When attempting to load a video that requires DRM, widevine fails to load.
Expected results:
DRM enabled video should play.
Reporter | ||
Comment 1•3 years ago
|
||
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
It looks like the GMP process is failing to load
D/GMP GMPServiceChild failed to launch GMP with error: NS_ERROR_FAILURE (0x80004005) - GeckoMediaPluginServiceChild::GetContentParent SendLaunchGMPForNodeId failed with description (Process has not loaded.)
and
D/GMP GMPParent[1d7bfe3a000|childPid=0] LoadProcess: Failed to launch new child process
Reporter | ||
Comment 3•3 years ago
|
||
Anything I can do to help debug this more?
Sure! It will involve debugging why the process is failing to start.
You've got a couple of options to debug this.
- Try running firefox with the env var
MOZ_DISABLE_GMP_SANDBOX=1
set. This will disabled the GMP sandbox and let us know if the problem is GMP sandbox related. - If that doesn't help, debugging the code above. You could use a debugger to see what's going on, or you could add extra logging to try and narrow down where the
Launch
code is failing. I think it's likely that the failure is happening in further calls starting here, so it may require some drilling down.
Reporter | ||
Comment 5•3 years ago
|
||
Running with MOZ_DISABLE_GMP_SANDBOX=1
works 👍. Any info from logs or related that may be of use?
Thanks for checking that! Could you try running with the sandbox on and logging on to see if you get any logs indicating what the sandbox is dying on?
Reporter | ||
Comment 7•3 years ago
|
||
Thanks. I don't know if I'll have cycles to look at this immediately. NI myself to have a look when I get a moment.
Reporter | ||
Comment 9•3 years ago
|
||
Output from the browser console when using MOZ_SANDBOX_LOGGING=1
. It doesn't look verbose enough or outputting anything relevant - should I use any other prefs?
Reporter | ||
Comment 10•3 years ago
|
||
Sorry, don't know what's happened! Double posted :-)
There's certainly some sandbox logging in there. I don't know off the top of my head if any of the blocking happening is our culprit -- there's certainly some stuff being blocked.
Reporter | ||
Comment 12•3 years ago
|
||
Ah wasn’t sure if it was enough information to do anything with. Good to hear then, if there’s anything else I can help with let me know - not sure I have the expertise to debug and step through the GMP and sandboxing around it.
I'm thinking we may be able to debug further if I can look at the logs and Windows sandbox rules, and if we can find a rule that looks like it's clobbering your build based on the logs, we could try a build with that rule(s) disabled to figure this out. However, the sandbox isn't my primary domain of expertise, so I need some time to trawl the code.
Similarly I'm not sure if the above log contains all possible info. I'll let you know if I figure out if we can gather more.
Passing NI.
Updated•2 years ago
|
Description
•