Clarify/correct handling of ClearKey protected content

[ojw28]

I'm not convinced our handling of ClearKey content is correct. We currently define the clear-key UUID as:

1077efec-c0b2-4d02-ace3-3c1e52e2fb4b

But there's also a ClearKey UUID:

e2719d58-a985-b3c9-781a-b030af78d30e

We should probably be doing something with that.

I'm also pretty unclear what would be necessary to get content like https://media.axprod.net/TestVectors/v7-MultiDRM-SingleKey/Manifest_ClearKey.mpd working.

@sandersaares, have you ever managed to get your ClearKey samples working on Android? I could be wrong, but I have a feeling that the ClearKey CDM requires a PSSH box to be passed to MediaDrm.getKeyRequest. I don't see a PSSH box available either in the manifest or the stream. Any help would be appreciated. Thanks.

[sandersaares]

Historically, there were some "clear key" labelled test videos floating around some years ago which used the W3C Common PSSH and systemID. Some players therefore started to interpret this as "Common PSSH means clear key", which is not intended by the W3C specifications as far as I can tell - the Common PSSH is just an abstract way to pass a key ID and does not add any further meaning or DRM system implications.

As some of us noticed in 2016 that this could become a problem and point of confusion, especially with signs of the W3C Common PSSH being more widely used in the future, we moved to define a specific system ID and specific guidelines for Clear Key usage in the DASH-IF IOP document. IOP v4.0 section 7.6.2.4 specifically addresses the connection with the W3C Common PSSH and outlines a basic manifest-based signaling mechanism.

The Clear Key guidelines are further clarified in 4.1, removing some ambiguity. IOP v4.1 is currenly in a 30-day internal DASH-IF review period.

I am not aware of any player that currently implements the IOP-defined Clear Key signaling mechanism, however. It would be great to see a player implementing the IOP mechanism for Clear Key and helping remove potential confusion from the universe, so please let me know if I can do more to assist here.

As for PSSH usage by Clear Key CDM implementations - well, EME says they should support the "keyids" JSON message as the initialization data but leaves the rest open. From a DASH-IF perspective, we wanted to deliberately break the connection that W3C Common PSSH means Clear Key because there is really no standards-based reasoning backing that.

I would view the situation as comprised of two parts:

1. The player should use the IOP signaling to detect that Clear Key is to be used.
2. The player should use the browser signaling to activate Clear Key. If the browser requires a PSSH of any sort to accomplish this, the player should synthesize such a PSSH based on the data in the DASH manifest (e.g. the default_KID).

This way browser idiosyncrasies can be cared for and uncomfortable PSSH implications avoided in the content.

The same approach could also be applied to non-clearkey CDMs in many cases - often the PSSH just contains the key ID and what is the point of passing the key ID in multiple formats in the manifest. DRM-system-agnostic content could be achievable in large part if the players synthesize the DRM initialization data (which they often can)! But this is perhaps going too far off topic :)

[ojw28]

Thanks for the detailed response! So to paraphrase (mainly to make sure I understand the above correctly), we should expect your Clear Key test stream to work if we:

1. Parse <ContentProtection value="ClearKey1.0" schemeIdUri="urn:uuid:e2719d58-a985-b3c9-781a-b030af78d30e"> from the manifest and therefore recognize that Clear Key is used.
2. Parse <ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc" cenc:default_KID="9eb4050d-e44b-4802-932e-27d75083e266" /> from the manifest and construct a PSSH box from it to feed to the ClearKey CDM.

And furthermore, we should repeat these steps for other schemes too, in the case that the ContentProtection elements corresponding to those schemes don't contain their own initialization data.

Does that sound right?

[sandersaares]

That sounds about right, assuming that the CDMs you target require a PSSH here - this would likely be CDM-implementation-dependent. The JSON "keyids" initialization data might also be suitable depending on the CDM, for example. At least, EME has a "should" for that one - the strongest (and only) wording I could find in any spec for activating the Clear Key CDM.

The DASH manifest may also contain an optional URL for the clear key license server, which may be relevant if the player does not have any overriding URL configuration from the app.

Applying this initialization-data-synthesis logic to other schemes is something that I personally consider useful in terms of moving the industry toward DRM-agnostic content. It is not really anything touched by DASH-IF or any other industry specification as far as I know. Just something that I would implement if I were making a player, to make it maximally easy to consume encrypted content. Certainly not required by any spec or standard.

Edit: oh, this is ExoPlayer. I did not notice what repo I was in. So EME might not be 100% relevant, I suppose!

[ojw28]

I had a try synthesizing a V1 pssh box, and was able to successfully pass it to the ClearKey CDM to generate a key request. However when I try and make the request to the license server, I get an http status code 500 back.

The request is a post request and looks like:

URL
https://drm-clearkey-testvectors.axtest.net/AcquireLicense

Headers
X-AxDRM-Message: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJzaW9uIjoxLCJjb21fa2V5X2lkIjoiYjMzNjRlYjUtNTFmNi00YWUzLThjOTgtMzNjZWQ1ZTMxYzc4IiwibWVzc2FnZSI6eyJ0eXBlIjoiZW50aXRsZW1lbnRfbWVzc2FnZSIsImtleXMiOlt7ImlkIjoiOWViNDA1MGQtZTQ0Yi00ODAyLTkzMmUtMjdkNzUwODNlMjY2IiwiZW5jcnlwdGVkX2tleSI6ImxLM09qSExZVzI0Y3Iya3RSNzRmbnc9PSJ9XX19.4lWwW46k-oWcah8oN18LPj5OLS5ZU-_AQv7fe0JhNjA
Content-Type: application/json

Body
{"kids":["EHfv7MCyTQKs4zweUuL7Sw"],"type":"temporary"}

where the body is the key request data obtained from the CDM.

Can you spot anything obvious in the request that would cause the 500 error, or is it possible that the license server is misbehaving? Thanks!

[sandersaares]

That request appears to be for a key with the ID 1077efec-c0b2-4d02-ace3-3c1e52e2fb4b which is not among the Axinom test vectors, as far as I know. I assume the error the server is encountering is one of a key not being found (though the error message could be improved for sure). Where is this ID from?

You can see the set of loaded keys at https://drm-clearkey-testvectors.axtest.net/Diagnostics

I will see if I can get the error messages from the clear key server to be a bit more user friendly. You will find the code at https://github.com/Axinom/clearkey-server in case you feel more productive running it locally. The CPIX files it uses for input are linked on https://github.com/Axinom/dash-test-vectors

Note that the X-AxDRM-Message header is not used by our clear key server. It should not hurt but it is simply ignored. No authorization is used for clear keys.

[ojw28]

Oops. That's the system id for the common PSSH box. I'm probably building my PSSH box wrong, and putting the UUID where I'm supposed to be putting the KID. I'll take a look.

[ojw28]

I fixed that and managed to get a response from the server:

[{"kty":"oct","k":"FmY0xnWCPCNaSpRG-tUuTQ","kid":"nrQFDeRLSAKTLifXUIPiZg"}],"type":"temporary"}

It looks like the CDM is unhappy with it though:

E JsonWebKey: Malformed base64 encoded content found.
E JsonWebKey: Failed to decode key(FmY0xnWCPCNaSpRG-tUuTQ)

[ojw28]

Looks like the CDM expects base64 encoding, where-as the response uses base64url encoding. Replacing the "-" with a "+" allows playback to proceed. I'm guessing this is a bug in the CDM (although not too hard to work around at the application layer).

[hishamMuneer]

@ojw28 As per the above conversation, can I deduce that you made the Clear Key working? If yes, please add the sample in the exolist.json or provide the steps you did in the chat below.

[hishamMuneer]

@ojw28 any possibility of adding a working sample of Clear Key in exolist.json?

[ojw28]

If this issue is still open, that means it's still being worked on. Repeatedly posting comments on the issue will not make us work any faster. Thanks.

[hishamMuneer]

Apology my friend. You added a commit after my comment, that's why i got confused. I ll try not to be unnecessary disturbance.

[ojw28]

Playback should now work in the dev-v2 branch, unless the key request/response happens to include a character that differs between base64 and base64url encodings. We need to put a workaround in place to account for the fact the platform's ClearKey CDM (incorrectly) uses base64 rather than base64url. This will be fixed in a future platform release, but of course we want playback to work on older platform versions too.

Keeping this issue open to track implementing the workaround described.

[ojw28]

ClearKey content should now be fully supported (in the dev-v2 branch and the upcoming 2.6.0 release).