Playready 4 will bring closure to the DASH dream: one single OTT format to rule them all

Editor’s note: the initial version mistakenly identified AES-CTR as “AES-CTB”, which doesn’t really exist.

What got us here?

2017 was a weird year. It’s not often that the OTT video industry comes together to create simplify the industry player’s lives. It was tried before and failed. Then DASH appeared, it promised to rule on the OTT format wars, by proposing a single standard format, but at the end of the day, it failed to deliver its promise.

DASH is a single standard, but as any other bad standard, it allows for options, incompatible options. It’s these options which allows standard compliant implementations to be incompatible between themselves, thus running the whole idea. These options include the following aspects:

  • How the index file (in the DASH case, MPD file) is refreshed, also known as “LIVE” and “On-Demand” profiles
  • Which actual streaming format to be used, allowing both the old TS (transport stream) and the newer fMP4 formats
  • Encryption method. Here things got murkier, and even at first sight there is one single encryption method, also known as Common Encryption or CENC, the small print allows for 2 incompatible options AES-CBC and AES-CTR.

The reason why DASH allows for so many options is mostly related with historical reasons. When DASH was created, there was (and to some extent, still are) two main OTT formats: HLS which is supported by Apple, and Smooth Stream which was created by Microsoft. Because both Apple and Microsoft couldn’t reach a common understanding on creating a single standard, so they simply agreed to disagree.

This meant that DASH takes both HLS and Smooth Stream and mostly repackages it around a single standard, with options each of the previous formats, with one single exception:

  • The index format is not recycled from any previous format, and a new file format was created, the Media Presentation Description, henceforth MPD. This may seem strange, but it’s mostly an empty win as far as the standard goes, as this is not where the money is.
  • From HLS, comes the support for the Transport Stream file format and the AES-CBC encryption.
  • From Smooth Stream, comes the support for fMP4 and the AES-CTR encryption.

So, when the standard match ended, there was a tie between Apple and Microsoft, but at the end of the day, everyone lost, as Apple’s DASH implementation and Microsoft’s DASH implementation here incompatible between themselves.


Then weird things started to happen

The first surprise came from Apple, which on the 2016 WWDC announced the support for fMP4. Although this was a huge initial step it still didn’t meant any actual win.

The problem lies on where the money is. The OTT business case comes from the ability to aggregate the unicast streams, actually creating an unique stream to each consumer as close to the consumer as possible. This often includes the typical components as the following diagram depicts.

The Typical ABR workflow used for OTT services
The typical ABR workflow used for OTT services

For most, if not all OTT services, the biggest cost component is related to the CDN component and the connected pipes, both of which can be minimised if each unicast stream can be cached and served closed to the end user. For this to happen, for the same component, one single copy of the component needs to exist. Unfortunately this never happened. Before, the CDN needed to contain two copies of the same content, one for HLS and another for Smooth Stream.

When DASH was announced, nothing really changed: where previously was Smooth Stream content, now it’s DASH, as both share the same underlying file format. Yes, you’d need to support both Smooth Stream’s manifest files and DASH’ MPD, but that’s really minor effort, load and cost.

When Apple announced support for fMP4, people cheered until they realised that Apple would change the file format and the encryption method, but not the encryption format. Apple kept the AES-CBC version used on HLS. What it means is that before you’d have 2 copies of each content, and now you still have 2 two copies of the same content, but instead of having one copy on HLS format, and another on DASH, you’ll have 2 copies on DASH, but two incompatible DASH versions.

At the end of the day, this means twice the storage cost and half the cache’s hit rate, or an overall cost increase.


Leave a Reply

Back to Top