Wowza Whiteboard: Low-Latency Streaming Basics

In this whiteboard session, director of product marketing James Jackson and Wowza cofounder and CEO Dave Stubenvoll discuss the factors involved in low-latency streaming. Learn about how Wowza meets the challenges of delivering low-latency streaming at scale.

Low latency basics: Quality of service, audience size, geographic scope, and more

Low latency, WebRTC, and traffic optimization

Streaming trends and low latency: Mobile streaming, social media, and virtual reality

Wowza technology for low-latency, high-volume streaming


Part 1

James Jackson: Thank you for joining us. My name is James Jackson. I'm the director of product marketing here at Wowza Media Systems.

Dave Stubenvoll: And I'm Dave Stubenvoll. I'm the CEO and one of the cofounders.

JJ: Today we're going to take a little bit of time to talk about low latency, what we've got going on here, and what's actually driving it in the industry. Thanks again, Dave, for joining me. I really appreciate it. We talk about low latency in the world in terms of the ability to get things from one place to another very quickly. We talk about latency which is essentially just, when you ask for something, the perceived time until you actually get it.

DS: Yep.

JJ: Can you talk a little bit about what we've been doing in the areas of low latency in terms of actually helping people to deliver and drive those low-latent-type solutions and experiences?

DS: Sure—low latency has been a part of the Wowza story forever. RTMP is a relatively low-latency protocol and it had its foundings in chat as well as video delivery. There's the real-time messaging protocol, the ability to send things back and forth. As the world is moving more towards HTTP for mass delivery, latency has really popped up. You went from a high-latency RTMP connection of being a couple of seconds to a low-latency HLS implementation being 10, 15 seconds, and that's an order of magnitude more. Low latency is getting to be a bigger and bigger thing. The need for it is certainly increasing.

JJ: Very much. When we look at what's driving that … when you're talking about your user experience, obviously you've got to have good content, but at the same time, users have lots of options, and so in order to keep your viewer base, reduce your customer turnover, you've got to be able to deliver those low-latent-type experiences.

DS: Yep. Yeah, there's certain use cases that absolutely require low latency. Doing an auction with 30 seconds of latency: not such a good idea, right? For real-time bidding and things like that. At the same time, though, the quality of the experience is often negatively impacted by low-latency streaming and the HLS concept. You have this cost/benefit that you constantly have to weigh. When you look at things like user-generated video, we think the best way to handle that is when you have a small number of viewers, you want to use a low-latency capability. Then, as the number of users grows, in order to handle that increased demand, in order to handle all that volume, you may want to increase the latency in order to make sure that you get that quality of service across a large base.

There's so many aspects that affect latency. One is the quality of service. Another is the size of the audience. Another is the geographic scope. The truth is that if you're streaming from Philadelphia to Philadelphia and to someone in China, well, the person in China is going to be a little bit behind.

JJ: Uh-huh. That's really great you bring that up. I want to talk a little bit more about some of the things, in terms of the architectural choices that we've made here across the product portfolio. You talked a little bit about that in terms of … what latency means across the global audience. We talked a little bit about just the fact that we do deliver on a global basis … whether it's hybrid or on premises or however you're going to deploy Wowza.

DS: Yep.

JJ: But you do have the ability to actually serve that global market. Can you talk a little bit more about that?

DS: Yeah, again, let's kind of go back a little bit. Wowza's streaming engine was built for live video, on-demand video, and for chat, right?

Chat requires extreme low latency; otherwise you keep stepping each other over on conversations. We've been built from the beginning to deal with chat. Then, when you look at the workflow of something, of any kind of application, it is that "ingest, manage, and deliver" component. With Wowza GoCoder we actually use a proprietary low-latency lossless protocol on the ingest side, called WOWZ. We're guaranteeing low latency at that kind of "one-to-one" in this aspect of it. Then, when you go to the delivery aspect, you can look at the use case and say, "What is the right thing to do here? Am I delivering to a global audience, in-region audience, and do I want to increase QOS by having increased latency, or am I willing to deal a little bit with lower QOS and have lower latency?"

JJ: OK. It sounds like from the outset it was really designed to be able to deal with these … low-latency types of scenarios in terms of those type of workflows, those types of use cases. The question is, if you want to do this, obviously we continue to evolve and continue to adapt, expand more capabilities, but with a platform that's designed from the outset to be able to onboard-adapt those capabilities quickly, in addition to being designed from the outset for low-latency scenarios, what's the likelihood that you'd be able to do that with another platform that was not designed from the outset to do that?

DS: It's super hard. So many of the products built today are built for HTTP streaming, which is inherently high latency. You've got various bits in the workflow, from the ingest, and then what is the server doing? How much time does it take the server to efficiently package and deliver the bits that are coming in? That's where our legacy with video chat becomes super important, because we architected the core of the server to help deal with video chat, which is inherently low latency. That part combined with our ability to do both low latency and high latency allows us to deliver the optimal experience for the customer.

For example, you may have a video chat between you and I in different locations, and our communication needs to be low latency. But that may be part of a worldwide event, right? We may want our chat to go out to a global audience, so we could be communicating at very low latency, and then we're delivering it at a super-high-scale way that might have 20 seconds of latency. And that's OK, right? Because we need to communicate. They're viewing. It's just a different thing.

Part 2

JJ: Can you talk a little about our implementation of WebRTC in terms of actually being able to deliver low latency but also being able to optimize the traffic?

DS: Yeah. There actually is a couple of unique things about WebRTC that makes it a little bit of a challenge to deliver. One is WebRTC is built into a number of browsers, and the problem is, or the opportunity as far as we're concerned, is that they are not consistent on the codecs that they're using. It could be VP8, could be H264, and so each browser may need a different codec in order to deliver it.

In that case, if you have a couple of people on Chrome that are communicating in VP8, for us to deliver that to the audience, we have to transcode that into H.264 for delivery to, whether it's a JW Player or a Wowza player or native Mozilla as an example, and so we have to break up that workflow and break up the way things are done in order to provide the right type of stream for every consumer. Then, on the inside of Wowza, people think of WebRTC as a peer-to-peer protocol, which it is, but it doesn't have to be. And so in Wowza we can take WebRTC, along with RTMP or an MPEG-TS, into Wowza and then deliver it out in all those ways: RTC, RTMP, HLS, et cetera.

We manage and optimize the connection of every type in Wowza, and that ability to handle so many different types of video, so many different types of protocol, is truly a key strength of Wowza because from day one we did that in an incredibly efficient manner and have developed ways to manage those connections and really optimize how the server is being used in managing each of those connections.

Part 3

JJ: One of the big things we talk about in terms of … trends in the world … we talk about things like mobile or social, and with social definitely, a lot of user-defined content, user-generated contented, user-submitted content. In the day and age of global news, we want to know what's happening right now. Even more than that, we start talking about things like virtual reality, or VR experience ….

Once again we talk about … that expectation for things to happen right now. A lot of those things we've actually put in place to enable these types of mobile, social, global VR-type experiences. Can you talk a little bit about some of the other things that we've put in place to help along the way with those things?

DS: Sure. Let's go back a little bit and talk about that real-time expectation, because this is an area that's really fascinating. In the days of broadcast, right, when we watched CBS and all that stuff, watched a football game, that wasn't real time. There's significant broadcast delay; we just didn't notice it because we weren't sitting in a stadium. Mobile puts you in the stadium and for the first time you're saying, "Oh my goodness. This isn't real time." Everyone thinks, when I watch at home, it's real time. No, it isn't. It really isn't. That connection between mobile and real time has been strong and weird … in that it changes the expectation and messes with your mind.

The social aspect of it is also cool because we see a number of use cases, like Real Madrid. They're bringing that second-screen content into the stadium, right? Yes, I need it to be real time or as close as possible—I don't want to wait 30 seconds and hear "Goal!" and, like, it's over. I don't care. These things working in concert are driving incredibly different viewpoints of what real time is, and what it's good for. As you bring that into VR, things get also weird. You can think of what's going to happen in the sports scene when we also have VR, when you can look around from some camera that's close to the field. It's going to be interesting. We'll see how that goes.

Wowza's capability in VR is very clear. VR really drives … 4K because you want the maximum amount of pixels coming in, so that when you're looking at your little slice it looks decent. This is moving pretty rapidly from 4Kto 8K to 12 to 16. Really, it's a frame size. You're looking at a slice of it. That's really getting pushed. That actually maximizes traffic overhead. We're delivering a lot more than the viewer's seeing at any particular time.

That's where we may have opportunities, again, in large-scale distributions. How do you deliver these VR experiences to places that don't have awesome bandwidth? Perhaps we can do things server-side to help give your control that slice server-side, like a pan-tilt-zoom capability.

And all this, people really want to deliver via HLS. HLS is very efficient, in that you can leverage large amounts of caching infrastructure that's in place. Wowza, given our legacy and all the things that we've done, and also the fact that Charlie Good, the other cofounder of Wowza, he is the developer's developer. He thinks of "what do I need out of this to make use out of it?" from a developer perspective. We give you the tools to really reduce that latency. At this point, there's no magic bullet. We're not going to give you 0.1-second latency with HLS. That's just a physical impossibility, pretty much. But we're giving you all the tools to really reduce that latency—to make it the absolute minimum to fit your use case, to fit the quality of service.

Again, as you crank these things down, you run the risk of running out of buffer. You run the risk of few things. The ability to recover becomes even more important, right? If there is a broken connection, if there is a starved buffer, how do I get that next chunk of video out there in a timely fashion so that the user experience is not compromised?

Part 4

DS: I think the best way to describe Wowza, and what points to our unique advantage, is we were designed for multiple types of streaming. We were designed for high scale as well as low latency. Quite honestly, if you were to do a completely dedicated low-latency system, would you make some different design choice? Yeah, sure.

Practical low latency—if you want to get low latency at scale—that's when I think we're at the best point. It's that mixture of different types of streaming that Wowza very uniquely excels at. Would I recommend using Wowza to remotely control an operation? You want super-specialized very low latency for that. I'd prefer you use something designed specifically for that. It is the real use case of folks that are building streaming applications today that need that mixture of low latency and high volume, that we're uniquely able to provide.

JJ: OK, well, thanks a lot, Dave. I really appreciate it, and once again, for more information please visit