The Ultimate Technical Guide for the Flash to HTML5 Transition – Part 3/4

This section will describe HTML5 deployment best practices regarding multi-DRM, ad insertion, and cross-device optimizations

 

3.1 Format and DRM System Fragmentation

Unfortunately, the industry has not standardized yet on a single format and interchangeable DRM system, which means to support HTML5 DRM across all browsers, the following formats and DRM systems are required.

• Chrome – Widevine – MPEG-DASH
• Internet Explorer / Edge – PlayReady – MPEG-DASH
• Safari – Fairplay – HLS
• Firefox – Widevine – MPEG-DASH

MPEG-DASH with PlayReady and Widevine can be combined into a single stream with common encryption (CENC), but for Safari, Sample Based Encryption HLS with Fairplay is required.

This means that not only are two formats required for playback, but also the ad stitching solution needs to either support both (often the case with server-side solutions), or be agnostic from the format (sometimes available with client-side solutions). Ads need be available in both HLS and MPEG-DASH formats for a seamless cross browser/device experience

 

3.1.1 Single Format Vision with CMAF

MPEG-DASH has been the most promising initiative to become a single independent standard, but is held back by Apple not adding MPEG-DASH support with Fairplay to Safari browsers and iOS devices, and MPEG-DASH’s higher than expected licensing fees.

This is where CMAF comes into play. CMAF is an ongoing MPEG standardization of the FMP4 container, and could be the foundation of the long-awaited single streaming format for cross-device DRM. A more detailed overview of CMAF can be found here.

Specifically once an HLS manifest with a CMAF/fMP4 segment is combined, it opens an interesting potential future path.

The following options are available today:

• Chrome – Widevine – HLS manifest with fMP4 segment (CTR encryption mode)
• Internet Explorer / Edge – PlayReady – HLS manifest with fMP4 (CTR encryption mode)
• Safari – Fairplay – HLS – HLS manifest with fMP4 (CBC encryption mode)
• Firefox – Widevine – HLS manifest with fMP4 (CTR encryption mode)

Now you might have noticed that the encryption mode is not standardized – once all the systems either support CBC or CTR, we truly have a single format. Until then, you have to use two different CMAF/FMP4 segments – one for CBC, and one for CTR.
Alternatively, Chromecast and Android 7.0+ have started to add support for HLS with Widevine (with TS container).

 

3.1.2 Streaming Format Strategies

When forming a strategy regarding what formats to use, there are two factors:

1. To protect content on a level that can be used for HD/4k, in most cases the DRM system that is native to the platform and uses hardware security needs to be used. What are the required container formats and encryption for native DRM I need to support to reach all my target devices?
2. What formats can my packaging / ad monetization ecosystem support?

In general, the following formats are required:

Widevine (e.g. Chrome, Firefox, Android) – fMP4 with CTR (MPEG-DASH, CMAF) on all devices, Android 7.0 and Chromecast also supports TS with CBC (HLS)

Playready (e.g. Edge/IE, Xbox) – fMP4 with CTR (MPEG-DASH, CMAF).

Fairplay (Safari, iOS, TVOS) – TS/fMP4 with CBC – requires HLS manifest (HLS, CMAF)

 

To summarize there are three main strategies:

1. Use MPEG-DASH with CENC as main format, and HLS + Sample Encryption for Apple browser/devices. For ad insertion, use a solution that both supports MPEG-DASH and HLS.
2. Use HLS manifest + CMAF/fMP4 segments as main format, and have two different versions of the container segments – one for CTR, one for CBC. Once the industry aligns around either CBC or CTR, switch to a single segment container. Use ad insertion that is compatible with HLS manifest + CMAF/fMP4 segments.
3. Use HLS manifest + TS segments (traditional HLS) where available. (Chromecast, Android 7.x, Apple browsers/devices, and software DRM solutions for other platforms). Note that in most cases DRM software implementations will not provide the level of security required for HD or 4k content approval. Use ad insertion that is compatible with HLS.

From all of those approaches, #2 seems to be the most likely one to combine strong security with a potential single format, but it is not reality yet. It remains a vision.

 

3.2 Ad Insertion

As described above, when DRM is used, the ad insertion system needs to not only support DRM, but also the associated streaming formats, which is not necessarily an easy task with advanced ad insertion use cases such as seamless mid-roll ad insertion or live/linear ad replacement.

When DRM is not needed, it’s easier. HTML5 becomes another HLS enabled client, and video monetization that worked in Flash and on devices often can be transferred without major technical hurdles.

However, there is one exception, interactive ads. Interactive ads based on the IAB VPAID standard have become more popular and are often valued higher than regular video ads with a higher CPM.

VPAID ads have been traditionally authored in Flash, and need to be available in Javascript format for the HTML5 transition. Thanks to the changing browser landscape, Javascript-based VPAID inventory has been on the rise. The advantage of forcing this transition is that HTML5 ads, which now only work on desktop and mobile browsers, can also be used in mobile applications.

 

3.3 Cross Device Optimization

HTML5 video is not the same across all browsers and devices.  It has different levels of support and behaviors depending on the browser and device. This unfortunately leads to fragmentation that requires cross device optimization and testing.

For example, MSE support differs between Chrome, Edge, Firefox and Safari, and often on connected TV devices is not on the same maturity level. In addition, Safari on iOS only supports MediaElement and not MSE, which is an Apple specific video API handling all the video playback directly. Also users who didn’t update their browsers might still need Flash playback to be reached.
From a UI perspective, there are differences between a video player running on the desktop, on a smartphone or on a tablet. All this requires testing and optimization.

 

3.4 Summary

There is complexity deploying HTML5 with advanced video use cases that go beyond what was needed with Flash. I highlighted some of the challenges in this section, but kept the solution intentionally open. While part one, part two, and this part of the series were focused around generically understanding what is technically needed for the Flash to HTML5 transition, the last part describes how Adobe Primetime is providing a solution to help with the transition.

 

Part 1: HTML5 Basics

Part 2: Understanding HTML5 Security

Part 3: HTML5 Deployment Best Practices – Multi-DRM, Ad Insertion, and Cross-Device Optimizations.