Improve error 6001 or add a new error for missing EME support

[alexandercerutti]

Have you read the FAQ and checked for duplicate open issues?

Yes

Is your feature request related to a problem? Please describe.

Please note we are still using Shaka 3.x and for several reasons we cannot upgrade (yet) to v4.

We encountered an apparently unknown issue with DRMed Live streams. On our QA systems, we checked for and saw a lot of 6001 errors coming from different platforms (and different reasons, I guess).

We started focusing on Android 11 Chrome on Moto E20 and we found out that most of the issues on that device with Error 6001, were belonging to "anonymous users" (not logged users).

So, by making a few attempts, we find out this thread in Shaka issues: #1928, which reports that EME are not available in Chrome Incognito, which might fit for the reason most of the issues belong to anonymous users.

This was quite challenging to understand because we had to check for patterns among the QA reports.

And this does not ends here, because we'll have to investigate further for 6001 on other different devices.

Current documentation says:

None of the requested key system configurations are available. This may happen under the following conditions:

    The key system is not supported.
    The key system does not support the features requested (e.g. persistent state).
    A user prompt was shown and the user denied access.
    The key system is not available from unsecure contexts. (i.e. requires HTTPS) See https://bit.ly/2K9X1nY 

But this is not very helpful. I mean, missing EME support is not in these cases. It also seems that patching failed.

Describe the solution you'd like

I'd like to have more details on what explicitly caused the error in the 6001 error itself or, instead, having different errors for the matters above (or at least a different error code for missing EME).

Describe alternatives you've considered

None

Additional context

I'd like to attach you a screenshot that has been snapped while checking the issue on Samsung with Android 12 and latest Chrome.

Thank you very much!

[joeyparrish]

I don't know of any way to differentiate between the cases mentioned in the error code docs. They all result in a Promise rejection.

If you know of a way to get more information and differentiate between those cases, please let us know! I would be happy to split that code if there was a way to do it.

To get more details on this particular platform (Chrome + Android + incognito), please visit this page and copy-paste the output here: https://shaka-player-demo.appspot.com/support.html That will help us see what the browser reports support for.

Thanks!

[alexandercerutti]

Thank you for your reply! Support page is really interesting. I will be able to dig down further on the next week. In the meanwhile I performed an analysis, which I hope will be interesting for the future.

I saw from MDN that navigator.requestMediaKeySystemAccess can fail with a DOMException NotSupportedError error, but it actually doesn't contain enough details to distinguish what happened.

The only thing we might assert, I guess, is that IF navigator.requiredMediaKeySystemAccess === undefined, EME is not supported. But I see Shaka Polyfills in action here that might override the function and make this statement false.

---

About iFrames without allow="encrypted-media *;", Standard reports:

If this's relevant global object's associated Document is not allowed to use the encrypted-media feature, then throw a "SecurityError" DOMException and abort these steps.

I've tried on Chrome and Firefox. While Chrome seems to honor this, Firefox doesn't (it doesn't support encrypted-media at all, but I hope that once they will, they will implement the standard with SecurityError).

Firefox:

Chrome:

(I've expanded error because SecurityError has code 18, according to this page)

So I think this check might get integrated. What do you think?
Safari doesn't support allow="encrypted-media *; as well.

---

About unsecure context, standard refers what follows:

This method is only exposed to secure contexts [SECURE-CONTEXTS] as indicated by the [SecureContext] IDL attribute.

Sadly Firefox doesn't honor this too (it is a deprecated behavior) and, if I visit for example http://info.cern.ch/ and try to use in console navigator.requestMediaKeySystemAccess, I can still use it (same code as above).

In Chrome this behavior is honored and it is undefined as expected.
I don't know (yet) how does Safari work with this.

---

About persistent license and checking if a keySystem is not supported, I don't have any idea.
I mean, might they considered regular failures?

---

Might it be worth to separate checks on these points, by browser?

[alexandercerutti]

Hey @joeyparrish, I've been able to perform a test on Android + Chrome + Incognito on the page you linked me. Here below the result.

Open details

Mozilla/5.0 (Linux; Android 8.1.0; DUB-LX1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.125 Mobile Safari/537.36
v4.2.1
{

	"manifest": {

		"application/dash+xml": true,

		"video/vnd.mpeg.dash.mpd": true,

		"application/x-mpegurl": true,

		"application/vnd.apple.mpegurl": true,

		"application/x-offline-manifest": true,

		"mpd": true,

		"m3u8": true,

		"application/vnd.ms-sstr+xml": false,

		"ism": false

	},

	"media": {

		"video/mp4; codecs="avc1.42E01E"": true,

		"video/mp4": true,

		"video/mp4; codecs="avc3.42E01E"": true,

		"video/mp4; codecs="hev1.1.6.L93.90"": false,

		"video/mp4; codecs="hvc1.1.6.L93.90"": false,

		"video/mp4; codecs="hev1.2.4.L153.B0"; eotf="smpte2084"": false,

		"video/mp4; codecs="hvc1.2.4.L153.B0"; eotf="smpte2084"": false,

		"video/mp4; codecs="vp9"": false,

		"video/mp4; codecs="vp09.00.10.08"": true,

		"video/mp4; codecs="av01.0.01M.08"": true,

		"audio/mp4; codecs="mp4a.40.2"": true,

		"audio/mp4": true,

		"audio/mp4; codecs="ac-3"": false,

		"audio/mp4; codecs="ec-3"": false,

		"audio/mp4; codecs="opus"": true,

		"audio/mp4; codecs="flac"": true,

		"video/webm; codecs="vp8"": true,

		"video/webm": true,

		"video/webm; codecs="vp9"": true,

		"video/webm; codecs="vp09.00.10.08"": true,

		"audio/webm; codecs="vorbis"": true,

		"audio/webm": true,

		"audio/webm; codecs="opus"": true,

		"video/mp2t; codecs="avc1.42E01E"": false,

		"video/mp2t": false,

		"video/mp2t; codecs="avc3.42E01E"": false,

		"video/mp2t; codecs="hvc1.1.6.L93.90"": false,

		"video/mp2t; codecs="mp4a.40.2"": false,

		"video/mp2t; codecs="ac-3"": false,

		"video/mp2t; codecs="ec-3"": false,

		"text/vtt": true,

		"application/mp4; codecs="wvtt"": true,

		"application/mp4": true,

		"application/ttml+xml": true,

		"application/mp4; codecs="stpp"": true,

		"audio/aac": true,

		"audio/ac3": false,

		"audio/ec3": false,

		"audio/mpeg": true

	},

	"drm": {

		"org.w3.clearkey": {

			"persistentState": false

		},

		"com.widevine.alpha": null,

		"com.microsoft.playready": null,

		"com.microsoft.playready.recommendation": null,

		"com.apple.fps.1_0": null,

		"com.apple.fps": null,

		"com.adobe.primetime": null

	},

	"offline": true

}

[avelad]

@alexandercerutti are you interested on send a PR to improve it? Thanks!

[alexandercerutti]

Hi @avelad, when I opened this task I attempted to look for ways to get more details but I failed and then things lost priority.

I'd like to, but I don't think I have enough time to put into this, also because we have the upgrade from Shaka v3 to Shaka v4 almost ready, but it is still halted there, waiting for it to ship in production. :/

[avelad]

@alexandercerutti do you have any new? Thanks!

[alexandercerutti]

Sorry, I don't. We didn't have time to investigate. We barely been able to upgrade v3 to v4 on one of two players I'm following.