Following the “.recommendation” – Key system string priority in dash.js

As part of our work on dash.js we are involved in numerous interesting discussions and face various exciting problems. Digital Rights Management (DRM) is definitely one of the most challenging areas in the context of Adaptive Bitrate (ABR) streaming and player development. In our previous blog posts, we addressed the issues of supporting different versions of the EME and enabling hardware DRM on Android Chrome using the EME. Quite recently, another interesting discussion in the context of DRM popped up in the dash.js issue tracker.

Different key system strings for Microsoft Playready

Using the Encrypted Media Extensions (EME), media players need to call the navigator.requestMediaKeySystemAccess function to obtain access to a key system. As part of the call to navigator.requestMediaKeySystemAccess a key system string must be provided. Typical key system strings to be used here are com.microsoft.playready for the Microsoft Playready DRM system and com.widevine.alpha for the Google Widevine DRM system.

Unfortunately the mapping of a key system string to an DRM system is not unique. For historical reasons, Playready supports different key system strings, all mapping to the same content protection schemeIdUri. Sam Wenker from the Microsoft PlayReady team gave some interesting insights on this:

The reason for having two key system strings for PlayReady is because Microsoft had major customers requesting EME support long before the EME spec became a recommendation – it was still in draft.
As a result, Microsoft implemented com.microsoft.playready based on that draft spec. The EME spec changed substantially after that implementation was released – so much so that there was no way to modify the existing implementation to be compatible with both the final recommendation spec and existing websites – Microsoft had a choice of either breaking existing websites or not being spec compliant, and we chose the latter. Since EME provides no way to specify additional key-system-specific data in the MediaKeySystemConfiguration, we had no choice but to create a new key system string for the new, spec-compliant implementation.

Unfortunately, that does add a number of nuances to how PlayReady is used. If you’re only dealing with recent Windows OS, recent Edge, and recent third-party browsers built on a recent PK and not doing anything unusual with the key system string in their implementations (where “recent” is relative in all cases), it’s pretty simple – com.microsoft.playready.recommendation with robustness string 3000 if desired. But as soon as you start factoring in all the combinations of older implementations, things get wonky.

Edge on Windows should properly map 3000 to hardware DRM. If you’re having trouble getting that to work properly, you can also use the key system string com.microsoft.playready.recommendation.3000 (windows only) to force hardware DRM for video. If the key system string com.microsoft.playready.recommendation is not supported, you can fall back to com.microsoft.playready (or com.microsoft.playready.hardware) for the legacy implementation. However, the legacy implementation has many incompatibilities with the EME spec, and we may remove support for it entirely in the future. I strongly recommend against using the legacy implementation under any circumstances.

https://github.com/Dash-Industry-Forum/dash.js/issues/3852

There are three major takeaways from this statement:

• Depending on the platform, multiple Playready key system strings can be supported.
• Clients shall use com.microsoft.playready.recommendation whenever possible.
• Application providers and dash.js users need full flexibility to account for the various possible combinations of key system string and other DRM configuration options such as persistentState and distinctiveIdentifier.

dash.js 4.3.0 – Key system string flexibility

With dash.js version 4.3.0 we introduce full flexibility in terms of the key system string configuration. In addition to specific configuration parameters such as persistentState and distinctiveIdentifier dash.js users can define a DRM system specific systemStringPriority:

"protData": {
    "com.widevine.alpha": {
        "serverURL": "https://someurl.com",
        "systemStringPriority": ["com.widevine.something", "com.widevine.alpha"]
    },
    "com.microsoft.playready": {
        "serverURL": "https://someurl.com",
        "systemStringPriority": ["com.microsoft.playready.recommendation","com.microsoft.playready"]
    }
},

Following the recommendation from Microsoft, we are also moving to com.microsoft.playready.recommendation as the default key system string for the Playready DRM system. If com.microsoft.playready.recommendation is not supported, we fall back to com.microsoft.playready.

We are confident that this addition will give dash.js user the required flexibility to achieve the optimal performance for the playback of their DRM protected content on the various possible end devices and platforms. A complete dash.js example showcasing the new configuration options can be found here. If you require any further assistance on dash.js, or you identified problems or missing features in dash.js, please reach out to us on Github. Until then: Happy streaming and stay safe (encrypted)!