Test Content Manifest Information for Encrypted Content

[haudiobe]

In order to start the process documented in clause "7.2.2 License Acquisition using the EME API", a set of information is necessary. We need to be able to store the relevant information in a test content manifest and preferably this is done using existing MPD elements and attributes. Input on this matter for the content model would be most useful.

[haudiobe]

(DPCTF 2019/07/31) Stefan Pham will check the test runner and content model for potential updates.

[squapp]

The following additional information is needed to trigger license acquisition using EME:

• keysystem string (e.g. "com.microsoft.playready.software", "com.widevine.alpha")
• license acquisition URL (laURL)
• auth token (optional. If the DRM server requires HTTP-header for authorization, otherwise URL parameters appended to the laURL are sufficient)
• server certificate (optional. If required by the DRM, it needs to be set via EME's setServerCertificate)
• robustness (optional. If required by the DRM, it needs to be set via EME's MediaKeySystemMediaCapability)

I believe these would be non-standard extensions to the ContentProtection element of an MPD. For the WAVE content model, I'd suggest to add them as attributes to the ContentProtection element of each DRM.

Example:

`

.... `

[squapp]

There is prior work in DASH-IF , which we can build on. However, it doesn't include all of the additional information as I proposed. I will check with sandersaares and make sure we are not re-inventing this

[sandersaares]

Copying here a few key points from call/email discussion.

License server URL and authorization token - reusable in DASH-IF proposed format

Server certificate URL - optional optimization. I am considering adding to DASH-IF proposal.

This leaves keystem string and robustness and introduces a bit of a snag: DASH "DRM systems" do not have a 1:1 mapping to EME "key systems"!

• One DRM system may exist as multiple key systems (e.g. playready.software and playready.hardware)
• There may be multiple variants (different implementations) of the same key system, selected based on the parameters in the MediaKeySystemConfiguration object (codec strings, robustness string, etc)

This mapping from a DRM system signaled in the MPD to a key system used via EME may be different depending on the device!

Furthermore, the appropriate "robustness" parameter to use for the same piece of content may be different depending on the device! For example, device A may expose H.265 decoder only with "robustness1" level, whereas device B may expose the same decoder only with "robustness2" level.

It is up to the DASH client to negotiate with the media platform (through EME) to dermine the appropriate value for the keysystem string and the robustness level, resolving the ambiguity that comes from different device implementation options.

The workflows for this negotiation are (partially) included in the DASH-IF proposal (to be further elaborated by me in near future).

I can understand a desire to have these values baked into the test content but considering the leeway that EME gives implementations, I consider this impractical and see the only meaningful course here to implement the necessary DASH client negotiation logic in the test harness.

If this were not so (if pre-determined values were to be used) implementations might fail a test even if they correctly conform to all WAVE and EME requirements. No doubt the developers of the device would work to "fix" this failure, which they might do by workarounds/adjustments specific to the test harness. This would be counterproductive to promoting standards-based behavior.

[haudiobe]

DPCTF call 2019/09/11: Discussion on robustness. It would be good to add a robustness testing parameters to MPD. Stefan has some ideas.

[squapp]

I'm trying to summarize the current status:

References:

[1] DASH-IF content protection guidelines

[2] Encrypted Media Extensions

[3] DASH-IF content protection identifiers

exists in DASH-IF

license acquisition URL

Section 8.3 of [1] introduces dashif:laurl

one or more dashif:laurl elements SHOULD be present under the ContentProtection descriptor, with the value of the element being the URL to send license requests to.

auth token

Section 8.3 of [1] introduces dashif:authzurl

one or more dashif:authzurl elements SHOULD be present under the ContentProtection descriptor, containing the default URL to send authorization requests to

not (yet) included in DASH-IF

keySystem string

requestMediaKeySystemAccess (see [2] Section 3.1) requires a keySystem string (e.g. "com.microsoft.playready.software", "com.widevine.alpha").

I could imagine a registry like [3], which includes the keySystem string for each DRM system.

This could then be added to the MPD as "one or more keySystem elements under the ContentProtection descriptor".

What do you think?

robustness

Section 6.1 of [1] explains the concept of robustness levels. The names of the robustness levels are specific to each DRM system.

Can we make an attempt to make robustness level names DRM-interoperable? I could imagine a registry like [3], so that "High robustness" = SL3000 = WV L1 or "Medium robustness" = SL2000 = WV L3

Independent from robustness level names, we could add "one or more robustness elements under the ContentProtection descriptor".

What do you think?

server certificate

Section 5 of [2] defines setServerCertificate. Certain DRMs (e.g. Widevine) require such certificates.

I think this has lower priority / is optional, since license acquisition will work even if a certificate is not set.

[haudiobe]

Check feedback from developers as well as the information provided by @wilaw

[gitwjr]

@haudiobe Please provide more information on what the developers feedback need to provide. Speak with Daniel.

[gitwjr]

Resolved for the second edition. May need to review for future releases.