Digital Rights Management (DRM) - getting started with playback

Digital Rights Management (DRM) is a form of authentication, authorising and decrypting the playback of previously encrypted content, when correct credentials are provided. The full flow is described here

This brief guide describes how to set up the bitmovin PLAYER (Step5 and Step6) to play back encrypted content. It assumes you already have suitably encrypted content in your storage (Step4) - For details on the encoding process click here.

Its important to realise different devices require different security approaches. This is simply because the security is typically handled in hardware, and the manner of securing the device has evolved over time. We mostly see three standards used today "widevine", "playready" and "fairplay"; noting bitmovin supports others.

Which device supports which standards?

To simplify implementation, a myriad of multi-DRM vendors have entered the market. These vendors 'wrap' the standards and allow a single call to respond with the correct response for the device. Bitmovin partner with all the leading multi-DRM vendors.

the Bitmovin player talks to the multi-DRM vendors through actions defined in the player configuration. The player configuration tells the player what to do, it is mostly common across all the devices bitmovin supports, and it is normally represented as value-pairs placed into sections.

For example a player configuration would have a source section:

1source = {
2hls : "https....."
3poster : "https....."
4etc }

It would also have a drm section where the value-pairs to set the DRM authorisation exists Take a moment to explore the value-pairs associated with DRM and come back.

All the DRM standards require the definition of LA_URL. This is the licence server from where the multi-DRM provider sends you the key. You need to get this value from your multi-DRM provider.

Next comes the authentication Message , this is defined as the prepareMessage in widevine, the customData in playready, the certificateURL in fairplay.

PrepareMessage, customData and certificateURL are the respective first part of the pair. The second part of the pair depends on how your multi-DRM vendor has wrapped the standards.

• It will typically include a reference to the content, "I'm trying to play back contentId 12345". Normally the player extracts this information from a field burnt into the video manifest. Sometimes it will need cleaning up to meet the multi-DRM vendors implementation, often achieved with the prepareContentId in Fairplay implementations.

It will always require some kind of authentication:

• This will sometimes be a token, sent to authorise the request for a key. The bitmovin player does this through the headers and/or prepareMessage value-pair.
• This will sometimes be a token, base64encoded with the assetID
• This will sometimes be a token, converted to a binary Octet, with the assetID.

The bitmovin player can handle all these scenarios. In all cases the multi-DRM vendor must first share with you their desired authentication approach.

Code sample hints:

• Search for the name of your multi-DRM vendor in the search box above.
• Visit the bitmovin github example repositories,
• View the API documention for the device, and find the DRM section relating to widevine, playready and fairplay