Open Bug 1724682 Opened 3 years ago Updated 2 years ago

[Widevine] DRM_NO_KEY_SYSTEM when building with mingw-w64

Categories

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

x86_64
Windows
defect

Tracking

()

UNCONFIRMED

People

(Reporter: alexboy94, Unassigned)

Details

Attachments

(4 files)

Attached file console.log

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.

Attached file gmplog.moz_log
OS: Unspecified → Windows
Hardware: Unspecified → x86_64
Version: Firefox 91 → Trunk
Summary: DRM_NO_KEY_SYSTEM when building with mingw-w64 → [Widevine] DRM_NO_KEY_SYSTEM when building with mingw-w64
Assignee: nobody → bvandyk
Severity: -- → S3
Priority: -- → P3

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

Anything I can do to help debug this more?

Sure! It will involve debugging why the process is failing to start.

  • It's this code that is failing.
  • The code is calling into this code, which looks like it's failing.

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.

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?

Attached file sandbox.log
Here's the log output from the browser console when using `MOZ_SANDBOX_LOGGING=1`: ```log

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.

Flags: needinfo?(bvandyk)
Attached file sandbox.log

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?

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.

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.

Flags: needinfo?(bvandyk) → needinfo?(jmathies)
Assignee: brycebugemail → nobody
Severity: S3 → S4
Flags: needinfo?(jmathies)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: