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.


Jens Loeffler

Author of The views/posts are my personal opinion.

5 comments on “The Ultimate Technical Guide for the Flash to HTML5 Transition – Part 3/4

  1. Adobe Primetime CDM allows HTML5 premium video to be played back in Firefox.

    When it will be possible to watch 1080p video in Firefox (using Adobe Primetime CDM)? This support is important for places like Netflix, especially for Win7 users (max resolution available is 720p):
    As you will notice 720p is maximum resolution for Windows 7. 1080p is max resolution for Win8.1, and 1080p or 4K is max resolution for Win10.
    IE11 in Win7 supports only 720p. Also Firefox and Chrome support only 720p (in all OS).


    1. The reduced resolution is not a technical limitation, but rather is due to the policies put in place by content owners (most prominently, motion picture studios) who require a “hardware root of trust” to play back full HD premium content. This limits the amount of full HD premium content available on desktop PCs, including the Firefox browser.

      Mozilla added a Google Widevine CDM (Content Decryption Module) in version 47, and removed the Adobe Access/Primetime CDM in version 52. (For reference, the current Firefox stable version is 53.) Hence, content services distributing protected content in Firefox must use Widevine to ensure compatibility with current Firefox browsers.

      For full HD premium content to be made available in the Firefox browsers, one of two things must occur: 1.) Google and Firefox would need to coordinate with hardware manufacturers (including Intel, AMD, and NVidia) to implement a hardware root of trust for the Widevine CDM in Firefox, and/or 2.) content owners would need to adjust their policies to allow full resolution content to flow to the Widevine CDM in Firefox.

      1. Thank you for the reply. I was aware that DRM mechanisms not technical limitations are important here. For this reason, I can play in Chrome 4K Youtube videos, and at the same time only 720p (=> 9x less pixels!) in Netflix.

        Q1: You mentioned that content owners require a “hardware root of trust” to play 1080p. Is it possible for Google, Firefox and CPU/GPU manufactures to implement a hardware root of trust for Widevine/Firefox on existing machines with Win7 or other systems (by driver updates) or is it possible only for newly designed equipment?

        Q2: For some reason IE11 on the same computers after update from Win7 to Win8/10 is able to support 1080p streaming on Netflix. This would mean that hardware root of trust root of trust can be implemented on older machines. Any comment?

        Q3: I have read that Adobe have been working few years ago on improving DRM in Flash so it would be possible to stream 1080p in browsers using Flash. Is it true and are you planning to do that in the future? Maybe Mozilla will be interested in placing Primetime CDM back in Firefox if DRM mechanisms in Primetime will be more difficult to overcome/brake by hackers.
        I have also seen this video but MPEG-DASH is probably not a part of CDM:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Get every new post delivered to your Inbox

Join other followers: