DASH or HLS? Which is the Best Format Today?

Home/Blogs/DASH or HLS? Which is the Best Format Today?
By | 2017-02-23T00:47:40+00:00 October 21st, 2015|Blogs|Comments Off on DASH or HLS? Which is the Best Format Today?

The survey results are in:


So, out of 87 responses, over 50% chose DASH, while over 30% choose HLS. The balance chose to explain why, and there were some very useful comments. 

“Not sure why i wouldnt cover both options.”

“DASH also doesn’t work on OTT boxes like AppleTV and Roku, where HLS does. DASH does have support for VP9 though, which is a great quality / cost saver. We’ll see about HEVC in the future…”

“Its not a selection question there is a need to use both for complete coverage and it costs almost nothing to add one on top of the other when using cloud based encoding and delivery (CDN) services.”

“Don’t choose just one. choose wowza and be ready for all formats!” (editor’s note: not from a Wowza email address)

“DASH, but what I’d really like is MP4 fragments with a simpler manifest format than DASH.”

The column referred to below has been submitted, but is not yet published. I’ll include a link when it’s public. 

Thanks to all who contributed by taking the poll or via comments. 


My next column for Streaming Media magazine is about the HLS vs DASH format decision. As you know, many web producers are moving away from RTMP-based Dynamic Streaming, or even HDS, and must choose between HLS and DASH. Twelve months ago, HLS was the clear best choice. Twelve months from now, DASH is probably in the driver’s seat. But what about today? 

To help firm up my analysis, I created two pro and con charts; one for HLS, the other for DASH. Both are presented below, with a touch of explanation for those points that are not obvious. Anyone who wants to weigh in, please do. Comments are free, and no salesman will call.

I’ve also included a one question survey for those who don’t want to comment but do want to weigh in.you can take the survey below.

Not shown in the charts is the obvious. Both formats enable developers to distribute one adaptive group of files to a very broad range of target platforms, though you’ll need an app to distribute DASH on the iOS platform. You’ll also likely need MP4 files for Flash or single-file HTML5 fallback, but that’s very dependent upon the player technology that you choose, and perhaps the subject of a different analysis. 

HLS Pros 

Let’s start with HLS.


The pros are pretty clear. HLS is a mature technology, so advertising and DRM, such as it is, are in good shape. Obviously, HLS plays natively on iOS devices and on Safari on the Mac, and it’s very well supported in the encoding world.

As you may know, many off-the-shelf (OTS) players, including the JW Player, support the playback of HLS on desktop and notebook browsers, but do so by using the Flash or Silverlight plugins. More on that in a moment. Just to be clear, not all OTS players support HLS playback via the Flash or Silverlight plug ins. The most notable exception is the THEOplayer from OpenTelly, which does not require any plugins for HLS playback.

HLS Cons

On the con side, HLS is a proprietary technology, so ultimately it will go away, and it really hasn’t advanced much in the last 10 years. Every file you encode into HLS format today will ultimately become obsolete, which means you’ll have to re-encode it down the road into a different format. Beyond that, the only natively supported DRM is encryption, so to really protect your content, you have to wrap HLS streams in another DRM technology like PlayReady or Adobe Primetime DRM.

Those OTS players that support HLS playback via Flash will lose that capability once the Flash plugin goes away. So while you’re moving away from Flash-based formats, you’re still reliant upon Flash for playback. If your concern is that Flash is going away soon, this is a big deal.

A key point for me is that browser support for HLS will never grow. In two or three years, native DASH support will likely be universal among all relevant browsers, and all mobile devices not manufactured by the big fruit, not to mention STBs, Smart TVs, and other devices. So while there are major gaps in direct DASH coverage today, usually addressed via some form of fall back, in two or three years that won’t be the case. In contrast, the current major gaps in HLS coverage will never go away and you’ll likely always need a plug-in, an OTS player, or both, to play HLS streams in a desktop or notebook browser (other than Safari on the Mac).

Here are the DASH pros and cons.



As I just finished saying, DASH is a standard and support will grow over time, so supporting DASH will grow easier over time. DASH plays natively today in most recent Chrome and Android versions, and while support among encoding tools and OTS players isn’t quite at the HLS level, you will have multiple options for both.


The big negative is that native support in most browsers is not currently there. I say Microsoft is the major culprit because they are limiting DASH support to Windows 8 and newer, which means IE11 and later. The pie chart below shows operating system market share from netmarketshare in September, 2015, the most recent period reported. As you can see, Windows 7 has more two and a half times the market share of Windows 8 and 10 combined, and Microsoft is leaving these users, and those still on Windows XP, stranded for an IE-based DASH solution. This really stinks because IE still has a very high utilization rate, particularly among corporations, government offices, and educational institutions.


Moving on to the next DASH con, there is obviously no DASH support on the iOS platform. However, there are multiple SDKs, including ones from castLabs and BuyDRM, that allow developers to create apps that do play DASH-encoded video on the iOS platform. That doesn’t give you native, browser-based DASH playback, but it gets the same content playing on the iOS platform so you don’t have to encode in two formats.

As with HLS, some OTS players, if not all, rely on Flash or Silverlight for playing back DASH streams when the browser doesn’t natively support DASH-based playback. Interestingly, however, you wouldn’t expect a browser to drop Flash until it supported DASH completely. Even Chrome didn’t drop Silverlight until DASH was available. So if a browser drops Flash support, it’s extremely likely that you’ll be able to move forward with native DASH support. That won’t be the case with a Flash-based HLS solution; If Flash goes, HLS goes, at least for those OTS players that rely on Flash.

The big DASH con, in my humble opinion, is that DRM under the Encrypted Media Extensions is a mess, which you can read about here. Advertising support is coming, so it’s not nearly as well developed as Flash or HLS. In a nutshell, this is why many broadcasters have yet to migrate away from Flash, but if you don’t need DRM or advertising support, that’s obviously irrelevant.

Where does that leave us? I’m honestly still up in the air, though leaning towards DASH. What do you think? What am I missing? Which format would you choose if converting over today?

Here’s the survey. I’ll post the results over the next few days. 


#1Ray StantzSaid this on 10/21/2015 At 06:34 pm

"What am I missing?"

That the MPEG LA is trying to form a patent pool around MPEG-DASH and, if successful, will presumably requirement payment for a patent license. This will stunt MPEG-DASH's growth.

Royalty-free works better. Consider HEVC vs VP9 support today. HEVC has licensing costs (and licensing uncertainty) whereas VP9 is royalty-free. No browser today supports HEVC whereas 3 browsers support VP9 with a fourth (Microsoft Edge) on the way.

#2JanSaid this on 10/21/2015 At 07:03 pm

Hey Ghostbuster:

- good one on the MPEG LA - I had forgotten.

- DASH is codec agnostic; YouTube is using it for VP9 (same potential license issue). 

Thanks for your contribution. 


#3Yury UdovichenkoSaid this on 10/21/2015 At 07:31 pm

Regarding the patent pool. It was only a "call for patents" which means that MPEG-LA wants to create it, but there's no sign of patent holders to actually joing the pool.

Will Law, vice chairman of DASH Industry Forum, mentioned during IBC 2015 DASH SuperSession Q&A - there is no intension from DASH founding companies to join any pantent pools. If some 3rdparty does, it will be crusial for those DASH founders to push back to keep it free. As Will said - "you can't charge people for XML file format".

So patents should not be an issue, even though there is some movement around it.

#4Nikos KyriopoulosSaid this on 10/21/2015 At 07:53 pm

Hi Jan, great initiative!

Some additional points here:

1. MPEG-DASH can deliver substantially lower end-to-end latency compared to HLS. This is especially important for eMBMS/LTE-B workflows (e.g. venuecast for live sports). Further, the initialization segment concept in MPEG-DASH, enables players to setup/warm-up even before streaming/broadcasting has begun, further shorterning the channel start/switch time. The template-based manifest of MPEG-DASH also helps here, as it does not need to be updated and can be cached at the network edges, while HLS manifest is updated periodically and needs to be propagated multiple times per minute.

2. MPEG-DASH supports both TS and MP4/ISO BMFF media segments. The MP4 box-based archirecture enables leaner delivery and also provides for easier expansion (custom boxes etc), MPEG-2 TS in generally more verbose especially in strict standards-compliant terms (e.g. transport-level CBR padding).

3. MPEG-DASH supports both index and time based references, enabling players to sync based on a common wall-clock (e.g. NTP PTP GPS). This makes is easy to synchronize the same content across multiple players or between views (e.g. multi-camera event).  

I hope these help



#5OrenSaid this on 10/22/2015 At 01:37 pm

Utilizing DASH doesn't necessarily mean re-encoding your content. 99% of the time, both HLS and DASH use the same h.264 source files which can be repackaged just in time.

#6JanSaid this on 10/22/2015 At 02:11 pmIn reply to #5


You get the gold star. I just spoke with consultant Jeff Tapper who said most of his larger clients are either encoding on the fly at the edge with their CDN (Limelight/Akamai) or transmuxing with a streaming server (Wowza) so they're using a very close to native format for every target; DASH for Chrome/Android, HLS for iOS, and one or the other for other browsers, with fall back to Flash or MP4.

So you're right. So long as you find a service that can use the same MP4 files there is no heavy transcoding down the road; just a fairly light (and much less expensive) repackaging for the target.

Sometimes the best either/or choice is BOTH! (to be fair, one commenter in the survey did mention this as well).

Just one cautionary note; this schema works most easily when the content is played back from the web. If there is a requirement for offline viewing, it could be problematic. 

Thanks for your note.


#7BenoitSaid this on 10/22/2015 At 03:27 pm

Nice post and comments; here are additional thoughts of mine:
1/ I think that the HLS con "Proprietary so going away some time" is not so relevant: it is "probably not soon" as indicated but also standard protocols may go away. We can see some proprietary systems staying longer than some standards! I see that the drawback of proprietary is dependency on decision of the owner of the protocol rather than "will go away". BUt then it is also a Pro to have fast decision and less IOT issues.

2/ OpenTelly is wrong in saying that they are the only one that don't need Flash or silverlight plugins. Squadeo player is another example of HLS player that can work with HLS and single DRM on Android/iOS/Windows/Mac independently from browser plugin technologies. I would appreciate Squadeo has same treatment as THEOplayer;-).
3/ Another DASH Con: lots of patents are owned by Qualcomm. When using Qualcomm chipset, this is safe. But on other chipsets... well, take your bet! And also I am not convinced Apple will embrace DASH soon due to this.

4/ And another cons of DASH linked to DRM is a mess is that the total cost to manage DASH systems is higher than HLS due in particular to the cost of multiple DRM mangement.

#8JanSaid this on 10/22/2015 At 03:45 pmIn reply to #7


Thanks for your comments; I didn't say OpenTelly was the only technology that played HLS without Flash dependencies, I said they were most prominent.

In terms of equal treatment, I didn't in any way claim that this article included all relevant OTS companies. I know OpenTelly because they reached out to me previously, and spoke on a panel with me at Streaming Media East, along with Bitmovin and edgeCast. JW is the 600 pound gorilla and market leader. I've written on transitioning from Flash to HTML5 many times and the only piece of advice I can give you is that if you want equal treatment in these articles, make an equal effort to get in touch with the author. 

Above was a good start, thanks again.


#9Colin WittSaid this on 10/23/2015 At 01:39 pm

I'm going to be the guy who says "both" but under specific cirtumstances.

For live delivery, I recommend HLS to clients, and that is what I deliver in the OTS players I work with.  I believe the maturity of the format is critically important when dealing with a live event, as well as the breadth of supported players.  You just don't have time to fix client issues or troubleshoot things on the fly, and you need to use a format that you know works every time.

For on-demand delivery, I say "both."  Encode to H.264 today and segment for both.  Use something like Wowza to handle the segmentation and manifests for you if you like.  Then write your player to preference DASH in HTML5 native when possible, and fall back to HLS native or HLS over Flash.  I'm generally going to support more formats (and even more adaptive renditions) when delivering on-demand compared to live.

When the native browser player market catches up to DASH, and when more CDN vendors start offering it as their standard live delivery formats, then I'll jump.  But not yet.

#10Jan OzerSaid this on 10/23/2015 At 02:09 pmIn reply to #9


Wow, thanks for the insightful and obviously well thought out response.


#12Pierre-YvesSaid this on 10/27/2015 At 05:24 am


You're confusing DASH/HLS browser support with MSE support. DASH is never "natively" supported in browsers, it relies on a JS library pumping data into an MSE H264/AAC decoding pipeline in data generation mode (similar to NetStream.appendBytes() in Flash, only 5 years later... ^_^). As soon as you have a working MSE implementation in your browser, you may actually support _any_ streaming protocol (with the right JS library, potentially transmuxing on the client side if the network fragment format does not match any of the local MSE accepted formats).

For HLS in most of the browsers, see: https://github.com/dailymotion/hls.js. Wherever DASH works, HLS will work too with this library. No need for Flash anymore. And as long as Apple does not provide some MSE support in their mobile browser (Mobile Safari), you'll have to keep HLS around to address those devices.


#13JanSaid this on 10/27/2015 At 07:56 amIn reply to #12Pierre-Yves:

You are correct on both counts, thanks for adding some precision and explanation. When I say native DASH support, I meant that the browser supports the Media Source Extensions; I'll try to be clearer going forward.

Thanks for writing in.

Jan#14Alex ZambelliSaid this on 10/27/2015 At 07:05 pmIn reply to #12

Or similar to Silverlight's MediaStreamSource, 7 years later... ;)

#15Alex ZambelliSaid this on 10/27/2015 At 07:13 pmIn reply to #12


I think you're conflating encryption and DRM and therefore drawing some misleading conclusions in that area. Encryption is encryption, and DRM is digital rights management. Both are used for the purposes of content protection but they are not the same thing. DRM is used to control who and how gets access to the content. HLS, according to the IETF draft spec, only standardizes the encryption method, so I don't think it's fair to say its DRM is in good shape.

DRM for HLS is almost a bigger mess than DRM for DASH, since at least for DASH you know which DRM providers support CENC and the products are designed to be interoperable and the technologies are mature.

For HLS you either have mature but Frankenstien solutions such as HLS+Access, HLS+PlayReady or HLS+Widevine, or you have a native solution such as HLS+Fairplay that is still immature and very difficult to deploy. HLS DRM is a mess.

#16Jan OzerSaid this on 10/27/2015 At 09:19 pmIn reply to #15Alex:

As always, thanks for weighing in. I get that HLS's native AES128 isn't DRM, but I'm hearing that FairPlay Streaming DRM is studio approved at this point. Certainly Netflix is using it for their content, though that's CENC based not HLS. I also understand that FairPlay Streaming is more secure than AES128, and like other DRMS, uses an external license server. Is that not true?

Not much out about FairPlay DRM, but at least one vendor, Castlabs is making it available:


As I understand it from discussions with Kaltura, they have partnered with Castlabs, in part, so Kaltura can access Fairplay from Castlabs.

Here's what Akamai says. "At Akamai we believe the benefits of having FPS available to protect content being distributed to the Apple ecosystem far outweigh the drawbacks of having to manage “another DRM” and is a significant step forward in the market. We will share our plans for how FPS will be supported throughout the Akamai ecosystem on Akamai Community in the weeks to come."


I'm not sure what to make of FPS, but I take it that you don't think it's a positive step? Any details you can share?