{"id":1259,"date":"2022-02-01T11:34:53","date_gmt":"2022-02-01T10:34:53","guid":{"rendered":"https:\/\/websites.fraunhofer.de\/video-dev\/?p=1259"},"modified":"2022-02-01T11:34:54","modified_gmt":"2022-02-01T10:34:54","slug":"following-the-recommendation-key-system-string-priority-in-dash-js","status":"publish","type":"post","link":"https:\/\/websites.fraunhofer.de\/video-dev\/following-the-recommendation-key-system-string-priority-in-dash-js\/","title":{"rendered":"Following the “.recommendation” – Key system string priority in dash.js"},"content":{"rendered":"\n

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<\/a> and enabling hardware DRM on Android Chrome using the EME<\/a>. Quite recently, another interesting discussion<\/a> in the context of DRM popped up in the dash.js issue tracker. <\/p>\n\n\n\n

Different key system strings for Microsoft Playready<\/h2>\n\n\n\n

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

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:<\/p>\n\n\n\n

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<\/em> a recommendation – it was still in draft.
As a result, Microsoft implemented com.microsoft.playready<\/code> based on that draft spec. The EME spec changed substantially<\/em> 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.<\/p>

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<\/code> with robustness string 3000<\/code> if desired. But as soon as you start factoring in all the combinations of older implementations, things get wonky.<\/p>

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<\/code> (windows only) to force hardware DRM for video. If the key system string com.microsoft.playready.recommendation<\/code> is not supported, you can fall back to com.microsoft.playready<\/code> (or com.microsoft.playready.hardware<\/code>) 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.<\/p>https:\/\/github.com\/Dash-Industry-Forum\/dash.js\/issues\/3852<\/a><\/em><\/cite><\/blockquote>\n\n\n\n

There are three major takeaways from this statement:<\/p>\n\n\n\n