Guest Blog: Bitmovin Says 80% of Our Streams are DASH

Editor's Note: bitmovin is an Austrian company who built their business around the DASH format, including its cloud encoding service bitcodin (reviewed here), and its bitdash player. After reading the blog post DASH: The Most Popular Format (almost) No One is Using, which reported that only about 1% of streams played by the JW Player were in the DASH format, bitmovin president Stefan Lederer requested the ability to respond. Here is his guest post, and the opinions expressed below are all Stefan's. 

Thanks for the opportunity to respond to your post about DASH usage by JW Player licensees. First, as you point out, JW's implementation has only been on the market for a few months. Twelve months from now, you'll probably see an entirely different result among JW users.  

In addition, JW has been an HLS - first player, rather than a DASH-first player. Players that prioritize the DASH format obviously will have a much higher percentage of users and streams utilizing DASH. While our numbers are much smaller than JW’s, we have several large users, including genflix.co.idflimmit.comkronehit.tvsonostream.tv, who have been using DASH for the last 12 months. Of our total user base, over 80% percent of streams are DASH.

While JW is undoubtedly the market leader, they are just dipping their toes in the DASH-space, so their player isn’t as well featured from a DASH-perspective as some others. For example our bitdash player (http://www.dash-player.com), supports multiple DRM system, captions for live and VOD, multi-caption and multi-audio, live streaming with timeshift/DVR, Firefox, HEVC for Microsoft Edge, all features not available in the JW Player for DASH (editor's note: I have not verified these claims). 

On JW's assertion that HLS will lead the MSE-charge, we simply disagree, for the simple reason: having a JavaScript HLS player could help here, but in this case one would have to do the transmultiplexing from MPEG2-TS to MP4/IBMFF in JavaScript on the client, which is performance-intensive and thus battery-consuming, especially when it comes to higher bitrates.

On the bitmovin side, we see most of our customers going for DASH + HLS combined. This is the best way to serve all types of devices in the best way, i.e. using DASH for HTML5 MSE-enabled browsers - which are already the majority - and in our Flash fallback for older browsers, and HLS on iOS devices which do not support anything else. Based on this, the viewers of our customers typically consume 80-90 % MPEG-DASH and 10-20 % HLS streams, depending on their country.

When it comes to studio/Hollywood/premium content with DRM protection, one really has to use MPEG-DASH today for most platforms - using MPEG-CENC with Widevine Modular and Playready, etc. using the HTML5 EME - and HLS with FairPlay for iOS/Safari (as it is not supported anywhere else). HLS alone is not suitable to reach the majority of platforms with DRM protected content, simply because it's not compatible to the HTML5 EME and MPEG-CENC ecosystem. 


Comments (1)

John Luther
Said this on 11-23-2015 At 04:47 pm
Thanks for your response, Stefan. I agree with Jan that it’s good to have more data on this topic.
I hope people didn’t interpret my SMW presentation as JW being “against” MPEG-DASH or doubting its momentum. Not so! Jan simply asked me for usage data and I provided it. JW has been a member of the DASH-IF for years and we are VERY eager for DASH to become the one truly standard format for ABR streaming. (As Stefan noted, JW Player supports DASH today, and we will roll it out in JW Platform next year.)
JW will continue to support HLS--using HTML5 as well as Flash--because many of our customers demand it. They have large catalogs of legacy content in HLS, investments in HLS encoding/packaging/advertising infrastructure [1], many browsers still don’t support Media Source Extensions, and of course must support ubiquitous Apple devices, which only play HLS [2]. I agree with Stefan that as DASH adoption grows in 2016, the percentage of DASH traffic in the JW Player network will grow, too.
Anyway, Stefan’s 80% number makes sense, because DASH has been the primary focus for bitmovin since they started. After all, as I joked during the session, their flagship product (the bitdash player) contains the word “dash.” :-)
However, I disagree with his one "simple reason," why HLS won’t be a boon for HTML5+MSE (i.e., that it requires transmuxing from MPEG2-TS to ISOBMFF in JavaScript). JavaScript transmuxing is certainly not ideal, but the same transmuxing requirement has always existed in Flash HLS implementations (although to FLV, not ISO), and the performance of those implementations has obviously not hindered the adoption of HLS in browsers.
The good news, IMO, is that implementations will be even MORE performant in the super-fast JS engines in modern browsers. The Peer5 guys posted an analysis of this the other day at http://blog.peer5.com/http-live-streaming-in-javas.... (By the way, JS “underperformance” has been a criticism of MSE since the spec was proposed at FOMS 2011. Barring some underpowered CE devices, that’s been proven false.)
[1] They can easily repackage their H.264/AAC streams into DASH--which is a Good Thing for DASH adoption.
[2] Yes, it is possible to play DASH on Apple devices, but it requires you to create a custom app. 

Thanks for your response, Stefan. I agree with Jan that it's good to have more data on this topic.

I hope people didn't interpret my SMW presentation as JW being "against" MPEG-DASH or doubting its momentum. Not so! Jan simply asked me for usage data and I provided it. JW has been a member of the DASH-IF for years and we are VERY eager for DASH to become the one truly standard format for ABR streaming. (As Stefan noted, JW Player supports DASH today, and we will roll it out in JW Platform next year.)

Anyway, Stefan's 80% number makes sense, because DASH has been the primary focus for bitmovin since they started. After all, as I joked during the session, their flagship product (the bitdash player) contains the word "dash." :-)

However, I disagree with his one "simple reason," why HLS won't be a boon for HTML5+MSE (i.e., that it requires transmuxing from MPEG2-TS to ISOBMFF in JavaScript). JavaScript transmuxing is certainly not ideal, but the same transmuxing requirement has always existed in Flash HLS implementations (although to FLV, not ISO), and the performance of those implementations has obviously not hindered the adoption of HLS in browsers.

The good news, IMO, is that implementations will be even MORE performant than Flash in the super-fast JavaScript engines in modern browsers. The Peer5 guys posted an analysis of this the other day at http://blog.peer5.com/http-live-streaming-in-javas....

JW will continue to support HLS (using HTML5 as well as Flash) because many of our customers demand it. They have large catalogs of legacy content in HLS, investments in HLS encoding/packaging/advertising infrastructure [1], a significant number of browsers in use still don't support MSE, and of course they must support ubiquitous Apple devices, which only play HLS [2]. I agree with Stefan that as DASH adoption grows in 2016, the percentage of DASH traffic in the JW Player network will grow, too.

[1] They can repackage their H.264/AAC streams into ISO for DASH, which is a Good Thing for DASH adoption.

[2] Yes, it is possible to play DASH on Apple devices, but it requires you to create a custom app.

Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
Website:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: