Support in-manifest LAURL for ClearKey about rx-player HOT 4 OPEN

I can confirm that parsing of dashif:laurl is broken.

The code to iterate over prefixes was removed from CommonEncryption.js (Dash-Industry-Forum/dash.js#4406 - 6.Feb.2024). Specifically, it now uses contentProtection.laUrl != null to test for presence of a valid license-server url, which relies on the manifest parser to do case conversion to DashConstants.LA_URL in CodeProtection::init(). This isn't happening so dashif:laurl is not handled.

The code discussed in Ticket Dash-Industry-Forum/dash.js#3343 is never executed now.

See https://content.media24.link/Leaf/stream.mpd

This patch fixed it for me:

`--- a/src/dash/vo/ContentProtection.js
+++ b/src/dash/vo/ContentProtection.js
@@ -59,6 +59,7 @@ class ContentProtection extends DescriptorType {
this.pssh = data.hasOwnProperty(DashConstants.PSSH) ? data[DashConstants.PSSH] : null;
this.pro = data.hasOwnProperty(DashConstants.PRO) ? data[DashConstants.PRO] : null;
this.laUrl = data.hasOwnProperty(DashConstants.LA_URL) ? data[DashConstants.LA_URL] : null;

•        this.laUrl = this.laUrl || (data.hasOwnProperty('laurl') && data['laurl'])
  

`

from rx-player.

Hi, attempting access to above DASH manifests through the URLs you provide yields 403 HTTP status.

from rx-player.

Hi, attempting access to above DASH manifests through the URLs you provide yields 403 HTTP status.

I think you have to be in Sweden or use a VPN service simulating being in Sweden.

from rx-player.

Hi @stephanterning,

I guess this is a new feature though it could be interesting, at least to better handle clear-key contents.

It looks like we may (not sure!) need to do two things here:

1. generate the initialization data ourselves (potentially? there are several clearkey key systems defined in https://dashif.org/identifiers/content_protection/, and the dash.js code talks about a potential pssh, so maybe this is not even needed here, we would have to look at the MPD and/or segments - is there a <cenc:pssh> element in the MPD? Is there a PSSH box in the MP4? "pssh" is encoded as an ASCII value in a ".mp4" so can be seen in the binary data, it is most likely in the initialization segment)
2. Rely on the license server url announced in the MPD (even here, is it always required? You don't know it in advance?)

Its specification (https://www.w3.org/TR/encrypted-media/#clear-key) mainly talk about a "Licence Request Format" and of a "License Format", which is nice but looks like browser matters, what would most likely interest us here is how to format what's called the "init data" that is communicated to the browser so it communicates back to us the "License Request Format" (though it can be known from the beginning here, but I don't think we're supposed to skip the generateRequest call so let's play along and act surprised when data comes back).

Though the dash.js implementation here is clear (https://github.com/fraunhoferfokus/dash.js/blob/fbc786ae6177537a03820ef8326fddbe86dd1ba4/src/streaming/protection/drm/KeySystemClearKey.js#L82) and seems to indicate that it is roughly the same than the "Licence Request Format" (only it omitted the type property from it):
It's a JSON (UTF-8 encoded) with a kids property set to an array of the Base64Url representation of the key ids of all wanted keys.
In the MPD, key ids are represented in the cenc:default_KID attribute on the <ContentProtection> element, as hexadecimal hyphen-separated values. Here we would have to decode that value and then switch them to the equivalent base64Url encoding before putting them in the kids array.

dash.js seems to do hex-> JS string (through String.fromCharCode) -> Base64 (through btoa) here (which is strange because they are here generating Base64 and not Base64Url - they remove = padding but do not replace + by - and / by _. I don't know if it's a bug or if it's unnecessary here).
I cannot see your MPD, but they also prefer to rely on the `ContentProtection's pssh instead of that generated JSON if there's one also in the MPD (what I get from https://github.com/fraunhoferfokus/dash.js/blob/fbc786ae6177537a03820ef8326fddbe86dd1ba4/src/streaming/protection/drm/KeySystemClearKey.js#L84).

As for the second part of that implementation which would be to rely on the license server URL found in the MPD, it doesn't look too hard either and could be communicated if found through a third getLicense argument (how it gets to there inside the RxPlayer code is another subject, but it still looks doable). We could also be doing the license request ourselves but for those matters I prefer to let the application in control.

So in conclusion, this is a new feature for the RxPlayer but it seems doable and standard enough to be integrated.

from rx-player.