Playready 4 will bring closure to the DASH dream: one single OTT format to rule them all
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 my 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.
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.
Microsoft closed the loop
Microsoft announced the upcoming Playready 4 DRM format prior to the 2017 IBC. As often on what regards to Playready, details are few and far between, except for a small but extremely important detail: support for AES-CBC.
What this means is that sometime in the future, any OTT CDN may only need to support one single copy of each content. No more on-the-fly repacking, no more just-in-time encryption (read bellow* for further details on this), you just maintain and cache one single copy of each content. As compared with today, it means that storage requirements decrease by half, and cache hit rate automatically doubles.
From an OTT operator perspective, this means less cost on the CDN and network pipes.
Now, this will not happen tomorrow, as Playready 4 won’t actually be available for months, compatible devices are not expected before end 2018, and then, until all devices are ported from Playready 2.x to Playready 4 both copies of the same content are necessary. Actually, a significant portion of Playready 2.x devices won’t ever support Playready 3, not to mention Playready 4, to these gains won’t happen before the end of the decade, but it does shows light at the end of the very dark OTT format war.
(*) Although real time repackaging won’t ever be needed, just-in-time may still be required, in order to support encryption key rotation as required by the content providers, but it will only happen on the centralised content storage. This still means that striate requirement will decrease and cache hit rate will double, only CPU requirement on the centralised storage may be slightly higher, but not significant so.
Originally published at Too many Bits, too little Bytes.