Which DRM-related DASH interoperability aspects need clarification?

[sandersaares]

I am currently working on a change request for DASH-IF IOP to clarify interoperable behavior with regard to some DRM interactions in the player. My motivation for initiating that is to clarify one specific aspect that is implemented in non-interoperable ways in different players (multi-key content handling) but I thought that while the topic is under investigation, perhaps other aspects of DRM behavior could also be given a close inspection and clarified by DASH-IF, if appropriate.

Therefore, I would like to request input from player developers and player integrators here: are there DRM related aspects of DASH playback that could use clarification? Do you know of things that are unspecified or underspecified? What causes you headaches?

[joeyparrish]

Thanks for reaching out!

Can you help us understand what you mean about multi-key content handling? It would be useful for us to understand the issues you've already identified.

[sandersaares]

The multi-key issue is that there exists at least one player (ExoPlayer) that assumes requesting one key for a presentation (for one adaptation set) will cause the DRM system to make the keys for all encrypted adaptation sets available. This I believe is contrary to DASH-IF IOP, though it is rather implicitly stated by IOP at the moment and could certainly be spelled out more clearly. At the moment, I am in the process of proposing a change to IOP clarifying this aspect.

The workflow I envision on this topic would be that:

1. The player determines what keys it needs (via default_KID plus querying the CDM for already available keys, if such query function is supported).
2. The player requests the DRM system (CDM) to get all the keys the player needs but that are not available.
3. The DRM system makes one or more license requests to get these keys (ideally, batching all the key requests up all up into one license request).
4. The DRM system processes the license response(s) and notifies the player of the results (all keys need not become available, due to authorization decisions on the server side).

I believe present-day CDMs do not really implement features to batch up license requests, which is why there has been some desire in some places to do this "behind the scenes" key retrieval where requesting one key will actually return many of them (based on some content ID or whatnot in the PSSH). This, however, is not really interoperable and should be discouraged.

I have not had a chance to take a look at Shaka Player behavior in this regard - what interpretation does it conform to?

[joeyparrish]

I don't understand what you mean about ExoPlayer. Are you saying that one request results in multiple keys? Or that ExoPlayer assumes that this will always be the case?

Widevine can deliver multiple keys in one license response, on all platforms. Is this what you mean about "batching up"?

Shaka Player does not have any hard-coded knowledge of Widevine behavior, nor any other key system. We assume that multiple requests might be needed. We do not assume one key per request, nor do we assume multiple keys per request. We make one request per unique init data. The number of unique init datas should be less than or equal to the number of unique key IDs.

Depending on how the init data was created, this may result in redundant Widevine licenses (which the Widevine CDM can handle gracefully). We can't read the provider-specific payload of the init data, so we don't know what we are actually requesting based on that init data. If the Widevine payload has a content ID that maps to multiple key IDs, then the response may contain multiple keys.

[sandersaares]

What I meant with regard to ExoPlayer is that it appears to only ever make a single license request, even if multiple keys (as identified by default_KID and the appropriate Initialization Data) are needed to play the selected adaptation sets. It assumes that the license server will somehow know all the keys needed to play all the other adaptation sets, as well, and return them as a set, based on only this single request for a single key.

While it is possible to implement a license server that does this (e.g. by embedding a content ID in the PSSH), it is not really an interoperable way to use DASH. The player should ask the CDM to acquire every default_KID from the selected adaptation sets.

The batching up aspect I mentioned is more to do with the requests, not so much the responses - if the player sees that there are two adaptation sets, one with default_KID "X" and another with default_KID "Y", it knows that two content keys are needed. The player then informs the CDM that it wants to use these keys and requests that the CDM go get them, if needed.

However, there is not really anything in EME that allows one to provide the CDM two sets of Initialization Data at once - as soon as you provide Initialization Data for key X, the CDM will make a license request. Ideally, you would batch up the requests for both key X and key Y into a single license request (for optimization of network traffic and/or control flow in the player). In theory, one might concatenate the PSSH boxes and expect the CDM to understand what is happening but that sort of behavior is not guaranteed by EME, so may not be practical, especially across DRM systems. Hopefully a future version of EME can cover this gap in a standardized way. Considering how many HTTP requests video playback already makes, I think it is not a big deal to request each key individually, but it matters for some, so an optimization here probably should be enabled, hence my talk of batching.

From your description, it sounds like the Shaka Player works in an interoperable way with regard to multi-key content.

The triggering of license requests based on initialization data is perhaps a point of interest, though. The relationship of Initialization Data and EME appears to be still evolving, though based on today's situation I would probably take the view that it is best treated as an opaque blob to be handed over, not triggering any logic by its presence or content (with the default_KID being the trigger for the player's DRM behavior). Reading meaning into PSSHs seems dangerous. Do you have a particular reason for basing the logic on the Initialization Data difference?

I remember a case with dash.js, which also uses the same (Initialization Data based) logic, where this became a problem. For whatever reason, the content workflow created different PSSHs for the same content key in different places (manifest VS init segment, I believe?), which led to two license requests. One of those was rejected by the license server (it only expected one), leading to playback failure, despite actually getting a license in the other request. The content of the PSSHs is entirely in the DRM domain, so one cannot really say that such content is wrong in any way. Probably better error handling logic in the player could have survived this situation gracefully, by using the license that was provided in the other response. Yet, considering the big picture, it should be possible for people to make players without thinking deeply about such edge cases, if they follow interoperable specifications. If dash.js had based its logic on default_KID, it would have survived this issue.

[joeyparrish]

We filter out duplicate init data exactly because we can't read meaning into PSSHs. Generically, we can't read key IDs out of init data. PSSH v0 is still in wide use, and it does not contain key IDs in any generic form across key systems. PSSH v1 makes this better by providing a generically-parseable set of key IDs, but we don't see it in wide use because it seems that some devices don't support it. (I don't have specific data on PSSH version support in devices.)

Two dissimilar PSSHs may contain the same key IDs, but two identical PSSHs definitely contain the same key IDs, content IDs, whatever, and can obviously be filtered out.

It would be better if we filtered based on key IDs in the manifest, but those are not always provided. We could start requiring them in Shaka Player for DASH content, but we would not be able to do that unless there was an equivalent in HLS (which we are actively working on).

I think best-effort for Shaka Player would be:

1. Filter out duplicate init data from any source (we do this now)
2. Filter out init data from the manifest based on duplicate default_KID, if present (we do not do this currently)

[joeyparrish]

I should also mention that filtering out duplicate init data is something we only do as an optimization. It should not be strictly necessary, as having two MediaKeySessions containing the same keys is a non-issue on the client side.

So, although I see the benefit in improving this filtering logic to make use of default_KID when available, it is not a high priority for us at this time. I just filed it as issue #580.

[joeyparrish]

@sandersaares, is there anything else you feel needs discussion here? Or are we okay to close this issue?

[sandersaares]

I got some good feedback here. Sounds like we can close this. Thanks!