Over the last few months, multiple articles in Streaming Media have touted that MPEG-DASH will see broad adoption in 2013 (says Microsoft) or that 2013 will be the year of discovery for DASH (says Adobe). The tone of the articles suggests that DASH will be some kind of panacea that lifts a heavy burden on all streaming media producers, a MacGyver-like savior that will magically align the industry into one format, one encryption strategy, one storage mechanism, and one delivery method.
On the contrary, while DASH will be a useful technology in closed systems such as OTT and broadcast, its broad acceptance in the general-purpose streaming space will make our lives more complicated in the short term, not easier. But only slightly, because the problem DASH solves just isn’t that big a problem, which is the first reason why DASH just doesn’t move my needle.
This realization came to me just after a session on producing for adaptive streaming at Streaming Media Europe last fall. I concluded with a short overview of DASH, railing on about how hard it is to support HTTP Live Streaming (HLS) for iOS devices and Dynamic Streaming for desktop devices, with the attendant duplication of effort, wasted storage, and other complications. You know, the typical DASH justification.
After the class, I started mentally debriefing the session and realized that 99% of the hassle of supporting multiple adaptive streaming formats is handled automatically by streaming servers such as the Wowza Media Server, Adobe Media Server, Microsoft’s Azure Media Services, or Real’s Helix Server. As you probably know, these servers can accept one incoming group of adaptive files and change the container format and add metadata files as necessary for transmitting to different players — say, MPEG-2 transport stream in, with HLS out for iOS devices and HDS out for Flash. They can convert closed captions for the various targets and even apply platform-specific DRM. No muss, no fuss. It’s not like any streaming producers are staying up nights figuring out how to service multiple adaptive streaming targets.
The second reason I’m down on DASH is that it’s not going to reduce the number of adaptive formats that producers have to support. Apple has stayed conspicuously mum on its intentions to support DASH, as has Google, and beyond PCs and Macs, iOS and Android are without question the most important priority for virtually all content producers. So, DASH may replace Flash as the desktop platform, but unless something changes, it’s not going to be the sole adaptive platform streaming producers need to support. The only good thing you can say about that paradigm is that supporting DASH in addition to HLS won’t be that hard, precisely because of point number 1; it will be just another check box in a server product.
The third reason I’m doubting DASH is that there’s a very strong chance that HLS will conquer the general-purpose adaptive streaming market before DASH gets out of the gate. The JW Player now supports HLS playback, as does Zencoder’s Video.js player, and it’s a feature so desirable that you can expect all similar players to adopt it in the short term.
What about service providers? Unicorn Media, Inc., which specializes in helping companies monetize their video, also delivers HLS to Flash Player-enabled computers via its player. Why support two technologies when one gets the job done? What about OTT? Pretty much every existing OTT box, including Roku, Boxee, Google TV, and even Xbox, can play HLS streams.
Today, right now, inmediatamente, if you deploy a player such as JW, you can play HLS streams on the desktop, on iOS devices, on Android 3.0 and later devices, and most OTT boxes. You already have one adaptive streaming format that plays everywhere, months before a usable DASH spec is finalized. And that feels like one marketing advantage that even MacGyver can’t overcome.
This article appears in the April/May 2013 issue of Streaming Media magazine as “DASH Is Overrated.”