HTML5 Guide for Broadcasters: DRM and Advertising in a Flash-Less World

Steve Jobs was the first to announce Adobe Flash’s impending doom during the reveal of the original iPhone in 2007. Since then, plenty of ink has been spilled about Flash’s impending death, seemingly always just a few years on the horizon as browser makers chipped away at support for the ubiquitous multimedia plugin. Now, finally, Adobe has made the Flash funeral official: last year Adobe stated publicly that by 2020 Flash will no longer be officially supported. In the meantime most modern browsers already disable Flash from loading by default.

A New Challenge for Broadcasters

Major broadcasters have become addicted to the convenience of a Flash-based development and publishing workflow. Let’s face it, whatever your opinions are of Flash as a runtime environment and ActionScript as a language, Adobe’s unified ecosystem running across a broad range of devices and operating systems with solid features like integrated DRM has been a major selling point for broadcasters of all sizes. Adobe’s vertical integration with creative products, cloud hosting, encoding, ad serving, analytics and other video streaming add-ons (many packaged under the Primetime brand) offered an attractive set of tools all nicely packaged from one vendor.
Just like traditional hardware replacement lifecycles, a video streaming technology also has a limited lifespan with regular investment cycles. Flash was a dominant player in the last cycle, now HTML5 is the dominant player in the current investment cycle. Compounding the complexity of this next technology lifecycle, the death of Flash comes at a time when the media landscape’s fragmentation is accelerating. With the addition of newer devices and platforms like mobile, OTT, smart TVs, streaming sticks, and the next generation of Android-based set-top-boxes, it’s hard for broadcasters to keep tabs on what devices are available, let alone to maintain a unified publishing workflow to reach new audiences!

What’s a Broadcaster to do?

In a Flash-less world with increasing fragmentation, it can be challenging for broadcasters to forge a path ahead. To help you on this journey, first we’ll review the internals of the modern HTML5 video workflow.

HTML5 Video Began a Decade Ago

It’s been more than 10 years since the video element was first proposed to be included as part of the HTML5 standard. Opera brought attention to the fact that at the time, video playback was supported only by “proprietary closed solutions that rely on plugins to display in a web page” (e.g. Flash), and they took aim to make video a “first-class web citizen.”  While they were successful in adding the element to the HTML5 standard, their well-intended and necessary effort created the unintentional side-effect of fragmentation. HTML5 video is plagued with competing standards for codecs, captions, content protection, and advertising. For Broadcasters, HTML5 video still presents considerable challenges.

Standardizing On A Codec

One of the many things that users took for granted with Flash video playback was its built-in support for the AVC/H.264 codec.  H.264 has many patent holders and is licensed by the MPEG-LA.  This prevented open source projects like the Mozilla Foundation from adopting the format.  Fortunately, in 2013 CISCO stepped forward with a major contribution:

“We [CISCO] plan to open-source our H.264 codec, and to provide it as a binary module that can be downloaded for free from the Internet. Cisco will not pass on our MPEG LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use…I’m also pleased that Mozilla has announced it will enable Firefox to utilize this module, bringing real-time H.264 support to their browser.”

While AVC/H.264 has become the current de facto standard, the road ahead brings uncertainty with new formats like HEVC and now AV1.  New codecs are needed to satisfy our ever increasing desire for better picture quality at lower bitrates.  Broadcasters seeking to deliver premium video must work continuously to ensure that they are meeting the demands of an evolving ecosystem.

Handling Advanced Use Cases

With HTML5 video, it is up to the browser itself — not Flash — to retrieve video segments, decode them, and play the media data.  This makes playback of a video relatively simple for non-broadcast use cases, but presents a bit of an issue for publishers that want more visibility and control. The Media Source Extension (MSE) is a JavaScript API that was introduced by the W3C to allow publishers to have control over things such as adaptive bitrate (ABR) logic, splicing, ad insertion, and time-shifting.
The MSE API allows a JavaScript player to dynamically pass media segments to the HTML5 video element by creating a “MediaSource object”.  The MediaSource buffer takes the place of a file URL for the src of the video elements.
While all of the leading desktop browsers, Chrome, Edge, Safari, and Firefox have adopted Media Source Extensions, the individual implementations vary slightly between browsers, which can make life difficult for broadcaster development teams.
It’s important to understand that when leveraging the Media Source Extension API, the responsibility for parsing the manifest file (i.e. the m3u8 or mpd) falls to the player JavaScript logic. Broadcasters must therefore carefully evaluate their choice of HTML5 player technology providers to be sure that it provides optimal ABR heuristics and is capable of properly extracting metadata that would be used to drive things like ad insertion, CDN redundancy, and DRM playback.

Content Protection

Another major obstacle that prevented broadcasters from adopting HTML5 was their need to protect content with DRM.  Flash offered the closest thing to a “silver bullet” by including support for Adobe Primetime DRM (formerly known as Adobe Access).  In order to satisfy the need for protected content, browsers now offer the Encrypted Media Extension (EME).
An EME is a JavaScript API that allows web applications to communicate with content protection systems.  A web application will use the EME API to pass messages between the Content Decryption Module (CDM) and a Key Server that provides the decryption keys.  The CDM is defined outside the EME specification.  The CDM can be software or hardware, and its primary role is to decrypt the media in a secure way.
It is the Hollywood studios that make the rules when it comes DRM requirements.  One of the biggest failings of Adobe Primetime DRM is that it did not have “hardware root-of-trust,” which means that in the eyes of the Hollywood studios it was more susceptible to an attack.  Most broadcasters are required to use a DRM technology that is natively supported by the device.  While there is rising standard called CMAF that may bring an easier solution, the current reality is that broadcasters must deploy a multi-DRM approach.  This means generating both DASH and HLS, and leveraging some combination of Widevine, PlayReady, and Fairplay.
It should be noted that the HTML5 Encrypted Media Extension standard is not a complete content protection solution in and of itself.  A web application must confirm the user’s identity and determine whether or not they are authorized for viewing the content before supplying them with a token that can be exchanged for a DRM license.  This means that broadcasters must either stand-up their own licensing backend, or work with an existing provider such as BuyDRM, ExpressPlay, or others.
Find more information about DRM in our DRM Whitepaper.

Adopting the Browser Security Model

When delivering video on the web, it is very common for the video to be hosted on a CDN using a different domain than that of the web page.  With Flash, all that was necessary was to host a small text file, called the cross-domain policy file.  The cross-domain policy file was an XML document that granted the Flash player permission to handle data across domains.
In the HTML5 world, broadcasters must be certain to understand and implement Cross-Origin Resource Sharing or CORS.  Instead of defining the permissions in a stand-alone file, the policy information must be contained within the HTTP response header.
Complicating things further is that browsers don’t like mixed HTTP / HTTPs content.  With mixed content the browser will either display an error or stop the content from loading altogether.  Broadcasters will need work with their CDN to make sure they are able to deliver their video over HTTPS.

Advertising

In its day, Flash provided a standard interface with which ad technology companies could integrate and provide an SDK module.  Most all ad technology vendors, including Google and FreeWheel, have since created new SDKs for HTML5.
The IAB is a standards body that helps define advertising formats.  VPAID is a commonly used format that provides support for rich interactivity with a player UI.  The initial definition, VPAID 1.0, was deprecated in November 2016 as it defined the media creative as a Flash SWF.  The more recent VPAID 2.0 format uses JavaScript instead, and is compatible with HTML5 players.  In June of 2017, Google ceased support for their IMA SDK for Flash and Flash VPAID ads in the HTML5 SDK.
Server-side ad insertion is also possible with HTML5, and the complexity between browser environments is a contributing reason for its growth in popularity.  However, it’s important to remember that an ad must be measured in order for the advertiser to actually pay for it.  While server-side beaconing exists most advertisers will prefer client-side ad beaconing (at least until VAST 4.0 is adopted), which means that careful consideration must be made to ensure that the HTML5 player can listen for the ad events such as ad start and completion.

Flash to HTML5 Comparison Table

Finally, How to Choose an HTML5 Player Technology

Now that we have a good understanding of the foundations of HTML5 video, it’s time to consider which player implementation will meet your needs.
The universe of options for HTML5 players includes everything from completely open-source players like HLS.js and DASH.js, to hybrid open-source with additional licensing and paid support options such as video.js (via Brightcove) or JW Player, or closed-source with licensing and paid support such as Bitmovin or THEOplayer.
When evaluating these player options it’s important to ask yourself these questions:

1. What is the true total cost of ownership (TCO) of each option? This TCO goes far beyond licensing costs and extends into cost of maintenance and support — whether that’s provided by your team or outsourced. How much R&D does your engineering team need to put into both the initial implementation and ongoing support? When bugs are found, how much is it costing you to fix these issues? What is the cost of lost revenue when tickets on bugs in open-source projects remain unfilled? What is the cost of maintaining separate codebases and API integrations for web vs. native players?
2. Do you need commercial support or will you handle everything internally? If you pay for support, does your player vendor own the entire playback stack, or are they simply wrapping their UI on top of an open source project? This affects the ability to quickly rectify issues found in production.
3. Will your chosen technology allow you to have control over the roadmap?  Consider these features:
   1. Multi-codec support, and the addition of new formats.
   2. Advertising insertion, both client-side and server-side.
   3. Adaptive Bitrate (ABR) handling and tweaks.
   4. Metadata handling
   5. DRM integrations
   6. Speed

Now What?

We may never return to the simplicity of Flash’s “write once run anywhere” value statement, but well-designed cross-platform player systems offer many of the same conveniences as Flash while also adding in newer adaptive streaming technology, advanced QoS monitoring and next generation client and server-side ad insertion features.
At Bitmovin we’re experts in helping video publishers make the transition to this brave new generation of online video. If you’re ready to make the jump, or need help improving your existing architecture, please contact us and we’ll be happy to work with you to map out the right path to success for your needs.

Image credit for the Flash gravestone: Joel Oughton