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 implementedcom.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 string3000
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
https://github.com/Dash-Industry-Forum/dash.js/issues/3852com.microsoft.playready.recommendation.3000
(windows only) to force hardware DRM for video. If the key system stringcom.microsoft.playready.recommendation
is not supported, you can fall back tocom.microsoft.playready
(orcom.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.
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
anddistinctiveIdentifier
.
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)!