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.
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-enabled client.
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 sideloading, 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.
Figure 1. Components of PlayReady DRM. Note that not all DRM technologies utilize the concept of domains.
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 plugin—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 getting 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:
- Adobe Primetime—Adobe’s DRM started its life as Access, then Adobe changed the name to Adobe Primetime DRM, but they have since reverted back to Access. Access is primarily accessed in the browser via Flash, or via HTML5 in Mozilla Firefox, but almost exclusively for companies who 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 DASH, but soon may support HLS under CENC.
- DivX – Now owned by Neulion, DivX has significant penetration in consumer electronics devices.
- Intertrust Marlin—An open standard DRM from the Marlin Developer Community, which was founded by Intertrust, Panasonic, Philips, Samsung, and Sony. Also focused on consumer electronics devices
- Microsoft 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. Also used in the Xbox, and many other Smart TVs and OTT devices.
- Veramatrix VCAS—A hybrid solution 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-premise 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.
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 DRM Today. 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.
Figure 2. The first step in DRM is encryption. (Image courtesy of DRM Today)
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.
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 back down 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 occurs before the download as well, with any playback rights and restrictions transmitted as well.
Figure 3. To play the video, the DRM player needs the decryption key from the license server. (Image courtesy of DRM Today).
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 Plugin to HTML5
As mentioned, in the past, the DRM player was typically a plugin like Flash or a separately downloaded player like Widevine Classic. Over the last two 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:
Media Source Extensions (MSE)
Dynamic Adaptive Streaming over HTTP (DASH)
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 videos 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 fit together like 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.
Encrypted Media Extensions (EME)
Common Encryption Scheme (CENC)
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 Base Media File Format (ISO-BMFF)
ISO BMFF is a standardized file format that contains the DASH encoded video and CENC DRM metadata.
Figure 4. The nuts and bolts of DRM operation in HTML5. (Image courtesy of BuyDRM)
These concepts come together in Figure 4, a slide from a presentation by BuyDRM at Streaming Media West 2014 that is available here. On the left is the ISO BMFF, which contains the DASH encoded 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.
Now that you know the acronyms and how the plumbing works, let’s see how EME has fundamentally changed the number of DRMs that most streaming publishers will need to support.
Working with EME
When DRM is tied to a plugin, the DRM works on any browser that supports the plugin. So if you protected your content with Adobe Access via the Flash Player, Adobe Access worked within any browser that supported Flash.
In contrast, with EME, each platform decides which DRM to support, and as shown in Table 1, the major browsers all support different DRM technologies. Not surprisingly, Microsoft supports its PlayReady technology in Internet Explorer and Edge, Google supports Widevine in Chrome, and Apple supports FairPlay in Safari. Firefox supports both Adobe Access and Widevine. As a practical matter, this means that technologies like DivX, or VCAS, or Marlin, which aren’t integrated into any browser, are unavailable for browser-based distribution without a separately downloaded player, which are increasingly anathema in an HTML5-centric world.
Note that the information in Table 1 was largely pulled from DRMToday’s website, which is a great resource for learning which DRM is supported by which platform and specs like HbbTV.
|Firefox (38+ Windows)||Adobe Access|
|Firefox (47+ Windows/Mac)||Adobe Access, Widevine|
|IE 11+ on Windows 8.1+||PlayReady|
|Microsoft Edge (Windows 10+)||PlayReady|
|Opera (only on Linux)||Widevine|
|Safari (8+ on OS X)||FairPlay|
Table 1. DRM support by browser.
Moving from desktops to mobile players, when securely distributing to the mobile devices, you have two options, browser-based playback, and playback within an app. In terms of browser-based playback, the vendors remain true to form; Apple supports FairPlay in iOS 6+, Google supports Widevine Classic in Android 3+, and Widevine Modular in Android 4.3+, while Microsoft supports PlayReady on the Windows Phone.
Of course, apps provide much more freedom of choice. For example, Figure 5 shows the App compatibility matrix provided by BuyDRM, which enables PlayReady on all mobile devices, with Marlin, the open-standard DRM solution, on iOS and Android devices. Basically, browser-based playback enables one DRM per platform, while an app usually lets you select from multiple DRMs.
Figure 5. Using an app broadens your DRM choices on mobile platforms. (Image courtesy of BuyDRM)
In OTT, PlayReady dominates, with support on most platforms except Apple TV, which of course only supports FairPlay. Widevine is also available on Google devices like Chromecast and Android TV, but not Amazon Fire TV, which uses PlayReady. Most smart TVs support PlayReady, with a smattering of support for Widevine and Marlin. Both Xbox and PlayStation support PlayReady, with the Sony devices also supporting Marlin.
Choosing a DRM and Licensing Partner
By this point, you probably understand that to choose a DRM technology, first you choose the playback platform, and then you see which DRM or DRMs it supports. To support all the major browsers on computers, you’ll need to support multiple DRMs. In addition, since EME doesn’t yet support 100% of target viewers, any DRM strategy based around EME will have to enable fallback to a plugin-based DRM, usually either Adobe Access via Flash or PlayReady via Silverlight. Complicating this fallback strategy is Adobe’s decision to make Access primarily available only within its own Primetime platform, so if you’re not a Primetime user, you may not be able to offer fallback to Flash.
On mobile platforms, you have to decide whether to produce an app or to distribute via the browser, with the former offering much greater flexibility regarding choice of DRM. Once you move into OTT and Smart TVs, it’s a device-by-device determination; identify the device that you want to serve, and then identify the supported DRM or DRMs.
DRM Licensing Options
After choosing the target platforms and identifying the DRM technologies you must support, you should choose a licensing provider, which involves multiple factors, including whether to go direct with those vendors that support (or require it), or to use a licensing partner. Obviously, the DRMs supported by a potential partner is a major consideration, and a partial list of service providers is shown in Table 2. Note that this is a fast moving market, so check with the service provider before making any decisions.
|Company||Microsoft PlayReady||Google Widevine||Adobe Access||Apple FairPlay||Marlin|
|Adobe Primetime DRM (coming Q4 2016)||Yes||Yes||Yes||Yes||No|
|Cisco VideoGuard Everywhere||Yes||Yes||No||Yes||No|
Table 2. A partial list of multiple DRM service providers.
As an aside, though Netflix has licensed FairPlay from Apple for the playback of DASH-encoded files using EME and MSE, it appears to be only content owner with that privilege. All vendors listed in Table 2 can supply FairPlay for protecting HLS content, but not DASH. While this may change later in 2016, this was true as of June 2016.
To the list shown in Table 2, you should add online video platforms (OVP) like Brightcove, Kaltura, and Ooyala, which all offer various DRM technologies to enable native EME support in current browsers, fallback to Silverlight or Flash for older browsers, as well as SDKs to assist with delivery to mobile and other devices.
Similarly, in 2016, Adobe introduced the Adobe Primetime HTH TVSDK that uses the native EME-driven DRM of each browser. Adobe also announced a partnership with ExpressPlay to provide a cloud service for issuing licenses in all required DRMs, which should be available in late 2016. Customers may use the Adobe cloud for DRM licensing, or use a limited set of license administrators in conjunction with the Adobe Primetime TVSDK on the client. Essentially, if you’re distributing your content through an OVP or similar platform, that service or platform should be able to either provide the necessary DRM, or an easy path to integrating third-party service providers like those shown in Table 2.
Again, as mentioned, Adobe has stated that they will no longer support third-party DRM resellers, which could mean some changes to Table 2 regarding Adobe Access in 2016 or beyond.
Packaging Your Content with DRM
For developers managing their own distribution and player development, the integration of DRM into your encoding and packaging workflow is another major factor, and different services take different approaches. For example, castLabs, owner of DRM Today, offers a cloud service that can input over 100 audio/video codecs, and output DRM-protected packaging for DASH, Smooth Streaming, and HLS, complete with closed caption support.
If you’re encoding in a third-party cloud service, check which DRM providers it directly supports. For example, Encoding.com supplies Widevine licensing directly, but integrates with BuyDRM to manage PlayReady licensing. BuyDRM also has deployments in Amazon Web Services, Akamai, Brightcove (Zencoder), Encoding.com and Google Cloud. If you’re encoding your own content, check if the vendor can supply encoding/packaging capabilities for your chosen platform, whether Windows, Linux, or the cloud.
Check whether your service providers or partners support dynamic encryption, as opposed to static, which can simplify your workflows and save storage costs. For example, the Wowza Streaming Engine can dynamically encrypt and package live and VOD content for delivery via Apple HTTP Live Streaming (HLS), Microsoft Smooth Streaming (MSS), and Dynamic Adaptive Streaming over HTTP (DASH) with PlayReady and Verimatrix VCAS DRMs using three third-party DRM service providers, BuyDRM, EZDRM, and Verimatrix (Figure 6).
With dynamic encryption, which is available from other vendors, including Microsoft Azure, only a single copy of the unencrypted content needs to reside on the server. In contrast, with the static packaging model, you would have to create and store the final encrypted packages for all technologies for all content, multiplying your storage costs. The potential downside of dynamic packaging is a slight playback latency, which will vary by technology provider.
Figure 6. The DRM capabilities of the Wowza Streaming Engine adds dynamic, multiple format encryption and packaging with support from multiple vendors.
Pay TV-Oriented DRM Services
If you’re a pay TV service provider also distributing to streaming and other clients, there are several other alternatives you should consider. For example, Verimatrix sells DRM and other products into the broadcast and pay TV markets. Since many of its customers are expanding into streaming delivery, Verimatrix created the MultiRights OTT service, which manages its core VCAS DRM for delivery of services to iOS, Android, legacy desktop browsers, and STBs, and adds Widevine for Chrome and other proprietary environments, and PlayReady for integrated license management for Smooth Streaming and DASH service delivery to closed Xbox and Windows environments.
NAGRA, the developer of the anyCAST Security Services Platform for Digital TV service providers, takes a different approach. Rather than use third-party DRM platforms to support computers, mobile devices, and other CE platforms, NAGRA has extended its own DRM technology to these platforms via secure players and other technologies.
Similarly, Cisco VideoGuard Everywhere (VGE) allows pay TV services to securely extend playback beyond the STB to computers, mobile devices, and gaming consoles. In addition to access to the DRM technologies, with VGE Cisco assumes responsibility for integrating all components of the video service solution, including different DRM systems, monitoring the integrity of the service after deployment, and responding to service breaches identified.
Business Models and Pricing
When choosing DRMs and providers, be sure to check that the combination supports both your target platforms and planned business models. If your model is streaming to online clients, that should be fairly simple, as virtually all DRMs and DRM providers support this. On the other hand, if you’ll be implementing a subscription model, or the ability to download and play the content offline, or download it on your computer and then sideload it to another device, you could have issues.
Beyond business models, you should price both startup and ongoing costs, particularly those involved with supporting additional platforms, which varies significantly from provider to provider. For example, many service providers in Table 2 offer SDKs to create Android and iOS apps, but some are available at a nominal fee, while others are quite expensive. When comparing prices, you should know all platforms that you intend to support, and how you intend to support them (app or browser). Then you should price out each module or service required to get that done, plus minimum monthly fees and per-license costs. Remember to factor in the potential storage costs as well.
The Player Side
As a final note, if you’re using an off the shelf (OTS) player like JW Player, understand that it may not currently support all DRMs. As an example, the only DRMs JW Player supports for DASH playback are Widevine and PlayReady. So check with your OTS player developer to determine which DRMs it supports.
In addition, before choosing a DRM provider, ask if your player developer has relationships with any providers will simplify the integration. For example, JW Player has partnerships with Vualto and BuyDRM for each provider’s multi DRM protocol. Similarly, if you use castLabs’ DASH Everywhere DASH Player, sister company DRM Today is a natural DRM provider. Finally, if you’ll be creating apps for mobile platforms, check which of your candidate suppliers offer software development kits (SDKs) to speed their development.
Author’s note: The author wishes to thank Christopher Levy, CEO of BuyDRM, for technical assistance with this article.