What YOU Need to Know About HLS: Pros and Cons

January 15th, 2016 by Chris Allen

R5P_HLS blog post

HLS, or HTTP Live Streaming is a video streaming format first introduced by Apple in May, 2009. It’s a format that breaks streams into small file-based segments made available for download over HTTP. It now is a widely supported format for viewing streams in almost real time. I say almost only because the protocol, by its very nature, introduces a lot of latency.

We’ve been getting a lot of questions and inbound interest from our customers about HLS. What are the advantages of using it? What are the disadvantages? How does HLS compare to WebRTC? Will Apple approve apps that don’t use HLS for streaming? This post is an attempt to address some of these questions.


There are many reasons you would want to use HLS for your live streams, and this is why we recently added the support to Red5 Pro.


First of all, HLS is widely supported. Although originally conceived by Apple for Quicktime, iOS and the Safari browser, it’s now implemented on virtually every browser out there. As you can see, the leading browsers support it. Now of course most of them support a comparable standard called MPEG DASH as well, but since Apple Safari and iOS devices don’t support it, we think HLS is currently a better choice.

Adaptive Bitrates

Another huge advantage of using HLS is that it allows for clients to choose from a variety of quality streams depending on the available bandwidth.



So if it does all that, why wouldn’t I want to use HLS for my live streaming app?

Terrible Latency

It turns out that while HTTP Live Streaming was designed to deal efficiently with multiple quality streams, it wasn’t built for delivering video quickly. Practically speaking, HLS introduces at least 20 seconds of latency (often more!) in your streams.

Here’s why; HLS requires three segments in queue before it will allow playback, and the segments are divided by the keyframes in the video. The only way to create a super low latency stream (let’s say under one second) with HLS is to encode the video going out with a keyframe happening every 250 ms. The HLS playlist moving-window would be four items long with a segment duration of quarter of a second.  This would of course create high bandwidth video, add to the number of HTTP calls happening (at least four per second), and put additional load on the server.

The whole point of keyframes in video protocols like h.264 is to reduce the number of times you need to send a full frame of image data. With the above scenario, you might as well be sending the frames as a series of JPEG images in sequence. There’s a lot more to this, like the fact that media has to be packaged in 188 byte packets which creates added overhead when you do it too much, but hopefully now you’ve got the gist of it: HLS is a poor choice when it comes to low latency video streaming.

No Publishing

HLS is a subscriber-only protocol. Unlike WebRTC, which has a spec for publishing from a browser, HTTP Live Streaming only supports playing streams. If you want to publish a live video stream for a device, you simply have to look for other technology to do this. Luckily with Red5 Pro, we have alternative SDKs for mobile that allow you to create publishing apps that utilize RTP; you can then relay those streams over HLS for folks to view these streams right in their browsers. You can check out our HLS player example using video.js on GitHub. We are also in development on full WebRTC support with Red5 Pro that will include a JavaScript SDK. This implementation will feature out-of-the-box tools like a WebRTC Publisher and a player that supports WebRTC, HLS and RTMP (as a fallback), so stay tuned for that update as well.

Apple iOS HLS App Rules

Another question that comes up when our customers get ready to submit their iOS apps to the App Store is: will Apple reject my app if it’s not using HLS? As many of you know, our SDK uses RTP streaming for iOS, and Apple has some strange requirements that all apps must use HLS for streaming. That’s not quite true however. Apple states the following in their App Store Submission Guidelines:

  • “9.3 Audio streaming content over a cellular network may not use more than 5MB over 5 minutes.”

  • “9.4 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.”

What we’ve also found is that if the app is a communication app–meaning that you have some form of two-way communication like Periscope has with live chats–then they tend to group the app in a different category. Apple also considers video calling apps like Skype to be in a different category, and the live streaming restrictions of having to use HLS don’t apply. The other good news is that as the popularity of apps like Periscope and Meerkat continues, Apple is getting used to the idea of live real-time streaming apps, and is gradually becoming more and more flexible with the restrictions.

So with that in mind, because of HLS’s high latency, Apple will approve apps that use other protocols if there’s a need for real-time communication. We simply recommend making a note of why you can’t use HLS when you submit your app.


As you can see, the ubiquitous support of HLS on a variety of browsers, mobile phones, and operating systems makes it a great choice for distributing your streams to the most amount of viewers. However, since it’s a rather slow protocol, if you are building any kind of app that relies on near real-time communication, you should look at other options. Finally, while Apple’s rules do seem quite rigid when it comes to their iOS streaming requirements, they are actually flexible when the need for something else is justified. What are you thoughts; are you currently using HLS in your apps? Have you submitted a non-HLS based streaming app to Apple’s app store? How did that go? Let us know in the comments.


, ,

He’s BAAAaaaack!

November 10th, 2015 by Paul Gregoire

Screen Shot 2015-11-10 at 4.11.15 PM

Why on earth would anyone choose to rejoin a company where they previously worked? In retrospect, the answer seems quite simple, though of course, taking the plunge is always a daunting task. I assume the statistics do not favor a return to a previous workplace after an extended hiatus, but I could certainly provide a plethora of reasons why I returned to Infrared5 when presented with the opportunity to do so. For me, and in any and all endeavors, the work has to be both intellectually stimulating and challenging. Software development can often be repetitive and monotonous, but fortunately that never was (and still isn’t) the case at Infrared5. Of near equal importance are the workmates that surround me; without a high quality, collaborative and generally pleasant team, even the most stimulating work can lose its shine.

So to that end, here is a short checklist I used when making the decision:

1. Do I enjoy my interactions with my teammates? Check!

2. Do I have respect for them and their abilities? Check!

3. Lastly, Infrared5 wanted to pay me to write code all day and work on Red5! Well that’s a no brainer–count me in!

While working for another company, I had joined the Red5 Pro beta just after it was announced on Twitter. A “Pro” version or Red5 was something Dominick and I had chatted about on a few occasions back in the day–there may or may not have been beer involved. Despite the casual conversations, we both thought there could be immense long-term value in providing the Red5 community with what they were always asking for and talking about on the users list and social media. Providing the ability to stream from any device to any device has always interested me. Alas, I had the desire to turn intrigue into application by helping to create a software which could do just this. Red5 Pro offers Flash streaming, HLS streaming, and RTSP streaming; these technologies are still in-demand and are not interoperable on existing platforms, except on Red5 Pro.

In the near future, the public can expect some major disruption on the streaming media front from Red5 Pro. It should come as no surprise to the community that we’re adding the new hotness of technology, WebRTC, to our existing stack. If this addition isn’t “For the Win,” I don’t know what is. I have no qualms about saying that the suite of tools which comprise Red5 Pro will help shape the future of the streaming market–and I couldn’t be happier with my decision to return.



, , , ,