- GiantSteps Media Technology Strategies 1790 Broadway, 6h Floor New York NY 10019 212 956 1045 www.giantstepsmts.com Strategies for Secure OTT Video in a Multiscreen World By Bill Rosenblatt March 23, 2015 2015 GiantSteps Media Technology Strategies. White paper commissioned by Irdeto. All trademarks are the property of their respective owners. This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License. For more information, see http://creativecommons.org/licenses/by-nc-nd/3.0/us/.
Table of Contents Table of Contents... 2 Introduction and Executive Summary... 3 Imperatives for Over-the-Top Video Service Providers... 4 Sources of Complexity... 4 Competition... 5 Technology Background... 7 Streaming Video Protocols... 7 Browsers and Web Application Technologies... 9 Digital Rights Management... 11 HTML5 Video Players... 17 Recommended Strategies... 19 Maximizing Scalability, Isolating Complexity... 19 Multiscreen Rights Management... 20 An Example: maxdome... 22 Conclusion... 24 About Irdeto... 25 About the Author... 25 About GiantSteps Media Technology Strategies... 25 2
Introduction and Executive Summary Life is not simple for providers of over-the-top (OTT) Internet video services whether they are pay TV operators or new pure-internet players. Services like Netflix have proven that it s possible to attract large audiences to Internet-delivered premium video content, but staying competitive is difficult. Devices that can consume Internet video are proliferating to include set-top boxes (STBs), Smart TVs, optical disc players, and game consoles as well as PCs, laptops, and smartphones. Consumers have become conditioned to all my media on all my devices all the time from their experiences with digital music and e-book services, and they expect no less from video; meanwhile, Hollywood studios and other video content licensors have raised, not lowered, their expectations that their content be protected from unauthorized use. In general, the technological complexity of building, maintaining, and scaling multiscreen OTT video services isn t decreasing. Operators require a range of capabilities including streaming video, content protection, application development, and other technologies. Yet no single, silver bullet stack with all these capabilities has emerged that operators can rely on to build out their services in a future-proof, scalable, and interoperable manner. This white paper is designed to help OTT video service providers understand some of the complexities and interdependencies of multiscreen streaming video technology today and in the near future. It aims to help them set a strategy that minimizes and isolates complexity among several moving parts. By making OTT service deployment easier, operators can better respond to competitive developments in the marketplace while minimizing total cost of ownership (TCO). The first section of the white paper looks at imperatives for OTT service providers, including consistent user experiences across screens, content access model variety, and competitive pressures. It also compares the evolution of multiscreen digital video with that of digital music and e-book services, and it describes the sources of technical complexity that service providers must grapple with to meet these requirements. The next section describes today s landscape and the near-term evolution of key technologies for streaming premium video content: adaptive bitrate streaming, web browsers as application development environments, digital rights management (DRM), and browser-based video players. In particular, we look at the emerging standards of HTML5 for application development and DASH for video streaming, as well as the current web browser market for digital video consumption devices and the challenges of integrating DRM technologies with browsers. The final section lays out a strategy and high-level solution architecture that OTT service providers can use to take as much advantage as possible of current and emerging standards while isolating and minimizing the sources of technical complexity that are likely to persist for the foreseeable future. The strategy calls for starting (or transitioning to) a program of multiscreen application development that takes advantage of DASH adaptive streaming, web browsers, and HTML5 Encrypted Media Extensions, and uses a variety of DRMs that (in many cases) go hand-in-hand with browsers and the client platforms they run on. The section ends with a description of maxdome, a successful European OTT service that is transitioning to a solution similar to that discussed here. 3
Imperatives for Over-the-Top Video Service Providers The bar is high for both pay TV operators and pure-internet providers that run, or are planning to launch, multiscreen OTT Internet video services. Here are several of the imperatives that OTT providers should bear in mind when planning implementations. The most important requirement for consumers is to offer them a consistent experience across all of their devices and as far as licensing rules permit it all locations. Users expect to have similar experiences on their phones, tablets, desktops, laptops, STBs, game consoles, and Smart TVs. In general, this has been more difficult for premium video services to achieve than it has been for other types of content services such as streaming music and e-books. Leading services of these types such as Pandora and Spotify for music, and Amazon Kindle and Kobo for e-books have had consistent cross-platform implementations since around 2010. In contrast, most premium video services have taken longer to achieve similar levels of platform ubiquity. Premium video services have taken longer than streaming music and e- book services to achieve consistent cross-platform implementations. Of course, there are many reasons for this, such as the lack of sufficient bandwidth over wireless networks to support adequate quality video streaming in many locations until more recently. But mobile devices with sufficient video capabilities (e.g., Apple iphone and ipad, Samsung Galaxy series, and various other Android devices) were available by 2010. Sources of Complexity Several complexities in multiscreen OTT video service implementation have presented obstacles to platform ubiquity. These include: Application development: the need to develop largely different code bases for apps on different client platforms. Encoding and streaming: the need to support several different codecs and streaming protocols, and to create and store a large number of files per content title, to reach a wide variety of devices. Digital rights management: the lack of standards for DRM that both satisfies the content protection requirements of Hollywood studios (and other content licensors) and is supported on a sufficient variety of clients. Tools and technologies exist to help minimize some but not all of these areas of complexity. As we ll see, these tools and technologies are in various stages of adoption. Application Development HTML5 was designed to enable single-source application development with crossplatform interoperability and consistent implementation of audio, graphics, and video applications. Yet although Pandora and Amazon released HTML5 browser versions of 4
their music and e-book applications in 2011, HTML5 did not become a practical choice for video services until more recently. Netflix started rolling out HTML5 versions for ChromeOS and Microsoft Internet Explorer in 2013; other services such as Hulu still do not use HTML5. As we will see, HTML5 is only now becoming a reasonable choice for rich media applications that require DRM. Encoding and Streaming Another source of complexity is streaming video protocols. Although streaming video technology has existed since the late 1990s, the adaptive bitrate technology required for uninterrupted viewing at the best possible quality dates back to the late 2000s; and, as we ll see below, various incompatibilities exist between adaptive streaming protocols and popular client platforms. In contrast, streaming music technology is simpler and more established; and the technology for sending e-books to users devices is simplest of all. Digital Rights Management Yet another area of complexity is studio requirements for content protection. Streaming music services typically rely on standard SSL/TLS transport encryption to protect content. Music download services no longer require DRM in most cases. On-demand music services like Spotify and Deezer use DRM for device-cached ( offline listening ) files, but each service provider designs its own DRMs. Many leading e-book services use their own DRMs as well, and book publishers rarely have much technical input into or approval over such schemes. In contrast, video services must use third-party content protection technologies, demonstrate conformance to robustness rules, and obtain approval on specific implementation details from multiple content licensors. To complicate matters further, it has not been possible until recently to implement DRMs within browser environments, meaning that video services have had to be implemented as standalone applications and/or using rich media application environments such as Adobe s Flash or Microsoft s Silverlight. Consumers rebel against complexity and inconsistency, so it s important to implement consistent rules across all platforms. Competition Other obstacles to consistent branded interfaces for video services include usage rules, which can become quite complicated given the variety of content and access models that a service could support (linear television, VOD, rental, pay-per-view, etc.) and the complexity of licensing rules. But it s well known that consumers rebel against complexity and inconsistency, so it s important to implement consistent rules across all platforms. Pay TV operators in particular are realizing that they have new competition as they expand from managed networks to over-the-top services on the Internet; in fact, the Internet has forced many operators to face their first real competition of any kind. And the competition comes from multiple sources: it includes services that focus on single access models that are simple for consumers to understand by themselves, such as subscription VOD (Netflix, Hulu Plus), rental and sell-through (Apple itunes, Amazon Instant Video), and standalone services from name-brand content providers (HBO GO, CBS All Access) not to mention unlicensed streaming and downloads. In contrast, many operators offer 5
limited VOD and SVOD services of their own, in addition to the same branded content that providers like HBO and CBS now offer by themselves. Pay TV operators have new, multifarious sources of competition as they expand from managed networks to over-the-top services on the Internet. Adding OTT versions of all these services the results of many licensing arrangements negotiated over a long period of time opens up many possibilities but also many more dimensions of complexity for both operators and their customers. Operators face a dilemma as they roll out OTT services: should they try to emulate their managed-network offerings online and add many types of services quickly, or should they go slow and bring their subscribers along gently? Either approach carries a risk of driving customers away, either from confusion over complexity or from not having desirable content or features. The best principles to bear in mind during this transitional period are consistency and flexibility. Operators should add features in a way that maximizes a consistent user experience and minimizes additional complexity, and they should be able to add features quickly based on market developments and customer feedback. The good news is that many of the challenges to OTT service implementation have been eliminated or reduced by new technologies, tools, and best practices. As we will discuss, operators nowadays have greater possibilities to launch OTT services in a way that manages complexity and minimizes TCO. 6
Technology Background The most important technology ingredients for cross-platform video service implementation are streaming video protocols, browsers and HTML standards, DRM technologies, and video players in browsers. In this section we discuss the current state of the art of each one of these. Streaming Video Protocols Cross-platform video service implementation requires a consistent experience not only across device types but also across multiple types of networks. Consumers should be as unaware as possible of whether they are watching video over a 3G wireless network, cable modem speed broadband in the home, or anything in between. The answer to this problem has been adaptive bitrate streaming over HTTP. The concept originated with the DVD Forum in the early 2000s. The first implementation is generally credited to Move Networks, which launched its HTTP adaptive streaming solution in 2007 and received a key patent on the technology in 2010. The basic idea of HTTP adaptive streaming is to maintain multiple copies of video content at different resolutions and deliver it in chunks over HTTP, choosing the resolution best suited to network conditions at the moment as well as the hardware capabilities of the client. HTTP adaptive streaming is a replacement for technologies such as RTSP which require real-time connections between clients and servers, and won t travel through restrictive firewalls, and therefore are less flexible in implementation. Fragmentation of Streaming Protocols Several companies have released proprietary adaptive streaming protocols. The most important ones in the market are: Microsoft HTTP Smooth Streaming, which Microsoft prototyped in its VOD implementation for the 2008 Olympics and released as a product in 2009. Apple HTTP Live Streaming (HLS), launched in 2009 with the release of the iphone 3. Adobe HTTP Dynamic Streaming (HDS), released in 2010. These protocols are not mutually exclusive, because they provide access to different sets of client platforms and applications environments: Smooth Streaming works with Microsoft s Silverlight video player, meaning that it can run within most major web browsers on Windows and Macs. It also has been ported to various STBs, Windows Phone and some Symbian-based mobile devices. However, it can t run natively ios clients in most cases. 1 1 While it is possible to port Smooth Streaming to ios using Microsoft s porting kit, Apple requires ios App Store apps to use HLS if they stream video over cellular networks. Therefore, apps that use Smooth Streaming must stream content in HLS and convert it on the fly within the app. 7
HLS started out on ios devices only. It has spread to other client platforms, including web browsers, several STBs, Windows 8, and limited support for Android. HLS has become the most popular of the proprietary adaptive bitrate streaming protocols. Apple has submitted it to the Internet Engineering Task Force as a draft standard. Adobe HDS requires the Flash Player or AIR application environment on Windows, Mac, and Linux clients. The lack of support for Flash on ios and Android has hampered HDS s success in the market in recent years. Therefore, streaming video services that need to reach as wide a variety of client platforms as possible are forced to run multiple adaptive bitrate technologies and streaming formats. This in turn requires licensing, storing and managing even more copies of content, which drives up complexity and costs. DASH Simplifies Adaptive Streaming Support An open MPEG standard, Dynamic Adaptive Streaming over HTTP (DASH), is emerging as an alternative that has the potential to reach all client platforms from a single server configuration and with a single set of content files. Development of DASH began in 2010, it achieved MPEG standard status in late 2011, and it became an ISO standard in 2012. DASH is intended to be a superset of the capabilities of all the proprietary adaptive bitrate solutions, 2 and it is completely agnostic to both codecs and as we will discuss later DRM schemes. Adobe, Apple, and Microsoft (among others) all participated in the development of the standard. MPEG DASH is emerging as an alternative to proprietary adaptive bitrate streaming video protocols. At this time, the most activity in DASH deployments is in OTT services (as opposed to digital broadcasters and managed network operators). Netflix was an early adopter, using at least a portion of DASH functionality since before it became a standard; Hulu and YouTube are both using it for new deployments. Microsoft and Adobe have both embraced it in their streaming media stacks. By now, all major encoder/packager vendors and service providers either support DASH now or have road-mapped it for the near future. It is also worth mentioning that many client platforms besides the browser/html5 environment described below support DASH now or will soon. DASH implementations in native apps for a variety of platforms are possible now through tools such as the opensource libdash code library. At the same time, a few forces are hampering DASH s trajectory toward becoming a universal open standard. One is Apple s current lack of support for it: there is no native support for DASH in ios, and Apple will not allow its use in most video apps distributed through the ios App Store. 3 Apple s HLS is widely used and reaches very popular devices; many operators have built out HLS infrastructure recently and will naturally be reluctant to move to a different adaptive bitrate streaming scheme, at least for a while. 2 For a handy overview of detailed differences between DASH and the three major proprietary adaptive streaming technologies, see http://www.encoding.com/adaptive-bitrate-video/. 3 See Note 1. 8
Still, even if the future revolves around two adaptive bitrate technologies (HLS and DASH), life will be simpler for some service providers than it has been with three different adaptive bitrate solutions that have various client, format, and DRM dependencies. Browsers and Web Application Technologies The web browser market is even more fragmented than the adaptive streaming market with respect to client platforms. A single standard for application development that works on all browsers would be of enormous help to operators in launching multiscreen services. HTML5 is just such a single cross-browser standard and therefore offers the easiest path for operators up to a point, as we will see. Although the discussion below refers to browsers, it s important to note that many service providers are using HTML5 and other web technologies within apps that run natively in operating environments such as ios and Android. This enables app developers to use a single code base (with minor platform-dependent variations) on the widest possible variety of platforms. Web technologies are often used within native apps as well as within browsers, to leverage a single code base across multiple platforms. Browser Market Fragmentation Figure 1 shows browser market share on the most widely used platforms for viewing streaming video; the pie charts are sized proportionately to the relative use of those platforms. Aside from PCs, Macs, mobile phones, and tablets, the next most popular viewing platforms are connected DVD and Blu-ray players, STBs (e.g., Roku), and Smart TVs. Most of these devices have web browsers built in, although streaming video applications generally do not use them. 9
Figure 1: Browser market shares on streaming video platforms, sized according to market share. 4 As Figure 1 indicates, consumers use more than a dozen different browsers on the top four categories of streaming video platforms. Each category of device has its own set of leading browsers: Users run over a dozen different web browsers across the four most popular categories of streaming video platforms. Chrome, Internet Explorer, and Firefox are used on the vast majority of PCs and Macs. Apple s Safari has dropped to single-digit market share. Native iphone and Android browsers maintain strong market shares on those platforms, though Chrome is now the market leader on mobile phones. The UC Browser is rapidly dominating the mobile market in India, China, and other Asian countries, accounting for its no. 4 (and growing) position on mobile phones. Safari dominates the tablet market due to its inclusion on ipads. The browser market on game consoles is dominated by ACCESS s NetFront browser, which is used in Sony PlayStation 3 and Nintendo Wii devices. Microsoft s Internet Explorer is also widely used, thanks to its inclusion in Xbox devices. 4 Sources: StatCounter, December 2014, worldwide (browser market share); TNS ReQuest, August 2014, US (platform market share). Internet Explorer includes IE Mobile. NetFront includes Sony PS3 and PSP, and Nintendo Wii consoles. Platform market share for PCs and Macs is for laptops only, because TNS ReQuest breaks out desktops and laptops separately; thus the true figure may be higher than 49%. Blu-ray/DVD players, Roku boxes, and Smart TVs all have market shares of about half that of game consoles for streaming video viewing. 10
Google, Apple, and Microsoft Dominate the Market Figure 2 takes the market shares of device types shown in Figure 1 for streaming video use and uses them as weightings to derive browser market shares by vendor: Microsoft includes Internet Explorer plus IE Mobile; Google includes Chrome plus the Android native browser; Apple includes Safari plus the iphone native browser. It shows that Google, Apple, and Microsoft together have almost three-quarters of the market. Of course, this does not necessarily imply that browser-based streaming video applications will follow the same pattern of browser use, but it does suggest that those three companies comprise the most attractive development targets at this time. Google, Apple, and Microsoft together have almost three-quarters of the browser market for the most popular streaming video platforms. 4% 3% 3% 7% 7% 14% 21% 37% Google Apple Microsoft ACCESS Mozilla Sony Opera UC Figure 2: Browser share by vendor according to popularity of device categories for streaming video. The good news is that all of these browsers support HTML5. The bad news at least for the time being is that not all of them support the Encrypted Media Extensions that enable integration of DRM into native browser applications. We discuss this in further detail below. Digital Rights Management Premium content licensors, such as Hollywood studios and major sports leagues, require DRM for both streaming and downloads. Some licensors will accept the stream encryption schemes built into proprietary adaptive streaming technologies such as HLS, but not all of them do; in addition, licensors are generally increasing security requirements for higher resolution content. Therefore streaming video providers must integrate one or more DRM technologies into their services. 11
Major DRMs for Browser-Based Video The most important DRM technologies for browser-based video available today are: 5 PlayReady from Microsoft, first released in 2008 within the Silverlight web application environment; backward compatible with Windows Media DRM. Example deployments: Netflix, Amazon Instant Video. FairPlay from Apple, originally released in 2003 as part of the itunes Music Store for AAC audio files, then modified to support itunes video downloads in 2005. Widevine, originally a streaming video protection scheme, acquired by Google in 2010. Example deployments: Netflix, VUDU, Google Play Movies & TV. Primetime DRM, part of the Adobe Primetime suite of Internet video solutions released in 2012, formerly known as Adobe Access (and before that, Adobe Flash Access). Example deployments: Comcast XFinity, NBC Sports. Marlin, from a consortium led by Intertrust Technologies, released in 2006. Example deployments: Sony PlayStation Network, Actvila (IPTV service in Japan). All of these DRMs except Apple FairPlay can be ported to multiple platforms through SDKs; FairPlay runs on ios, OS X, and Windows. Some of the other DRMs are built in to certain platforms. For example, PlayReady support is built into Windows 8, Windows Phone, and Xbox in addition to Silverlight; Widevine is integrated into Android devices from version 4.2 on up; Google Chromecast supports both PlayReady and Widevine. There is no such thing as a single DRM that can work with all browserbased streaming video implementations. Unfortunately there is no such thing as a single DRM that can work with all browser-based streaming video implementations. Various attempts at universal DRM interoperability have failed, such as: The Coral Consortium was founded in 2004 by Inte7rtrust, HP, Twentieth Century Fox, and several consumer electronics companies as an attempt to develop technology for converting among existing DRMs; this failed for reasons including technical complexity, privacy concerns, and Apple s lack of participation. Coral officially dissolved in 2012. The Open Mobile Alliance (OMA) created a series of open standard DRMs called OMA DRM, the latest of which is OMA DRM 2.2, released in 2011. Although the technology (and its license administrator CMLA) still exists, it has not seen much uptake in the market due to reasons including ongoing uncertainty over patent coverage. Various attempts at developing open-source DRM have been made. But opensource DRM has major impediments to security, such as no licensing authority 5 Of course, several other DRM and conditional access technologies exist today that are approved by major studios and widely deployed in applications around the world. This list simply includes DRMs that are integrated with major HTML5 compliant web browsers through the Encrypted Media Extensions, as discussed below. 12
that issues trusted key material and administers compliance and robustness rules for implementations. For this and other reasons, no open-source DRM has ever obtained approval from movie studios or other major content licensors. The DRMs mentioned above (with the exception of FairPlay) can be ported to a wide variety of client platforms, typically via a porting SDK. This means that the DRMs can be used in native apps for those platforms, but separate efforts must be made to integrate the apps with each platform. Among other things, this includes using different sets of techniques for hardening the applications so that they are made resistant to hacks. Various attempts at universal DRM interoperability have failed. Challenges of DRM Integration with Browsers Integrating protected premium video content into browsers has been a challenge, given that HTML browsers were not primarily developed with content security in mind, and therefore it isn t possible to implement DRM directly in a browser. The original way to integrate DRM-enabled applications within web browser presentations was with browser plug-ins. Plug-ins began early in the history of the web. They are in the process of being phased out in favor of HTML5, though the transition should be a long one. The first browser plug-in interface to appear was the Netscape Plug-in API (NPAPI). NPAPI was released in 1995 with the original intent of enabling Adobe PDF files to render within the Netscape browser instead of requiring users to go to the trouble of saving files and opening them separately in Adobe Acrobat. In many browsers, the browser could be set to automatically download the plug-in needed to run on a file given its MIME type. In other words, plug-ins were used to trigger applications that would run within the browser environment when a user clicked on a file of a certain type. Most major browser makers ended up supporting NPAPI, at least for a while. Microsoft supported it in Internet Explorer alongside ActiveX, a competitive technology that Microsoft introduced in 1996 but stopped support for it in 2001. Google introduced a modified version of NPAPI called PPAPI (Pepper Plug-in API) in 2009; Chrome and Opera both support PPAPI plug-ins. Google and Mozilla began phasing out support for NPAPI plug-ins for Chrome and Firefox in 2013 and 2014 respectively. The next type of technology used for premium media applications within browsers was the web application environment, such as Microsoft Silverlight and Adobe Flash, both of which operate within the above plug-in frameworks. These are development tools designed to create rich-media applications specifically within browsers, as opposed to merely interfaces to launch third-party applications on files downloaded from web pages. Flash dates back to the mid-1990s as a graphics and animation platform developed by FutureWave, which in turn was acquired by Adobe (by way of Macromedia). Video support and the FLV Flash Video container format were added later, and Flash enjoyed a major rebirth as an Internet video platform. Flash runs in browsers as a plug-in. Its major shortcomings in terms of interoperability have been lack of native support in ios and recent versions of Android, and click to play obstacles in various browsers. Recently Adobe has been transitioning from Flash to HTML5 and even offers Flash-to-HTML5 conversion on an experimental basis. 13
Microsoft released Silverlight in 2007. It works in some browsers as well as natively on certain mobile platforms: Internet Explorer (except Windows 8 in Metro mode), Firefox, Safari (on Mac only 6 ), and Chrome (on Windows only, as of Chrome 39), as well as Windows Phone and some Symbian devices. In 2013 Microsoft announced a slow phase-out of Silverlight with end of life by 2021, also with the goal of moving towards HTML5. Because Silverlight depends on NPAPI, browser makers phase-outs of NPAPI support (see above) also means phasing out support for Silverlight. Adobe and Microsoft are moving away from these app development environments for a variety of reasons that include security and privacy concerns, performance degradation, and the migration of more and more of their functionality into the core of HTML. DRM Integration in HTML5 via Encrypted Media Extensions HTML5 has a new way of integrating DRM-enabled applications. As HTML5 was developed, controversy existed over whether or not it should include DRM capabilities. The Electronic Frontier Foundation, Free Software Foundation, and Mozilla Foundation (makers of Firefox) campaigned against it, while Microsoft, Google, Netflix, and Hollywood studios supported it. A consensus emerged that keeping DRM out of HTML5 would only serve to relegate premium video content to standalone apps and keep it away from open web technologies, so it would be better to include DRM hooks while keeping DRM out of the browser per se. With HTML5, developers can write their app code in JavaScript and use a set of routines called the Encrypted Media Extensions (EME) to integrate with DRM schemes from within browsers that support it. EME works with a secure execution environment on the client platform called a Content Decryption Module (CDM), which handles license requests, stores licenses when necessary, and decrypts content. Each CDM is specific to a DRM technology. EME contains routines to inquire whether the DRM used to protect content is supported on the client. If so, the EME asks the appropriate CDM to issue a license challenge if necessary. The CDM passes the license challenge back to the application, which passes it on to the appropriate DRM license server for processing. HTML5 Encrypted Media Extensions is becoming the preferred way of integrating DRM with web browsers for premium video content. Browsers are not required to support EME, because HTML5 extensions are not mandatory. Those that do support EME, or plan to at this time of writing, include Chrome, Internet Explorer, Safari (for OS X Yosemite), and Firefox (as explained below). It seems inevitable that other browsers used on popular streaming video platforms (see Figure 1, p. 10) will follow, but timeframes are currently unknown. DRM vendors can create CDMs that enable browser makers to play protected content with the respective DRM; the interface for CDMs is defined in the EME spec. 7 CDMs can be implemented as wrappers around existing DRMs. Figure 3 shows how the scheme works. A web app, written in JavaScript, runs within an HTML5-compliant browser that supports Encrypted Media Extensions and a CDM for a specific DRM. The user requests playback of content, causing the app to retrieve 6 Apple released a version of Safari for Windows starting in 2007 and discontinued it in 2012. 7 https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html. 14
encrypted content from a CDN. The app uses EME to determine the type of DRM used to encrypt the content and, if needed, request a license from the appropriate DRM license server, as described above. The license server returns a license, which is passed to the Content Decryption Module, which hands it off to the DRM. The DRM extracts content keys from the license, decrypts the content, and hands the decrypted content off to the Player. In some cases, a license request may not be necessary because the appropriate license is already stored on the device within the CDM (e.g., for licenses covering multiple linear TV channels). Figure 3: Delivery of encrypted content to HTML5-compliant browser with Encrypted Media Extensions. It is theoretically possible for any browser to support any DRM via the EME/CDM mechanism. But doing so requires action on the part of both the DRM vendor and the browser maker. The DRM vendor has to create a CDM-compliant version of its DRM client, and the browser has to be able to call it. The CDM-compliant DRM client can exist in several places: the browser maker can compile it in to its code, it can be pre-installed on the client (as part of the operating system and/or firmware), or it can be downloaded separately. Three out of the five DRM vendors are also browser makers, which has created dependencies between browsers and DRMs. For example, at this time of writing: Apple appears to have implemented EME within Safari for OS X Yosemite, which suggests that it has implemented a CDM-compliant DRM for FairPlay. 8 Google has implemented a CDM-compliant version of Widevine for the Chrome browser and ChromeOS. 8 See http://techblog.netflix.com/2014/06/html5-video-in-safari-on-os-x-yosemite.html. Netflix uses PlayReady on many platforms and is not known to use FairPlay. 15
Microsoft has implemented a PlayReady CDM wrapper that can be compiled into any browser; 9 it works with Internet Explorer today. Mozilla eventually agreed to support EME because it did not want its users to switch to other browsers in order to watch premium licensed content. It announced a partnership with Adobe to create a CDM version of Primetime DRM for Firefox, 10 and it is working with Intertrust on an integration of Marlin. Integration of both Primetime and Marlin into Firefox is expected to be complete in mid-2015. Three out of the five HTML5 EME-compliant DRMs come from browser makers. This has created dependencies between browsers and DRMs. In other words, the EME/CDM scheme does not by itself enable the possibility of mixingand-matching browsers with DRMs; it is ultimately another type of plug-in scheme, albeit one with a much narrower focus than Flash or Silverlight. Furthermore, the availability of pre-installed CDM-compliant DRM implementations on some client platforms has led to the need for some applications to support multiple DRMs even for a given browser. This, together with browser-drm interdependencies, increases the need for service providers to use multiple DRMs. Common Encryption Simplifies Multi-DRM Support The good news in terms of interoperability is on the server side. DASH also incorporates a Common Encryption scheme, CENC, which is used to standardize the way content is encrypted across DRMs. The CENC scheme takes advantage of the fact that many major DRMs use the same core algorithm for encrypting content: AES-128-CTR, an application of the U.S. government standard Advanced Encryption System. By using CENC, a service provider need only create a single encrypted copy of each title at each resolution (for each adaptive streaming technology used), instead of one set for each adaptive streaming technology and each DRM.. With Common Encryption, a provider only needs a single encrypted copy of each title at each resolution for each adaptive streaming technology. Figure 4 shows a single set of encrypted files that can play on an app that runs in three different browsers, each using a different DRM and running on a different type of device. The three implementations of the app can (but do not necessarily) share the same HTML and JavaScript code, including code for the video player. In each case, the application and CDM, via EME, work together to build and issue a license request from the DRM s license server (not shown in Figure 4), based on the DRM supported by the browser and/or client environment, so that the proper license can be issued and used. For example: Implementation 1 could be Chrome (browser), Widevine (DRM), and an Android smartphone (device platform). Implementation 2 could be Internet Explorer, PlayReady, and a Windows PC. 9 http://download.microsoft.com/download/d/5/0/d5097b71-5d00-4dce-af69- A0675BAC8E47/Interoperability%20Digital%20Rights%20Management%20and%20the%20Web.pdf. 10 https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/. 16
Implementation 3 could be the Sony PlayStation 4 browser, Marlin, and a PS4 console. HTML5 Video Players Figure 4: Common Encryption allows a single set of encrypted content files to be stored for multiple DRMs instead of one set for each DRM. With HTML5 video, the player can be written in HTML5/JavaScript and can run directly in the browser, not as a separate app, as long as the browser can integrate with one or more appropriate DRMs as described above. With HTML5 it is no longer necessary to rely on either a platform s built-in player code or third-party (or your own) compiled player code that runs separately from the browser. At this time of writing, dozens of web video players are available for licensing, some on an open-source basis. The DASH Industry Forum maintains a list of commercial DASH clients, including players. 11 Otherwise, few of the dozens of players on the market at this time of writing support DASH, though some have announced plans to support it. 12 Once they do, unless you have very special requirements that an off-the-shelf player can t handle as well as the resources to develop and maintain the code over time it would be unwise to write your own player. In the meantime, the DASH Industry Forum offers code for a basic reference player called dash.js. 11 See http://dashif.org/clients/. 12 For example, the widely used JW Player has announced early 2015 availability of DASH support on Chrome and Internet Explorer browsers. See http://www.jwplayer.com/labs/roadmap/mpeg-dash/. 17
Dozens of HTML5 video players are available for licensing, though few of them support DASH at this time of writing. Here are some of the criteria to look for when selecting an HTML5 video player, depending on your application requirements: 13 What controls does it support? Does it support controls for the required content access models, such as VOD, SVOD, linear TV, etc.? Does it support full-screen playback? Does it support trick play (fast-forward and rewind)? Does it support closed captions, subtitles, and multi-language audio? Does it support ad insertion? Does it provide an API for extraction of usage data for analytics purposes? Is the user interface skinnable? Does it support plug-ins and add-ons? Is there an active community supporting its maintenance and further development? Does the player fall back to Flash video for platforms that do not support HTML5 media extensions? If the player is open-source and you are creating a commercial video app, can the player be licensed for commercial use? 14 13 For more detailed feature comparisons among popular HTML5 players, two good sources are http://praegnanz.de/html5video/ and http://html5video.org/wiki/html5_video_player_comparison#gpl_licensed_players_with_subtitle_support. 14 A particular licensing issue to watch is open-source players that are available under GPL version 3. GPL3 licenses contain DRM poison pill provisions that render laws against circumvention of DRMs (such as Section 1201 of the U.S. copyright law) inapplicable. This jeopardizes studio approval of your app. 18
Recommended Strategies This section describes a recommended strategy and high-level solution that enables OTT service providers to deploy across as wide a variety of devices as possible while isolating the factors that introduce complexities. Maximizing Scalability, Isolating Complexity A recommended strategy for OTT providers can be summarized as follows: Implement apps in browsers wherever possible using HTML5 with EME. Chrome and Internet Explorer are currently the browsers with support for HTML5 EME that is best suited to third-party app developers. Therefore start with PCs and Macs, then move to tablets and mobile phones, game consoles, and finally other devices such as STBs and Smart TVs as HTML5 EME-compliant browsers become distributed with them. HTML5 enables app development with consistent user experience across platforms with minimum incremental development effort. Adopt DASH for adaptive bitrate streaming wherever possible, but be prepared to support two adaptive bitrate streaming technologies HLS as well as DASH in order to support a sufficiently wide variety of client devices. Be prepared to support a larger and varying number of DRMs and browsers. Take advantage of built-in support for certain DRMs on popular platforms (see p. 12) to simplify implementation. Use CENC common encryption to minimize the number of encrypted content files that must be created and shipped to CDNs. Support for multiple DRMs due to browser dependencies is the number one technological bottleneck to interoperability and scalability. In the remainder of this section we ll discuss an approach that minimizes complexity and maximizes future-proofing by isolating DRM and browser dependencies as much as possible. Support for multiple DRMs due to browser dependencies is the number one technological bottleneck to interoperability and scalability. An OTT service provider can get content from a variety of sources, such as movie studios, television networks, live events, or internal sources. The provider ingests content, along with metadata, and encodes, packages and encrypts it for delivery to users. In addition, it gets detailed information about rights that the content sources are making available. Providers typically need to maintain three distinct back-end systems: Subscriber management (SMS): keeps track of accounts, users (for providers that offer family or other domain style accounts), and users devices. The SMS drives account management functions. Content management (CMS): stores information about content, including basic metadata, metadata to drive recommendations, available rights, and pricing. The CMS feeds the back-end service that the client app uses for searching, browsing, purchasing and selecting content. 19
Content repository, which sends video content items to an encoder-packager that encodes and encrypts content and sends files to the provider s content delivery networks. License agreements with content owners specify rights to content items, typically on a perdevice and/or per-drm basis. Service providers usually enter this information into the CMS manually through a management interface, as each studio (or other content licensor) typically specifies a single set of rights for all of its titles, or all titles of a certain type (feature film, episodic TV show, etc.). Rights for a given device or DRM include such parameters as: Access models: whether the content is available for linear (e.g., cable TV channel), VOD, SVOD, pay-per-view, EST (electronic sell-through, a/k/a permanent download), rental, caching for offline viewing, etc. Resolutions: SD, HD, 4K/UHD, etc. Output rules, such as whether analog output is allowed or whether HDCP is required on HDMI output. Multiscreen Rights Management In other words, the primary bottlenecks to interoperability and scalability are DRMs and rights information. The best strategy for providers to minimize this complexity is to adopt a multiscreen rights management capability like that shown in Figure 5. The multiscreen rights management scheme acts as a single interface between a service provider s back end systems and apps on all client platforms. It enables DRMs to be added and changed as the market evolves and needs dictate. At the center of the multiscreen rights management scheme shown in Figure 5 is a Rights Manager, which abstracts away DRM-specific license parameters and manages much of the communication with apps when a user selects a content item. It also generates CENC encryption keys to include in DRM licenses and responds to requests for keys from the Encoder-Packager. The Rights Manager abstracts away DRM-specific license parameters, manages communication with apps, and generates CENC encryption keys. The multiscreen rights management scheme also ideally includes an entitlements database, which integrates information about user accounts and content rights, so that it is efficient to get information about rights that a particular device (belonging to a user, who has an account) has to a particular piece of content in order to approve access to it. Some operators maintain separate entitlement management systems (e.g., so that they can support managed-network as well as OTT services), in which case the multiscreen rights management scheme can pull information from those systems. Finally, the multiscreen rights management scheme also maintains account-level business rules, such as limits on the number of concurrent streams or bitrates. 20
Figure 5: Multiscreen rights management capabilities make it possible to provide services with consistent user experiences to an expanding variety of client platforms. Here is a description of how a multiscreen rights management capability typically facilitates playback: When a user starts an app, the app initiates a session with a back-end application server, establishing a session ID. (Figure 5 omits this for simplicity.) The user interacts with the app to search, browse, and select an item of content to watch. Depending on the user s account and the entitlements, the user may need to purchase the item. Once the purchase (if necessary) is complete, the app sends a license request to the license engine. 21
The license engine validates the session ID in the license request, then checks to ensure that the device is valid and located within the proper territory of licensing (country). Then the license engine checks the entitlements to the content item based on the user s account: for example, has the user purchased the item, is the item available under the user s subscription plan, does the user still have the right to play a rental. Finally it checks the account-level business rules, such as whether less than the account s maximum number of permitted concurrent streams are running. If all of these checks pass, the Rights Manager passes a request to the appropriate DRM license server, along with an identifier of the content (from the CMS) and a CENC encryption key that it has generated. The encoder-packager obtains the key from the Rights Manger. It encrypts the content with the key and sends the required files to the CDN. This can be done on the fly so that no files containing content keys are resident on CDNs any longer than necessary, or it is done in advance of any user requests for the content. The app grabs content from the CDN, decrypts it through the DRM, and plays or downloads it. If the content is merely being downloaded and saved for offline playback later, the content is not decrypted. An Example: maxdome One example of a popular streaming video service that has been able to maintain a consistent user experience across a wide variety of devices through technology, similar to that described above, is maxdome. maxdome, owned by one of Europe largest independent media corporations, ProSiebenSat.1 Group, is the most popular OTT video service in German-speaking Europe. maxdome offers video-on-demand movies (many in HD and Dolby Digital Plus), television series and original programming, as well as live concerts and sports events. Users can subscribe to the service for a monthly price of 7.99 or purchase or rent individual titles. Monthly subscribers can download videos for playback on mobile devices for up to 30 days. maxdome launched in 2006 on PCs and has been adding client platforms ever since. Today it runs on a wide variety of client platforms, including: PCs and Macs through all major web browsers; ios, Android and Windows mobile devices and tablet devices; A wide variety of smart TVs, Internet STBs, game consoles and connected Bluray players; and Google Chromecast. 22
maxdome s previous multiscreen strategy was based on Microsoft Silverlight, which includes Smooth Streaming adaptive bitrate technology and PlayReady DRM. maxdome also uses Smooth Streaming and PlayReady on Smart TVs, STBs, Blu-ray players, Chromecast and game consoles. maxdome is switching from Smooth Streaming and PlayReady to an HTML5, DASH, and multi-drm strategy. maxdome recently decided to move to a new strategy based on HTML5 and MPEG DASH streaming to address Chrome support and expand beyond PlayReady. It leverages Irdeto Rights to provide multiscreen rights management functionality across all DRMs. maxdome s last step down this path is its implementation for the Chrome browser, which uses HTML5, MPEG-DASH adaptive streaming and Google Widevine DRM. maxdome has built its own HTML5 video player based on Orange Lab s reference player, hasplayer.js. As we continued to expand to new platforms, we found that Irdeto Rights enabled us to embrace an HTML5 and MPEG DASH strategy with the least amount of operational complexity, said Erno Hempel, CTO, maxdome. In the future, we should be able to use this approach to add support for more clients, browsers, and DRMs as the market dictates growing our service and preventing obsolescence while minimizing complication and TCO. 23