With the recent announcements from Apple/Netflix and Mozilla, all modern desktop browsers will soon support the proposed HTML Encrypted Media Extensions (EME) standard. EME provides a standardized approach for playing encrypted content in HTML5. One application of encrypted video is the enforcement of Digital Rights Management (DRM) on paid video content. Many content owners (film studios, sports leagues, etc.) mandate using DRM to distribute their content online.
What does all of this alphabet soup mean for users? In short, the EME standard enables publishers to deliver premium video to browsers without the need for plugins. To date, doing DRM in the browser requires the Adobe Flash, Microsoft Silverlight or Google Widevine plugins. These plugins use non-interoperable file formats, protocols and DRM key systems, creating fragmentation. EME solves (most of) these issues, enabling premium video in HTML5 using a single file format and streaming protocol.
The EME specification mandates support of basic encryption using an AES key (called “Clear Key” in the spec). All browsers therefore support it. Using Clear Key, developers will be able to implement a level of video protection very similar to that built into the HTTP Live Streaming protocol from Apple.
Full-fledged DRM applications, however, require an external software library called a Content Decryption Module (CDM). To date the browser and mobile OS vendors have chosen only to support their own proprietary CDMs (Adobe Access in the case of Firefox), which are not interoperable. The table below summarizes which CDM each browser and OS supports.
Internet Explorer 11+ (Windows 8.1+ only)
Firefox (version TBA)
Windows Phone 8.1+
From Three Plugins to Four CDMs
So, there were three DRM plugins, but now there are four CDMs with EME? Isn’t this worse than the fragmentation that exists today?
Yes and no. The EME implementers have agreed to support an interoperable standard file format (ISO BMFF), codecs (H.264 and AAC), and encryption (CENC), as well as the HTML Media Source Extensions (MSE) to facilitate standard adaptive bitrate streaming protocols such as HLS and DASH.
This means that the only difference among implementations is the DRM servers that the web application calls to request and download a content license and AES decryption key. Everything else is interoperable, allowing content publishers to reuse the same encrypted video files across all browsers, OSes and devices that support the agreed-upon standards.
In short, while the fragmentation in DRM itself remains, the encoding and delivery workflow are now separated and standardized. This is a net gain for publishers that require DRM, since they don’t have to encode, store and deliver multiple versions of their content anymore. For a more detailed explanation, see Microsoft’s & Fraunhofer’s “Interoperability, Digital Rights Management and the Web” white paper (PDF).
JW Player and EME
Today JW Player supports several content protection mechanisms, including domain restriction, URL tokening and playback of AES–128 encrypted HLS streams. These tools are both adequate and cost-effective for applications like corporate communication, live streaming and e-learning.
Since usage of JW Player by broadcasters and (S)VOD providers continues to grow, EME support is the logical next step on our roadmap. We plan to incorporate both EME and MSE in JW Player, enabling our publishers to protect and deliver their premium content in pure HTML5.