DRM: Enable more complex case than a single license request per content or a single per init data

Situation

Since the v3.24.0 (2021-04-01), the RxPlayer added the keySystems[].singleLicensePer option, allowing to signal that only a single license request, usually concerning only a single key for a content, will actually return a (or a group of, depending on the key system) license containing all the keys needed to decrypt the content.

This option is used a lot at Canal+ Group, to greatly reduce the number of HTTP requests to the license server in complex cases where contents need multiple decryption keys (for different qualities and / or type of data).

However, we now encounter a new case: on some contents, multiple keys exist but all might not be communicated in the initial license request. Either because future keys are not known yet, because there might be much more keys in a license than low-end devices are able to register at the same time, or both. How it will actually work is that the license server might return the keys for N DASH Periods, this N being variable in function of the limits of the device.

The simple singleLicensePer: "period" solution

Thankfully, this is a situation we prepared for in our design for the singleLicensePer API. We already thought about adding a singleLicensePerPeriod: "period" in the future leading to a license request every time a new Period with a yet-unknown combination of key ids is encountered.

Though the case here is a little more complicated. We are not talking about a single license per Period but about a single license per N Periods, with a variable N. Thus, comparatively to a simple singleLicensePerPeriod: "period" which would be for a single Period per default, we may need here to be more careful to check if keys for future/previous Periods have also been returned.

Keeping track of N

We could keep track of N when it is communicated in the client. But even just referring to it would be complex: is this N the amount of Periods in chronological starting from the one the license request is for, or a more complex arrangement? What if the same set of keys repeat for other Periods (we would prefer not to perform a license request here)? Also it might be difficult for an application to know what N is, as it is in fine decided by the license server (e.g. there might be a default value, or it might have less keys available than the ones asked for the N Periods).

singleLicensePer: "periods"? (with an s)

What I first envisioned we could do instead is to add a singleLicensePerPeriod: "periods" (with an s) option and to consider that a fetched license applies to both:

1. The Period containing the Representation for which the license request was for
2. All other Periods which contain a Representation linked to a key in the fetched license

Those points might be difficult to understand at first. I’ll try to re-phrase it more intelligibly.

The idea is to “detect” which Periods have all their compatible keys contained in the license. This can be hard as the license server might decide to voluntarily retain some keys because it does not trust the client enough for it to handle them (e.g. keys meant for Widevine L1 clients on an L3 client). We thus have incompatible data, hence the need to detect which Periods the fetched license is for.

Here the idea would be to first always assume that the license will contain all keys for the Period containing the Representation for which the license request was for. It makes sense after all, we requesting a license for a specific quality so we expect at least to have that - and because we’re in a per-Period mode, we expect compatible keys for the full Period to be in that license.

However even considering just that could be not so straightforward: what if a key was used for several Periods, each combining a different set of keys (e.g. for different qualities)? Here, if a key is linked to multiple Periods, the license server might not even “know” which one we are considering (in the player) right now, and so by extension, which group of keys it should send. Going into that route leads to many problems so I’m always assuming here that when and if there’s ambiguity, the license server return keys for all those Periods.

Because the returned license might also contain keys for other Periods, we also could infer those by looking at the key ids contained in the license once it is pushed (retrievable through the MediaKeySession.keyStatuses property) and consider that as soon as a single Representation is linked to one of these key-id, then the licence contains keys for the whole Period containing that Representation. Again, if that last point was not true, we would be left with the same ambiguity that what I exposed earlier.

Do you have thoughts on this or better proposals ?

[peaBerberian]

I think we are on the same page for the implementation. I was also considering the “different Periods with both common and different keys” too ambiguous here, so I also prefer explicitly forbidding it (as a not-handled usage in the corresponding API documentation) in that mode.

Regarding the way to configure this in the rxplayer, are you proposing to introduce a new parameter named singleLicensePerPeriod (i.e. different from the existing one called singleLicensePer) ?

I was just thinking that a singleLicensePer: "periods" (with an “s”) would be sufficient. Its documented behavior being what we’re agreeing on:

• A fetched license apply both to the Period of the Representation for which the license request has been performed and to any other Period containing at least one Representation whose key is found in that license (technically: its key-id is in the corresponding MediaKeySession’s MediaKeyStatusMap).

Because Period is mostly a DASH concept, and because we’re handling multiple types of transports, the notion of Period will be translated as such:

• "dash": <Period> element
• "smooth": whole content
• "directfile": whole content
• "local-manifest" (downloaded contents): period object
• "metaplaylist" (client-side relinearization proof-of-concept we’re still maintaining): Period concept of each wrapped content (each content being at least one separate Period)

[peaBerberian]

#1061 has been merged. The singleLicensePer: "periods" keySystems option should be available in the v3.27.0 version that we plan for next week for now.

It has been succesfully tested on some tested contents where there was one license per period (there’s still another case to really test however: a license for multiple periods)