Low-Latency Streaming Checklist
Learn more about streaming latency at Streaming Media East.
See complete videos and other highlights from Streaming Media West Connect on Streaming Media's YouTube channel.
Read the complete transcript of this video:
Speaker 1: (00:07)
Robert Reinhardt: Building for a low latency--what does that mean, exactly? This is a five-step checklist that I put together just for this webinar.
1. How long do you need that latency? When I do discovery, that's one of the first things I want to ask. For that that scoring session I mentioned before, the stakeholders were okay with a two- to three-second latency. When it comes to cattle auctions, in the past I worked with a wine auction house too. That was all Flash legacy. They need sub-one second latency for an auction. And we could actually pull that off with RTMP. You knew you had to know how to script your Flash player to have a super-low buffer and have the pipelines all working the way they needed to over RTMP. More often than not, they were very pleased with the results of the latency.
2. Knowing the size of your audience. Again, if you have to build a map, if you have to build for large audiences, WebRTC is going to be much more difficult than you would have been able to do with latency factors that were higher. Mainly, because you can't just slap Amazon CloudFront in front of WebRTC apps and make it work. Those are all HTTP caching mechanisms and WebRTC is not using HTTP. It's not even using TCP if you're using the lowest-latency UDP transmission path.
3. How often are you going to be broadcasting? I have lots of clients--that athletic competition I just referenced before, it only had to run for a weekend. So, we could do a whole lot in the cloud that was very temporary, and it was going to be torn down as soon as we were done with it. Again, that plays into licensing. If you're going with cloud platforms with WebRTC, if you're paying by the minute,, or by bandwidth, whatever their metric is for billing you, that's going to be an important consideration.
4. What are your intended viewing targets? Where do you want people to watch it? Do you want it to work on the phone? Do you want it to work on the browser on the desktop, or do you have the budget to put together native smartphone applications? You're always gonna have the most control when you're not working in the browser for an application, because you're stuck with what the browser has made available to you.
Stereo decoding's a great example. Last I checked--and again, this stuff changes every day--Firefox is the only browser that can decode stereo audio channels and WebRTC. And that was a bit of a problem for that musical scoring client that I mentioned earlier, because high-quality audio that's running stereo is super-important. If we're driving people to an experience that's browser-based, then we're back to this equation of "best experience" with "our only experience with Firefox." And I have another client that has basically tailored all of their WebRTC offering to Chrome. So if you go there without using Chrome, you're going to get a big warning saying, "Hey, come back, use Chrome and everything will go as expected." Um, so that's.
5. What resources do you want to maintain? This is a conversation that I find stakeholders at companies that come to me want to have. And this usually happens. I wrote a column about this for Streaming Media, where I talk about the single stakeholder mentality. I have had more than a few projects where there's a CEO of a smaller company, or maybe even came from a bigger company, made a lot of money in some organization that they started with some product. And now they're switching gears. They want to test the waters with something that might be real time, and involving WebRTC or whatever tech stack they need. And I find that those folks don't necessarily always understand the implication of what it means to run your own WebRTC stack, what it means to go down this path of building things. They might be new to software development, and they don't have the proper project management resources. This is all-important because, when you're trying to put budgets together that go along with a roadmap, I have to deal with the stakeholders that want to own that architecture. They don't want to use a cloud platform and pay by the minute because somehow that's perceived as being more expensive.
How am I going to offer free? If I want to have a free version, like Zoom does, you can use it for 45 minutes or 40 minutes, and then it cuts you off. They want you to pay after that. And so they had this sense that their own infrastructure isn't going to cost them anything.
That's something you got to talk about and dismiss right away. Because running your own architecture 24/7 and having support staff for that is not for the faint of heart. And you need budget to support that. That's where cloud offerings can help--Millicast, who's here as a sponsor; Frozen Mountain with LiveSwitch. There's lots of offerings out there when it comes to cloud platforms and they all should be on the table.
Related Articles
Award-winning Limelight Realtime Streaming now offers increased global scalability and bi-directional data sharing, enabling new, innovative online video business models
19 Nov 2020
Advances in chipsets allow for more processing at the edge, so we're going to see latency times drop even further in the near future.
18 Nov 2020
VideoRx CTO Robert Reinhardt explains what low-latency streaming means in different scenarios and how to measure it from glass to glass in this clip from Streaming Media West Connect 2020.
21 Oct 2020