MPEG-DASH: Creating a Standard for Interoperability, End-to-end Delivery

MPEG-DASH: Creating a Standard for Interoperability, End-to-end Delivery

If you work in media, you, like me, have undoubtedly heard the term MPEG-DASH bandied about quite a bit. So, what does this acronym stand for anyway? What is it, exactly? MPEG-DASH is not a codec, a protocol, a system, or a format. Instead, it is a standard (ISO/IEC 23009-1) for interoperability--essentially end-to-end delivery--of video over HTTP.

One of the main goals of MPEG-DASH--and ostensibly the core benefit to publishers--is the ability to reduce the cost and effort of delivering live and pre-recorded premium video experiences using open standards on existing infrastructure. Today's premium video experiences typically include requirements for advertising, security (e.g., DRM), adaptive bitrate playback, captions, and support for multiple languages. Applying these requirements for live and pre-recorded content in a fragmented device landscape results in complexity (read: cost) for publishers’ encoding, packaging, storage, and delivery workflows.

With MPEG-DASH, industry players are endeavoring to take three de facto protocols for video delivery (Apple's HTTP Live Streaming, Adobe's HTTP Dynamic Streaming, and Microsoft's Smooth Streaming) and logically "evolve" them into a composite standard. This makes sense. These three protocols are all very similar in terms of what they're trying to accomplish: efficient and secure delivery of content for adaptive bitrate playback over a HTTP network. However, as Will Law pointed out, they are "80% the same, yet 100% incompatible." 

Today, most publishers are striving for content ubiquity, supporting a range of devices: desktop, mobile Web (smartphones, tablets), smart TVs, game consoles, Internet-enabled television companion devices, etc. Consequently, if publishers want to support adaptive bitrate streaming, they either have to support multiple formats, protocols, and content protection options for broader support across devices and platforms or standardize and limit their device and platform footprint.

Neither is appealing. Everybody is operating inefficiently, from content creation (encoding for multiple formats and languages, packaging for multiple content protection schemes), duplicative storage, multiple content delivery protocols, multiple players with differing capabilities, and inconsistent ad formats.

MPEG-DASH's goal is to streamline the video workflow so that publishers can efficiently manage their video workflow and deliver to any platform and device.

But, is MPEG-DASH a Cure All? Maybe Not.
MPEG-DASH doesn't define the implementation details; instead, they leave the following tasks and decisions to the industry at large:

  • End-to-End DRM
  • Codecs
  • File formats and backward compatibility
  • Royalty considerations and issues surrounding current and future IP

There's still the possibility that if publishers rush into the migration, their technology and workflow decisions would be dictated by the limited or inconsistent support by individual vendors in the ecosystem and the lack of interoperability between the vendors within the ecosystem. Publishers would then need to piece together all the parts of their stack--content delivery, advertising, analytics, encoding, DRM packaging and license management, and playback--to truly solve the end-to-end workflow.

In fact, the fragmentation we have seen with the HTML5 "standard" could be indicative of what we will encounter with MPEG-DASH.

What's in It for Apple?
It's also not clear why Apple would promote MPEG-DASH, given that they have put forth tremendous effort around HLS and elevated it to a de facto standard. Many systems and companies are built around this protocol, and in my view, it will likely be an uphill battle to convince Apple to sacrifice the advantage they have with HLS and instead push for standardization of an alternative to their offering.

History Repeats Itself ... or Does It?

Whenever I assess the viability of a new standard or process, it's helpful to consider it through a historical, comparative lens. In the case of MPEG-DASH, I came up empty. Thanks to a brief break to watch an episode from Season 2 of "The Wire," what ultimately came to mind was the history of containerization.

Consider how companies used to transport goods. Prior to the 1950s, there was no easy and efficient way to do so. But in the mid 50s, the concept of intermodal freight transport and containers was introduced. By allowing goods to be transported by ship, rail, or truck in a standard format, the modern supply chain was born. Agreeing to the standardization of the process was the critical first step. MPEG-DASH is trying to accomplish a similar "sea change," but because it avoids implementation details, there's a significant risk that fragmentation will ultimately enter the equation.
Here are the issues we may encounter:

  • If MPEG-DASH implementations are not backward compatible, then there will be a need to support both MPEG-DASH and HLS. If HLS (or even HDS and Smooth) continues on a path that makes backward compatibility inefficient, publishers are forced to account for MPEG-DASH and HLS … and Smooth Streaming…and HDS…
  • If client-side players (desktop, mobile, Connected TVS, game consoles) cannot broadly support MPEG-DASH, publishers will still be faced with player fragmentation. Player fragmentation flows upstream; this means the entire content workflow--from playback…back to delivery…back to packaging…back to encoding--will be duplicative of the MPEG-DASH workflow. For many publishers, the cost of adoption may not be worth the incremental gains.

Brightcove's Take
Our publishers already face the operational complexity of supporting multiple formats and associated delivery protocols. We will continue to improve our capabilities to reduce the friction and effort needed for all steps in the workflow: content ingestion of multiple formats, transcoding and packaging for multiple renditions and formats needed for cross-platform playback and cross-platform DRM, and adaptive bitrate streaming for desktop, mobile Web, mobile apps, and connected TVs.

While I support the concept of standardization, we're not (yet) at a point where we can eschew all other support in favor of an end-to-end MPEG-DASH scenario. Since MPEG-DASH does not account for the the full breadth and depth of the video ecosystem, early adoption could lead to vendor dependence or lock-down, which I believe is detrimental to our customers.

Ultimately, we hope that MPEG-DASH and the vendors within the ecosystem quickly enhance their capabilities to provide publishers with more flexibility rather than force a proprietary implementation that results in vendor dependency or in an incomplete implementation of the standard. In the meantime, we're rolling up our sleeves and putting fingers on keywords to work on our digital role within the MPEG-DASH ecosystem.

But what do you think? Where will MPEG-DASH be in a year? How about five years from now? I'd love to hear your thoughts in the comments.