The problem with Apple HLS is that it uses MPEG TS container, which is not supported natively by the browsers (except Safari). So, any implementation of HLS in Chrome/Firefox should do the job of extracting video/audio from container using JavaScript (or Flash, like FlashHLS player does).
A more standard-friendly solution is MPEG DASH, which is similar to HLS, but can use MP4 container supported natively by the browsers (as a part of HTML5 video standard)
The MPEG-TS container (from 1995!) is also a lot less efficient than the more modern MP4 container. Overhead can range from 5% to 30% with bad muxing settings.
But a problem with DASH is that the MPEG LA is attempting to form a patent pool, presumably with the goal of charging a patent license fee. The MPEG LA's Larry Horn says, "Market adoption of DASH technology standards has increased to the point where the market would benefit from the availability of a convenient nondiscriminatory, nonexclusive worldwide one-stop patent pool license".
Another reason HLS is so widely used is that the App Store Guidelines require it for video streaming longer than 10 minutes:
Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 192 kbps or lower HTTP Live stream
It's also the only format that works with Apple TV via AirPlay.
If you're already deploying HLS to target iOS and Apple TV (natively as well as in Safari), and HLS is already supported in other devices like Android, desktop browsers via Flash, and now JavaScript, then it seems like the path of least resistance.
Great article. I think we can actually talk about flash being replaced now that we have a real solution for HTML5 live streaming. Flash was never going to go away until there was something that could handle the DRM across all browsers.
I've worked a lot with Ooyala's live streams and was just looking at moving a client over to their HTML5 offering. They claim to offer it in all browsers but that is probably with a flash fallback, they haven't open sourced their JS (or at least I can't see it on their GitHub page).
We also use StreamUK on a lot of sites (but I've never used it directly) and from what I have heard they have great support for HLS. They have no GitHub presence so not quite sure if they're using the same libs the article mentioned or something proprietary.
Obviously DRM would still be an issue unless the browser natively supports EME.
I agree we should do tests on low-cost machines as well.
But at least on my machine the js libraries performed better than the Flash ones.
So moving to flash-less should improve performance.
> Obviously DRM would still be an issue unless the browser natively supports EME.
Actually, with HLS, DRM is an issue on browsers since HLS is not designed to work with EME spec.
By the way, some open source players like https://github.com/canalplus/rx-player implements EME spec to work with DRM, Smooth Streaming Format or MPEG DASH format, that are compatible with the common encryption model.
>but Chrome, Firefox, and IE still don’t use this technology on their desktop versions
Actually, since version 11, IE supports HLS. [0]. When Apple streamed their last event, they mentioned on the video page that IE11 is supported. That's when I found out about it.
> Dash basically takes all of the good stuff from HLS and gets rid of the bad pieces.
Not sure I would use that sentence to describe a standard that replaces the extended M3U file format (it really whips the llama's ass) with yet another complex XML document.
MPEG-DASH is less of a video standard itself and more of a set of guidelines for new set of adaptive-bitrate streaming standards like DASH-AVC/264.
This is a great article! Been thinking of writing one myself for a while now. I have a project (https://github.com/johnBartos/RadioFreeTwitch) which siphons Twitch's HLS streams and extracts the audio-only portion from its manifest file. Up until recently, it's been near impossible to get a reliable, easy to use solution for non-flash HLS. So I shelved the project until the technology matured. Just last night I decided to take a crack at a flashless solution and was blown away by how easy it was - I use Flowplayer, and hlshjs (https://github.com/flowplayer/flowplayer-hlsjs) was just plug-and-play for me.
A better solution would be to deploy a media server that can provide multiple stream formats. For example, Microsoft IIS Media Services [1] supports Microsoft's Smooth Streaming, HLS and MPEG-DASH without having to re-encode video for each format.
With such a solution, nearly every client out there can use a natively supported stream format without overhead. Also, Microsoft has a decent cloud offering with Windows Azure Media Services [2] that fixes all of this for you, including optional DRM.
I think at the end of the day the better solution for most people would be to use something like Brightcove, The Platform, Ooyala, Adobe, paid Vimeo, or even Youtube.
Unless you're Netflix, I wouldn't bother with this stuff yourself. Even then, a lot of (A)VOD sites 'outsource' this stuff to Brightcove or The Platform.
I think BitTorrent was only using Flash because it offered portability across browsers and OSes. I wouldn't be too surprised to see them switch to using html5 instead.
I've talked with a few guys from jw and videojs They've said to reach sub 2s using hls.
They did that with <1s chunks and progressive streaming of a single chunk.
I have an HLS live stream with less than 1 second of latency. If you have a keyframe interval around 5 frames, the player can start playing when it receives 15 frames.
A more standard-friendly solution is MPEG DASH, which is similar to HLS, but can use MP4 container supported natively by the browsers (as a part of HTML5 video standard)