Save your seat for Streaming Media NYC this May. Register Now!

Buyers' Guide to DRM 2017

Article Featured Image

If you plan to distribute premium content from the major U.S. studios, you’ll need to encrypt that content, which typically means that you’ll have to deploy one or more digital rights management (DRM) technologies. As you’ll learn in this article, while many aspects of the migration from plug-ins like Flash and Silverlight to HTML5 playback have simplified video distribution, the shift has made the DRM side much more complex, though new services and service models are available to help.

Before getting to the implementation side, let’s define DRM, and see what distinguishes it from other less-sophisticated content protection schemes like simple encryption. In essence, there are four components to DRM: digital rights to manage, encryption, license management, and a DRM-capable player.

Digital rights to manage: DRM technologies enable a broad range of business models (including purchase, subscription, rental, and gifting); enable playback on single and multiple platforms via streaming, downloading or side-loading; and provide playback restrictions that guard against or enable playing via HDMI outputs and the like.

Encryption: DRM technologies use encryption to protect the content prior to or during streaming, downloading, or other transfer.

License management: DRMs require a DRM platform to manage the request and issuance of licenses (Figure 1). Some also incorporate domain controllers, which manage the multiple user devices that can play content under a single license, and metering servers that track usage data and total plays for royalty purposes.

A DRM-capable player: The final element of DRM is a DRM-capable player that can communicate with the DRM platform and enforce all software-and hardware-related playback restrictions. For computer and notebook playback, some DRMs use an existing plug-in—like Adobe Access and Flash or PlayReady and Silverlight—while other technologies, like Google Widevine Classic, require a separate download, which is one of the reasons that Google has stopped updating this technology. As discussed in more detail later, the industry is moving from plugin-based DRM to browser-based DRM via the Media Source Extensions (MSE) and Encrypted Media Extensions (EME), where the DRM must be integrated into the browser.

On mobile devices, DRM support can come from the native browser or via a downloadable app. For example, iOS devices support Apple’s DRM FairPlay via the Safari browser, but you can use other DRMs if you distribute via a custom app. Typically, Smart TVs, OTT boxes, and other consumer electronic devices have one or more DRM technologies pre-integrated into the platform.

Before we get too deep into our discussion, let’s identify the major DRM technologies and companies on the periphery that provide critical DRM-related functionality.

The DRM Marketplace

Let’s start with companies supplying the actual DRM, some of which we’ve already discussed. The main streaming-related DRM providers are as follows:

  • Adobe Primetime: Adobe’s DRM started its life as Access before Adobe changed the name to Adobe Primetime DRM. The company has since reverted back to Access. Access is primarily accessed in the browser via Flash, or via HTML5 in Mozilla Firefox, but it is almost exclusive for companies that are also licensing the Adobe Primetime platform.
  • Apple FairPlay Streaming (FPS): FPS is Apple’s DRM for HTTP Live Streaming (HLS), and it works on iOS, Apple TV, and Safari on OS X. Apple licenses FairPlay to content owners and some premium platform operators. DRM vendors can offer FairPlay encryption and licensing, but they must get a certificate from the content owner, who in turn gets it from Apple.
  • Google Widevine: There are two versions of Widevine: Classic, which is available only via a downloadable player, and Modular, which works with HTML5 in Google Chrome and Android devices. As mentioned, Classic has been deprecated. Today, Modular only works with Dynamic Adaptive Streaming over HTTP (DASH), but soon it may support HLS under CENC.
  • DivX: Now owned by NeuLion, DivX has significant penetration in consumer electronics devices.
  • Intertrust Marlin: This open standard DRM is from the Marlin Developer Community, which was founded by Intertrust, Panasonic, Philips, Samsung, and Sony. It also focuses on consumer electronics devices.
  • Microsoft PlayReady: PlayReady works with the Silverlight player on older browsers, or with HTML5 on the latest versions of Internet Explorer (on Windows 8.1+) and Microsoft Edge. It is also used in the Xbox, as well as many other Smart TVs and OTT devices.
  • Veramatrix VCAS: This hybrid solution is for pay TV distributors that also wish to distribute to computers, mobile, and OTT devices.

Surrounding these core DRMs are a number of distribution and technology partners/service providers. As you learned, DRM needs a licensing function, and each DRM vendor provides these functions differently—some directly, some with a network of third–party, value-added resellers.

Many companies also touch the DRM workflow, from on-premises and cloud encoding vendors that encrypt the content files to player vendors that help develop video players that talk to the license servers to retrieve the decryption key and play the video file. We’ll look at some of these vendors and discuss how to choose a DRM technology after taking a deeper look at how DRM works.


Fig 1: Components of PlayReady DRM: Note that not all DRM technologies use the concept of domains. 

How DRM Works

Now that we’ve defined DRM, let’s take a quick look at how DRM technologies generally work, borrowing images from a DRM service named DRMtoday. The first step is to get the encryption keys from the DRM provider or create them and upload them to the DRM platform. These are used to encrypt the video, with the decryption key and associated metadata sent to a license server accessible by the player. This encryption prevents playback of the content without a decryption key, making it safe to transport to the end user via the internet.

For most DRMs, external products or services can perform the encryption and packaging shown in Figure 2. For example, cloud encoders like Encoding.com can communicate with a DRM platform to acquire encryption keys to encrypt and package the licensed content, as can many enterprise-level encoders like Elemental Encoder, Wowza Streaming Engine, and Telestream Vantage. In addition, most DRM services provide separate encoding tools to encrypt and package your video and send the key to the DRM Platform. Once encrypted, the protected content is delivered to a web server for distribution.


Fig 2: The first step in DRM is encryption. (Image courtesy of DRMtoday) 

When a customer plays the content, the player sends the license request to the content owners’ proxy, which communicates with an authentication process running on the customer’s website. Once the customer’s website validates the user’s rights to the content, the proxy communicates with the DRM platform to create the license/ decryption key, which is then returned to the customer’s proxy and ultimately to the user’s player (Figure 3). In the case of content downloaded for offline playback, this verification also occurs before the download, with any playback rights and restrictions transmitted as well.


Fig 3: To play the video, the DRM player needs the decryption key from the license server. (Image courtesy of DRMtoday) 

Now let’s take a quick look at how DRM works in a browser-based environment, and the transition from plug-ins to HTML5.

From Plug-in to HTML5

In the past, the DRM player was typically a plugin like Flash or a separately downloaded player like Widevine Classic. Over the last 2 years, several standards-based technologies have been implemented to enable the browser itself to function in this role. While individually these technologies may seem technically complex, as you’ll see, the big picture is easy to grasp. These technologies are as follows:


MSE is a W3C HTML Working Group specification for a JavaScript interface to play back media data. Browsers and devices that support MSE can play back chunks of video (or byte-range requests for video segments within a single file), which enables both live and VOD playback of adaptive bitrate streams, complete with closed captions. While the original HTML5 video tag enabled progressive download of a single MP4 file, MSE enables full adaptive streaming.


DASH is a standardized file format for HTTP-based adaptive streaming that is similar in form and function to Apple’s HLS or Microsoft’s Smooth Streaming. Like all HTTP-based adaptive streaming technologies, there are two types of files in the final output packaging: fragmented video files (or byte-range requests for segments within a single file) and manifest files, which identify the location of the various streams in the adaptive group and the location of the chunks or byte-range requests of the individual segments. In use, most DASH content consists of separate MP4 files (one for each encoded stream in the adaptive group), and MPD (Media Presentation Description) manifest files.

MSE and DASH work hand in glove. That is, for a browser or device to play DASH files, it must support MSE. So MSE provides the playback capabilities, while DASH is one of the supported file formats that MSE can play.


EME is another JavaScript API that enables HTML5based DRM by extending MSE with application programming interfaces (APIs) to control the playback of protected content. EME works by incorporating what’s called a content decryption module, or CDM, into the browser, device, or mobile operating system, which allows the browser or device to communicate directly with the license server.


CENC details the standard encryption and key mapping techniques used to store the DRM-related data for one or more DRM technologies with the compressed audio/video data. As you’ll see, the ability to manage multiple DRMs is critical because most browsers or other devices will only support one DRM flavor, making multi-DRM support a necessity for most video producers.


ISO BMFF is a standardized file format that contains the DASH-encoded video, and CENC DRM metadata. These concepts come together in Figure 4, a slide from a presentation by BuyDRM at Streaming Media West 2014. On the left is the ISO BMFF, which contains the DASHencoded content and CENC DRM information for three DRMs. This information is delivered via the cloud to an EME-compatible browser that communicates with the appropriate license server (1, 2, or 3, but not all three), and obtains the decryption key. Once decrypted, the DASH data is played back via MSE.


Fig 4: The nuts and bolts of DRM operation in HTML5 (Image courtesy of BuyDRM) 

Streaming Covers
for qualified subscribers
Subscribe Now Current Issue Past Issues
Related Articles

Protecting Your Assets: How Studios Secure Their Premium Video

Piracy will always be a problem, but new advances in DRM and watermarking are making headway in the never-ending global battle.

Status Update: Encrypted Media Extensions and the Future of DRM

While publishers wait for a single content encryption system that works across all browsers, standards bodies debate the future of EME. Here's what rights management will look like in a post-plugin world.

What Is DRM?

The move away from plugins like Flash and Silverlight has made video delivery easier, but it's also made DRM more complicated. Here's what DRM looks like today, along with a discussion of the leading DRM technologies and DRM service providers

Buyer's Guide to DRM 2016

A simple guide through the complex landscape of multiple DRM technologies. Learn what DRM is, and how to choose and deploy the best solution for each platform.

Companies and Suppliers Mentioned