Video: Pros and Cons of HLS for Live Streaming Playback

Learn more about emerging codecs at Streaming Media's next event.

Watch Robert Reinhardt's complete presentation from Streaming Media East 2019, T102. How to Identify Real-World Playback Options, in the Streaming Media Conference Video Portal.

Read the complete transcript of this clip:

Robert Reinhardt: HLS, and I'll put DASH out there as well, because it's part of that same model, and CMAF is changing this landscape. I don't have CMAF as a dedicated slide in this session, but CMAF is gonna play a huge hand in making HLS and DASH a much more universal format or delivery mechanism.

I hope everyone in the room knows what CMAF is. CMAF is one of the main reasons I used a tool like Wowza. Wowza took care of my CMAF needs before CMAF was even a luxury. So, the idea of having just one encode for each rendition that you wanna serve and not having to have different containers for all your video formats is what CMAF is all about. You still need different manifests, but your source video and audio can stay in the same container formats.

Of course, the biggest thing that we hear about HLS and its problems are the high latency that you usually have. And that's usually just a problem with default settings. It's just like folks who buy a Linksys router and don't change the router password from "admin" and then they complain that they've been hacked.

There are so many things that you can do with HLS and DASH to optimize it, to get it much lower than the default. Of course, vendors here are gonna advertise that they're much lower than 10 to 30 seconds.

I'm not saying that you shouldn't look at other vendors when it comes to their low-latency HLS variants because I would say every one that I've looked at has a unique approach to it, and it's interesting to see how they're trying to solve those low latency times.

I tend to do a lot of Wowza for my clients, so I'm just going to show you a quick for-instance. So, I'm in Wowza Streaming Engine right now, and if you are a Wowza Streaming Engine user, or you've utilized it before, and again, there's similar settings in other technology; just go to under your Cupertino Streaming Packetizer. The default chunk duration in Wowza is 10 seconds! That's why your latency is so high! You can take that down as low as your keyframe interval on your encode is going to support.

So, if you have a two-second keyframe interval in your live stream encoder or your H.264 encoder, set that to two seconds. There's no reason why you shouldn't. Now, I shouldn't say there's no reason. I've had a medical client who has a very low-bitrate video display screen of a monitoring device that they use in hospitals, and they get some one-second latency with HLS because they've got such a short keyframe interval. Wowza will now actually create keyframes from previous P frames if you need to. You can do things like that so you don't even have to have your encoder send it out, especially if it's fairly static video footage.

Just know there are simple ways to reduce latency. It's a no-brainer for me to take someone.. If I have a client come to me and say, "Hey, these HLS latencies are out of control. How do I get this down?" We're just going to change one setting, and automatically we are now, this particular one, you look at the playlist chunk count. So, how many chunks are you listing on your playlist? The default for Wowza is three. I increased this one to four. So, we've got a little bit more of a buffer in the manifest, and by "buffer" I just mean playout time to switch between adaptive bit rates. But that's an eight-second latency on average. It could grow to 10 or 12 seconds, but that's cut more than half from the default 30, right? You can do math. 10 times three is 30, that's 30 seconds. Sorry, two times three, I'm looking at the wrong number, the max chunk count. That's how much the server will store in reference to a playlist generation, but your playlist is going to have basically eight seconds.

You can try any settings you want with this. I wouldn't recommend a manifest with just one chunk reference in it because you're going to be refreshing that manifest a lot. There's going to be a lot of overhead with the calls to update that manifest. So, I wouldn't recommend less than three chunks in a playlist, but I have clients that have taken it down to two and for the load that they have on their servers, it hasn't been too bad or the clients that they have looking at it.

But those are really easy things to do. You don't need someone like me to help you with that. You just need to know where to go for those kind of settings. And again, those are all, any good media server that's doing its job is going to be able to do that for you. Just specify that chunk count. What's nice about Wowza is that that's a target, so even if your chunks aren't able to be carved out of two seconds, it's just gonna find the closest match to that. So, if I had a three-second keyframe interval, it's going to make three-second chunks. It just lets it know what the neighborhood is for chunks.

We, of course, are going to be supporting new codecs, or the codecs are already supported beyond H.264. We've got HEVC supported and HLS on both iOS devices that have been around for a couple years. DASH, as well, they're fairly codec-agnostic containers. By definition, it's really more about where you have those codecs installed. And, again, the drawbacks, out of the box, they're going to be prone to high latency and they are generally designed for one-to-many broadcasts.

It doesn't matter how low you get that latency, you're not likely going to be using HLS or DASH or any kind of HTTP chunked packetized stream for a real-time conference. I'm not going to start trying to talk to my buddy with an HLS stream. If I was broadcasting this session live, it's perfect. And, of course, it's TCP-only. That's just the nature of HTTP, right? So, TCP will, of course, have a different kind of networking negotiation than something like WebRTC and UDP.