Introduction to the multi-DRM world on the platform side

Introduction to the multi-DRM world on the platform side

What is multi-DRM and why does it get so much attention lately? To answer this question we first have to make the definition of “platform” clear. There are many things that can be called platforms – the hardware of a device like a mobile phone of a particular manufacturer, an operating system such as Windows, a browser such as Chrome, and even software on which a specific video player runs, like Silverlight. All of these are equivalent where multi-DRM is concerned.

The various platforms usually have a DRM component embedded somewhere, either in the hardware, the operating system. The DRM component can also be part of some platform software created by a third party vendor, for example Google Chrome that incorporates a different DRM than the platform on which it is running on (e.g. Windows) but the Chrome DRM component can still be called native – native to Chrome platform.

The following list outlines some popular platforms and the respective DRM technologies they use.

Screen Shot 2015-06-17 at 14.55.53

Some players also embed a DRM component to play back videos protected with DRM technologies other than the native one. The intent is good but in practice it is much more advantageous to use the native DRM for each platform and the manufacturing of players with different than native DRM components is slowly declining anyway. For example, one such player is Microsoft’s PlayReady Client SDK which is a combination of player and DRM component that can be used to play PlayReady protected media on Android, whereas Android’s native DRM technology is Widevine. You can learn details about the pros and cons of the different approaches in future blog posts.


Browser-hosted modern players use the native DRM component via JavaScript and do not need any plugins to be installed. One such player is the DASH-IF reference player “dash.js” and there are others. These players require the browser to support the Encrypted Media Extensions (EME) JavaScript API and the browser to provide a suitable Content Decryption Module. The latter is the DRM component and is responsible for decrypting the media. Using EME the player can communicate with all the different CDMs, since EME defined a standard API. For example, Chrome includes a Widevine CDM while Internet Explorer includes a PlayReady CDM, both accessible using EME.

Considering all the details above, the multi-DRM world might seem confusing at first. In reality things have gone easier for both end users and also service providers/content owners. If there would be no standard EME API and CDMs, all the decryption should be done in a native player or in some browser plugin which is often cumbersome to install and does not provide the security that Hollywood studios mandate. Service providers like Axinom have taken care of creating a unified interface that uses the same business logic for different DRM technologies, so for our customers it seems as if there was only one DRM technology to support. And if we add to the mix the MPEG-DASH specification together with Common Encryption then there is also a single video container which needs to be encrypted and delivered. Playback is already native and the appropriate license for decryption is given automatically by a multi-DRM licensing service.