DRM for online video untangled
Is securing online video content now straight-forward, or, is it a case of plus ça change, plus c’est la meme?
Jukwa founder Philip Haggar writes – After many years running Windows Media Digital Rights Management (DRM), over 10 years ago, I remember a visit to Microsoft in Redmond to learn about their new proposal – effectively a standard in DRM – Protected Interoperable File Format. What happened to it?
In the short article below, we’ll trace the origins of online video DRM and its development to today’s Common Encryption and Encrypted Media Extensions for HTML5. We’ll see that it is still necessary to use different technologies for delivering to all browsers and devices, and that server software from suppliers such as Unified Streaming and Wowza are streamlinging the workflow, minimising the number of copies of source files that are needed.
DRM History – Flash and iTunes
Back in 2005, there were only a couple of ways to secure content, depending on whether content was being streamed or downloaded.
Streaming from a Flash server was the most common solution using RTMPS (effectively Flash streaming over an SSL connection) or RTMPE (encrypted streaming from the Flash server). Additionally, Adobe offered SWF verification – locking down receiving applications (SWF players) so that only the authorised players worked – the aim was to prevent unauthorised ‘pirate’ players recording the stream and saving it locally.
While these types of security relied on the server, Microsoft digital rights management also supported offline playback. Windows Media DRM encrypted the video content and then effectively put a hard shell around the file, to make it tamper proof. In the header of the encrypted file, a URL was embedded, which told a player where to find a license server, so that combined with appropriate business logic, a license key could be issued – the URL was known as a License Acquisition URL (or LAURL, sometimes pronounced ‘laurel’). This was a nice solution – it allowed an encrypted file to be distributed and any viewer who opened it with the Windows Media Player would be taken to a page where they could choose to obtain a license and watch the content.
At that time, Microsoft’s competitor Apple was protecting its iTunes content with its own DRM system called FairPlay. However after Steve Job’s put the proverbial boot into DRM, in an open letter in 2007, iTunes started to remove it from audio (although kept it for video).
Again, in that year, Netflix started streaming, using Microsoft’s DRM and the Windows Media Player browser plugin, sadly only available on Windows.
Silverlight, PlayReady DRM and Netflix
Over the next couple of years, playback in the browser, rather than through stand-alone media players, was become more significant. Microsoft’s new Silverlight browser plugin allowed the encrypted content to be played back in most browsers, including on Apple Macbooks, and Windows Media DRM was renamed as Microsoft PlayReady.
Microsoft’s streaming server also moved from the proprietary ASF to HTTP (Smooth Streaming) in 2010, using the newly-announced Protected Interoperable File Format (PIFF). PIFF was a container format, its aim was to support a single file format regardless of the DRM technology used inside.
Adobe was a bit late to DRM, and its first version in 2010 (Flash Access 1) was almost unusable. Although that changed rapidly, it wasn’t a surprise that Netflix quickly adopted Microsoft’s solution, Silverlight and PlayReady with SmoothStreaming, a secure (Hollywood-approved) cross-browser, cross-platform solution which maximised quality and minimised rebuffering.
2010 was also notable for the launch of Apple’s iPad, and in typical style, Apple used its own delivery protocol (HLS – HTTP live streaming) forcing Netflix (or rather, ‘inviting’ Netflix) to adopt this technology for the iPad and shortly after that the iPhone.
As devices for viewing continued to fragment – games consoles, smart TVs and Android for example, PlayReady kept up, by being ported to iOS and Android.
Google, meanwhile, acquired the DRM company Widevine, arguably to keep Hollywood happy during Google’s early forays into TV as well as Android.
Outside of the big 4 (Apple, Microsoft , Google and Adobe), the connected TV manufactures had grouped together to launch Marlin DRM, with SDKs for Android and IOS and the mobile phone operators themselves created the Open Mobile Allowance (OMA), yet another DRM scheme!
At the end of 2010, it wasn’t an easy place for a premium online video provider, with a splintering of DRM technologies (including FairPlay, PlayReady, Widevine, Marlin, OMA and Adobe’s DRM – fairly recently renamed to match its online TV platform as ‘Primetime’) and also of delivery formats (HLS, Smooth and Adobe’s version HDS) combining with a multitude of end-user devices with different size screens and different capabilities. Throw in an eventual move to HTML5 and deprecated browser plugins (Silverlight and Flash) – no wonder there was a need to unify the DRM technologies as DASH was aiming to do for the delivery technologies.
UltraViolet and CENC
While the software companies were creating the DRM tools needed for secure streaming services, the major movie studios were looking at how the consumer could have access to a single digital locker with all of their purchases. The studios (with technology partners) created a consortium called DECE which produced a cloud-based digital rights locker called UltraViolet.
The UltraViolet service, needing to work with a variety of content sources, mandated a Common File Format (CFF) -based on Microsoft’s PIFF specification – and then a common encryption (CENC) scheme, which instead of merging all commercial DRMs into one, supports the 5 different DRM schemes of Adobe, Google, Marlin, Microsoft and OMA with iTunes left to its own ecosystem.
EME and CDM
So, where are we in 2015?
Common encryption media delivered into HTML5 pages can now be decrypted, which is a good thing – not only were the plugins heading for end-of-life but they also appeared to use more power to run.
Encrypted content is handled, in the browser, using Encrypted Media Extensions (EME). EMEs are code that allows the browser to make use of a Content Decryption Module (CDM). The browser itself supports the CDM, which handles the decryption of the content. So you’ve got a browser that chooses to support only a certain type of DRM decryption, (e.g. Firefox only supports Adobe Primetime) but luckily if Common Encryption is used on the source file, you can still decrypt it in any supported browser.
All in harmony? Not quite.
Not all browsers support EMEs, so there is still a need to use Silverlight or Flash as a fallback. And not all devices and browsers support a common delivery format (such as DASH) nor the same codecs.
However the good news is that the major, modern browsers are all supporting common encryption and EME, specifically Safari on OSX Yosemite; Chrome, IE11 and Firefox
Online video platforms still need to deliver multiple bitrate source files with different types of DRM and different types of http wrapping (HLS, HDS or Smooth) for the devices that don’t support common encryption but this is made easier by tools from Wowza and Unified Streaming, that can dynamically ‘http-rewrap’ an MP4 source file and apply DRM in real-time to (or even change the DRM of) both live and on-demand content.
While the desire to take a single file and securely deliver it to all devices was envisioned over 10 years ago, the reality is that there is still no ‘one size fits all’ solution. We haven’t even touched on the costs of licensing the DRM schemes, so before any investment is made, our recommendation is to determine what devices you need your content to playback on, and take it from there.
P.S. If you need support on DRM, or just have questions, just talk to us here
P.P.S. If you’ve made it this far, and are looking for more, then do check out Jan Ozer’s post over here. Not only does Jan know his stuff, but he has some nice graphics to explain things too!