Getting Started: Adding DRM support to your application
1. Playing media: The HTMLMediaElement
The HTMLMediaElement interface adds to HTMLElement the properties and methods needed to support basic media-related capabilities that are common to audio and video. The HTMLVideoElement and HTMLAudioElement elements both inherit this interface. See https://developer.mozilla.org/en/docs/Web/API/HTMLMediaElement for more info.
2. Streaming media: Media Source Extensions (MSE):
We can load, decode and play media simply by providing a src URL:
3. Adaptive streaming of media: Dynamic Adaptive Streaming over HTTP (DASH)
The idea is to be able to adapt our video streams based on present circumstances, for example fluctuating bandwidth, etc. DASH allows us to dynamically adapt our video streams over time. This can be done in several ways, DASH is one of them. The 2 main other APIs are HTTP Live Streaming (HLS) developed by Apple and Microsoft Smooth Streaming (MSSS) developed by Microsoft. Both HLS and MSSS are proprietary, however, DASH is an open standard due to which it is the most popular (used in Youtube TV for example).
4. Encrypting your streamed media: Encrypted Media Extensions (EME)
This is where Digital Rights Management (DRM) starts to come in. Simply put, Encrypted Media Extensions (EME) provides an API that enables web applications to interact with content protection systems, to allow playback of encrypted audio and video. It is an extension to the HTMLMediaElement specification, hence the name. There are 2 types of EME support available: prefixed and un-prefixed. EME spec versions 0.1b and earlier are informally called prefixed EME while later implementations are called un-prefixed. This is because function calls in the older versions of the EME spec were prefixed with the browser vendor name (ex: msSetMediaKeys, webkitAddKey, etc) while the newer versions have a universal API which is browser-independent and thus un-prefixed.
Applications that use EME normally have the following components:
- A Keys System: In order to decrypt the encrypted media, we need some kind of a key system. This is where DRM technologies come into play. EME does not mandate a particular key system, but does mandate that browsers implementing EME support implement Clear Key. The most popular Key systems are Widevine maintained by Google and Playready by Microsoft.
- A Content Decryption Module (CDM): In order to be able to decrypt and ultimately play the video on device, a Content Decryption Module (CDM) must be present on the device. This can be in the form of a software or hardware implementation.
Here is a table with a list of the supported key systems for different Vewd Core and EME versions (taken from here):
(Draft 04 February 2016)
Refer to this excellent article for a more thorough understanding of EME.
5. Choosing your Licensing Technology: DRM Backends
Now that you understand how EME works with a Keys system and a License server, it is time to select which licensing technology you want to use:
- Microsoft Playready
- Google Widevine
Vewd based browsers may support both PlayReady and Widevine, depending on capabilities of the platform integration. So your application needs to be tested on each device to make sure DRM playback works on that device. Unfortunately, our 4.x based Emulator does not provide PlayReady or Widevine support at the moment and we recommend testing your application on an Android based device (for example the NVidia Shield and Google Nexus TV) to test these out. Clear Key, however, is always supported internally by the Vewd Core and you can test it on any platform. This information is summarized in the table below:
|Vewd TV Emulator 4.x||Not supported||Not supported|
|Nvidia Shield/Nexus Player||Up to security level 2000||Up to security level L1|
|Other devices||Dependent on device|
Dependent on device
Automatic Streaming & DRM Playback Methods
- Microsoft Smooth Streaming (MSSS): http://something/something/Manifest
- Http Live Streaming (HLS): http://something/something.m3u8
- Dynamic Adaptive Streaming over HTTP (DASH): http://something/something.mpd
For example, in order to automatically playback a video via Microsoft Smooth Streaming, the following code should suffice:
In addition to these streaming technologies, the Vewd Media Player Module also supports using PlayReady Web Initiator. This is described in the next section.
PlayReady Web Initiator
Devices that support the Vewd Media Player Module also support PlayReady Web Initiator, where a license acquisition manifest file is passed as the source of a <source> element. This manifest file in return contains a link to a Microsoft Smooth Streaming (MSSS) manifest file along with the license acquisition information. Below is a simple test case with 2 files: index.html and LicenseAcquisition.xml which can be used to test PlayReady Web Initiator support on your device:
Here is a list of the common problems you might face when adding DRM support into your application:
|1||License request is not generated by CDM|
|2||License request is rejected by server|
|3||License is rejected by CDM|
|4||License is acquired correctly but video doesn't play (no decode error)|
- DCP EME tests: http://dcp.otvs.tv/ts/eme (ClearKey, PlayReady, Widevine)
- DCP DRM tests: http://dcp.otvs.tv/ts/drm (ClearKey, PlayReady, Widevine, PlayReady Web-Initiator)
- YouTube DASH player: http://yt-dash-mse-test.commondatastorage.googleapis.com/demo-player/dash-player-020416.html
- YouTube EME conformance: http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2017.html
- Vewd Certify for Apps Specification: https://developer.vewd.com/display/OTV/Certify+for+Apps
- Vewd Certify for Devices Specification: https://developer.vewd.com/display/OTV/Certify+for+Devices
- DRM vendors: DRM Support in Vewd Core and devices, DRM Support in Vewd Core and devices