Jeroen Wijering Talks HLS, DASH, and the JW Player 6
LongTail Video recently announced the release of JW Player 6, a major upgrade to the company's popular free and low-cost video player. One key new feature is support for Apple HTTP Live Streaming (HLS), which enables desktop computers to play HLS streams, and for video publishers to support desktop and mobile viewers with one set of adaptive files. It also raises questions about the importance of the Dynamic Adaptive Streaming over HTTP (DASH) spec, which was supposed to deliver the same capability, but is not yet available in the marketplace.
We caught up with Jeroen Wijering, the creator of the JW Player, who was kind enough to answer questions about how the JW Player works and its potential impact on DASH.
SMM: Does the player provide native H.264 playback capability or does it rely on H.264 playback provided by other modules, like Internet Explorer or Safari, or the Flash Player?
JW: The player relies on the Adobe Flash plug-in to provide HLS support on desktops and on the HTML5
SMM: So, if a Firefox user doesn't have the Flash Player installed, they can't play HLS (or H.264 in general).
JW: That's correct. The browser (or Flash) has to provide support for H.264.
SMM: You've commented publicly that the installed base for Flash was about 99 percent. Was that an estimate or do you have actual stats? With all the buzz about HTML5, why do you think that number is so high?
JW: This is somewhat anecdotal. We see this on our own website, plus analytics providers like Statowl show aggregate breakdowns. The piece of the pie without Flash is almost exclusively mobile devices.
The Flash Player install base has always been great, and Flash's upgrade cycle is better than ever, with support for auto-updates across Win and Mac, and built-in support in Chrome. Flash is also still required for several key web use cases, one of which is streaming video. Hulu, BBC, HBO -- everything is still Flash, for reasons of quality and security, plus ecosystem support.
SMM: What's your sense of the progress the browser vendors are making vis-à-vis DASH support?
JW: As far as I know, no browser vendor has DASH support on its roadmap. Chrome's work on a Media Source API is the closest to it. This API allows publishers to build adaptive streaming using JavaScript. Chrome will do the H.264 decoding, but parsing of the manifests and bitrate selection are up to the publisher.
A similar API in Flash allowed JW Player to support HLS. When it arrives, we'll likely leverage the Chrome Media Source API for HLS support in HTML5 too, which means that HLS will play in Chrome without Flash installed.
SMM: How do you see DASH support coming into the market? I've heard through plug-ins, and then perhaps players like the Flash Player. Is this how you see it? Perhaps through players like yours? What's your sense of when general purpose publishers (as opposed to OTT and other closed system vendors) can actually start thinking about using DASH in HTML5?
JW: The only way right now to support DASH is indeed to build it using the Flash Plug-in. It can be easily done, just like JW Player supports HLS through the Flash plug-in today. I think DASH implementations in HTML5 are years out still.
I do also see publishers building DASH into apps, on the Android, iOS and Windows 8 platforms. This is only possible for large publishers though; those that have the dev resources to build and reach to distribute the app. Smaller pubs would be left out.
SMM: What's your sense of the pluses and minuses of DASH vs. HLS support? What are the critical features that DASH provides that HLS doesn't (if any)?
JW: The critical feature is DRM. Apple's HLS provides AES128-based encryption support, but not full-on DRM with licensing. DASH does so, supporting various protocols (like PlayReady). Luckily, in our segment of the market (SMB), DRM is not a requirement. Protection from hotlinking is much more important, and AES in HLS provides that.
There are several other features in DASH that HLS used to miss (like separate audio/video fragments or external closed captions), but recent versions of the HLS protocol added many of these in. In a sense, HLS is becoming more and more "DASHy". Maybe Apple is doing this to slowly work towards DASH compatibility? For now, HLS is the only way to stream to iOS devices though.
SMM: What's the status of HLS playback on the Android platform?
JW: Officially, Android supports HLS as of Honeycomb. In practice, we see a number of critical bugs in the current iterations of Android that break in-browser HLS playback:
- On Honeycomb, HLS playback crashes a tablet quite consistently. The version is of little concern though, since it has 2 percent market share and is shrinking.
- On Ice Cream Sandwich (26 percent share), HLS plays, but VOD streams cannot be seeked. The aspect ratio is also not detected, leading to deformed images. When going full-screen, a video is re-started from the beginning (again with no support for seeking).
- On Jelly Bean (3 percent share, but growing), the aspect ratio issue is fixed but the no-seek issue remains. Additionally, the new default browser (Chrome) does not understand HLS, leading to broken mimetype detection and an error message plus crash of the stream when taking it full-screen.
Taking into account that Gingerbread (54 percent share) does not support HLS, the only solution to streaming HLS on Android is building your own app.
SMM: What was so difficult about adding HLS support to your player? Why not sooner?
JW: Adding HLS meant we had to do the unpacking (de-muxing) of the TS streams ourselves, so we had to learn the nitty-gritty details of video containers first. This included all the small differences between providers. Wowza sets a certain byte this way, Akamai that way, and Sorenson yet in another way. We had to do a lot of testing and reverse engineering to get our HLS support compatible with all major solutions and performing well on old devices.
In addition to that, publishers were (and are) quite content with RTMP. The protocol works quite well, so why change? Only in this year, we've really seen an uptake in demand for HTTP streaming. The main requirement from publishers for HTTP streaming is always iOS support, which is why we chose HLS over Adobe's HDS.
SMM: Would you expect that Adobe will add HLS playback to the Flash Player sometime soon? If not, why not?
JW: I don't think Adobe will add this to the Flash Player. HLS is a format controlled by Apple, directly competing with HDS, Adobe's own format. With HDS, Adobe is in control of the server, protocol, and client, so it can offer unique functionalities, such as DRM or multicasting. With HLS, the Flash player is "just another" client and the Adobe Media Server is "just another" HLS compatible server.
Related Articles
Customers can now bring their videos and ads to the biggest screen in the house using a Chromecast-enabled television.
22 Jul 2014
Guiding attendees from the backend setup to the viewer experience, two experts offered HLS specifics at Streaming Media West.
28 Jan 2014
Rebranding to take the name of its popular product, JW Player outlines its areas for future development.
25 Oct 2013
Reach viewers no matter where they are. Check out these strategies for reaching the most devices with the smallest number of files.
05 Mar 2013
Delivering a more modern look and ad network support, LongTail Video keeps the popular player current.
16 Nov 2012
The JW Player creator talks through HTML5 basics, explaining what it is and why it's useful.
08 Feb 2012
Companies and Suppliers Mentioned