-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Comments
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:
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 :) |
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:
And furthermore, we should repeat these steps for other schemes too, in the case that the Does that sound right? |
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! |
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:
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! |
That request appears to be for a key with the ID 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 |
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. |
I fixed that and managed to get a response from the server:
It looks like the CDM is unhappy with it though:
|
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). |
Issue: #3138 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=164434858
Issue: #3138 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=164434858
@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. |
Issue: #3138 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=164590835
@ojw28 any possibility of adding a working sample of Clear Key in exolist.json? |
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. |
Apology my friend. You added a commit after my comment, that's why i got confused. I ll try not to be unnecessary disturbance. |
- 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
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
Issue: #3138 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=166849631
Playback should now work in the Keeping this issue open to track implementing the workaround described. |
- 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
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
Issue: #3138 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=166849631
Issue: #3138 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=175006223
Issue: #3138 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=175006223
ClearKey content should now be fully supported (in the |
I'm not convinced our handling of ClearKey content is correct. We currently define the clear-key UUID as:
But there's also a ClearKey UUID:
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.The text was updated successfully, but these errors were encountered: