Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify/correct handling of ClearKey protected content #3138

Closed
ojw28 opened this issue Aug 4, 2017 · 14 comments
Closed

Clarify/correct handling of ClearKey protected content #3138

ojw28 opened this issue Aug 4, 2017 · 14 comments

Comments

@ojw28
Copy link
Contributor

ojw28 commented Aug 4, 2017

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
Copy link

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
Copy link
Contributor Author

ojw28 commented Aug 4, 2017

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
Copy link

sandersaares commented Aug 4, 2017

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
Copy link
Contributor Author

ojw28 commented Aug 4, 2017

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
Copy link

sandersaares commented Aug 4, 2017

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
Copy link
Contributor Author

ojw28 commented Aug 4, 2017

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
Copy link
Contributor Author

ojw28 commented Aug 4, 2017

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
Copy link
Contributor Author

ojw28 commented Aug 4, 2017

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).

ojw28 added a commit that referenced this issue Aug 7, 2017
Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164434858
ojw28 added a commit that referenced this issue Aug 7, 2017
Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164434858
@hishamMuneer
Copy link

@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.

ojw28 added a commit that referenced this issue Aug 8, 2017
Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164590835
@hishamMuneer
Copy link

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

@ojw28
Copy link
Contributor Author

ojw28 commented Aug 10, 2017

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
Copy link

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 added a commit that referenced this issue Aug 10, 2017
- There is a proper ClearKey UUID now. This change requires
  it to be used instead of the Common PSSH UUID when instantiating
  DRM components.
- Internally, we'll map the ClearKey UUID onto the Common PSSH
  UUID where necessary to (a) access the ClearKey CDM on older
  devices, and (b) access drm init data stored under the Common
  PSSH UUID in the stream.

Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164839213
ojw28 added a commit that referenced this issue Aug 29, 2017
This mapping when we call into platform components also needs
to be applied when creating the MediaCrypto instance. The fix
is to stop propagating the UUID through all the createMediaCrypto
methods. This is unnecessary, since the eventual target already
knows its own UUID!

Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166843372
ojw28 added a commit that referenced this issue Aug 29, 2017
@ojw28
Copy link
Contributor Author

ojw28 commented Aug 29, 2017

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 added a commit that referenced this issue Sep 6, 2017
- There is a proper ClearKey UUID now. This change requires
  it to be used instead of the Common PSSH UUID when instantiating
  DRM components.
- Internally, we'll map the ClearKey UUID onto the Common PSSH
  UUID where necessary to (a) access the ClearKey CDM on older
  devices, and (b) access drm init data stored under the Common
  PSSH UUID in the stream.

Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164839213
ojw28 added a commit that referenced this issue Sep 6, 2017
This mapping when we call into platform components also needs
to be applied when creating the MediaCrypto instance. The fix
is to stop propagating the UUID through all the createMediaCrypto
methods. This is unnecessary, since the eventual target already
knows its own UUID!

Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166843372
ojw28 added a commit that referenced this issue Sep 6, 2017
ojw28 added a commit that referenced this issue Nov 13, 2017
Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175006223
ojw28 added a commit that referenced this issue Nov 13, 2017
Issue: #3138

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175006223
@ojw28 ojw28 closed this as completed Nov 13, 2017
@ojw28
Copy link
Contributor Author

ojw28 commented Nov 13, 2017

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

@google google locked and limited conversation to collaborators Mar 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants