1912238 - [EME] `navigator.requestMediaKeySystemAccess` API fails on Windows 10/11 if at least one of the provided robustness is not supported

Status: RESOLVED DUPLICATE of bug 1911283

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

Description

[pea.berberian]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

On Firefox 129, 130 (current dev edition), but not nightly (131):
From JavaScript, on Windows 10 with a widevine CDM available, call the following code:

navigator.requestMediaKeySystemAccess("com.widevine.alpha", [
      {
        "initDataTypes": ["cenc"],
        "videoCapabilities": [
          {
            "contentType": "video/mp4;codecs=\"avc1.4d401e\"",
            "robustness": "HW_SECURE_ALL"
          },
          {
            "contentType": "video/webm;codecs=\"vp8\"",
            "robustness": "HW_SECURE_ALL"
          },
          {
            "contentType": "video/mp4;codecs=\"avc1.4d401e\"",
            "robustness": "HW_SECURE_DECODE"
          },
          {
            "contentType": "video/webm;codecs=\"vp8\"",
            "robustness": "HW_SECURE_DECODE"
          },
          {
            "contentType": "video/mp4;codecs=\"avc1.4d401e\"",
            "robustness": "HW_SECURE_CRYPTO"
          },
          {
            "contentType": "video/webm;codecs=\"vp8\"",
            "robustness": "HW_SECURE_CRYPTO"
          },
          {
            "contentType": "video/mp4;codecs=\"avc1.4d401e\"",
            "robustness": "SW_SECURE_DECODE"
          },
          {
            "contentType": "video/webm;codecs=\"vp8\"",
            "robustness": "SW_SECURE_DECODE"
          },
          {
            "contentType": "video/mp4;codecs=\"avc1.4d401e\"",
            "robustness": "SW_SECURE_CRYPTO"
          },
          {
            "contentType": "video/webm;codecs=\"vp8\"",
            "robustness": "SW_SECURE_CRYPTO"
          }
        ],
        "audioCapabilities": [
          {
            "contentType": "audio/mp4;codecs=\"mp4a.40.2\"",
            "robustness": "HW_SECURE_ALL"
          },
          {
            "contentType": "audio/mp4;codecs=\"mp4a.40.2\"",
            "robustness": "HW_SECURE_DECODE"
          },
          {
            "contentType": "audio/mp4;codecs=\"mp4a.40.2\"",
            "robustness": "HW_SECURE_CRYPTO"
          },
          {
            "contentType": "audio/mp4;codecs=\"mp4a.40.2\"",
            "robustness": "SW_SECURE_DECODE"
          },
          {
            "contentType": "audio/mp4;codecs=\"mp4a.40.2\"",
            "robustness": "SW_SECURE_CRYPTO"
          }
        ],
      }
]).then(
  // on success
  () => console.log("Configuration supported"),

  // on failure
  () => console.error("Configuration unsupported")
);

(Here reproduced on the following userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0" )

Actual results:

The configuration is announced as unsupported.

Expected results:

The configuration should be announced as supported (and a MediaKeySystemAccess object should be created).

This only seems to happen if at least one of the provided robustness is provided (e.g. from tests, it doesn't seem to happen if only asking for software decode+crypto capabilities).

From what I understand from https://www.w3.org/TR/encrypted-media-2/#dom-navigator-requestmediakeysystemaccess and https://www.w3.org/TR/encrypted-media-2/#dfn-get-supported-configuration, and also from other implementations (Firefox on Linux and MacOS, prior Firefox versions, Google Chrome, Microsoft Edge with both Widevine and Playready, other derived browsers on embedded devices...), as long as one of the provided audioCapabilities and videoCapabilities is supported (and other asked configuration also is), the requestMediaKeySystemAccess call should resolve with the corresponding MediaKeySystemAccess.

Note that as this seems to be fixed on Firefox nigthly, this issue may already have been spotted and fixed, though I did not find the corresponding bug report in bugzilla.
So in doubt, I'm creating one, sorry if that was already seen.

Comment 1

[pea.berberian]

Two added details now that I've seen the resulting posted issue (I do not seem to be able to edit it):

• The user agent on top of the issue is NOT the device on which the bug was seen (it is "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0", as written lower in the issue)

• This only seems to happen if at least one of the provided robustness is provided

  I wanted to write here "is unsupported", instead of "is provided"

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Alastor Wu [:alwu]]

Could you help me turn the pref media.eme.mfcdm.origin-filter.enabled to 0 to see if it fixes the problem? If so, that is bug 1911283, which is already fixed on Fx130 Beta and Fx129.0.1 Release. Thanks!

Comment 4

[pea.berberian]

Yes, turning media.eme.mfcdm.origin-filter.enabled to 0 does fix the issue so it may be the same bug.

Just to add more information to this, as the original issue seems to link it to an hulu issue, it also broke canalplus.com, a streaming service popular in France (and some other territories) as well as applications from some of Canal+'s partners which rely on the same core player implementation (e.g. we know of production issues in poland or italy where customers could not use firefox).
Though we're (I'm working at Canal+ Group on that core player) also currently testing a new release with a work-around (one that corresponds to another work-around seen on some other streaming services which succeeded to stay functional) which calls navigator.requestMediaKeySystemAccess a second time without any set capability (video or audio) if the first call fails.

Anyway, very nice if the issue is already fixed for the future, thanks!

Comment 5

[Alastor Wu [:alwu]]

Thank for the confirmation! In addition, I'm curious if Canal+ is going to use Widevine L1 because you use HW_SECURE_ALL in the request? Or it's simply just checking all the possibilities, and the actual decision is up to the Canal+'s partner? Thanks!

Comment 6

[Alastor Wu [:alwu]]

In addition, I wonder if you would mind to help me check this build to see if the issue still persists or not? Thank you so much!

Comment 7

[pea.berberian]

Thank for the confirmation! In addition, I'm curious if Canal+ is going to use Widevine L1 because you use HW_SECURE_ALL in the request? Or it's simply just checking all the possibilities, and the actual decision is up to the Canal+'s partner? Thanks!

Basically like many other streaming platforms, we most often encounter contents with different protection requirements depending on the media quality: higher video qualities such as 1080p, 4k or HDR, often requiring widevine L1, PlayReady SL 3000 or other ""HWDRM"" tech to be able to be decrypted+decoded, whereas if you can only rely on software DRM, you'll only be able to decode lower qualities (this is basically often the result of a compromise between the content right holders who don't want their content to be easily copied and the streaming platform who wants user to be able to stream that content on most devices).
We rely on adaptive streaming technologies (such as DASH or HLS) to facilitate/standardize this type of setup.

And we are able to rely on such "HWDRM" on many platforms though not any one relying on firefox I know of for now.

In terms of EME calls, what we do by default (the behavior can be updated by the final application from Canal+ / our partners) is to poll for all robustnesses on all platforms and try relying on the "highest" one available on the current platform based on those navigator.requestMediaKeySystemAccess's response. We do not ask for a different list of robustnesses per platform just in case some new feature, or some esoteric implementation, does bring support to e.g. widevine L1 on some platform without us knowing.

In addition, I wonder if you would mind to help me check this build to see if the issue still persists or not? Thank you so much!

OK I'll test it once I re-access my windows setup (on friday?).