Video: Best Practices and Key Considerations for Reducing Latency

Learn more about reducing latency at Streaming Media West.

Read the complete transcript of this clip:

Jamie Sherry: Depending on your use case and what you're trying to achieve, and how latency is part of that use case, there are different techniques for lowering latency. There isn't one silver bullet here. You can choose one of many protocols or technologies to try to solve these things. They have trade-offs, they have positives and negatives. But you really need to think about it at every step in your workflow.

It's not just about the network, it's not just about the buffer management, which I do have listed here. It's content creation too. It's the features you need. In the sense that if you need to do transcoding, for example, that's going to introduce latency. That can be minor, but it can be major, too. If you're going to manipulate content in other ways with metadata or with encryption or anything else, usually these things are OK, but again, it just depends.

It all depends topology-wise where you're doing these things in relation to how you're then delivering it to the user. I know that doesn't sound easy, but that's the way this goes right now. Content creation, things like codecs. There's bitrate and resolution, these all impact things. Streaming workflow and devices, whatever devices you're hitting on whatever networks they are: WiFi, 4G, all those things have network fluctuations. Public internet. If you're on private connections with enterprise or corporate stuff, it can be different or it can be better because you have more control there, usually.

The workflow, again, reflects on what you're trying to do with the content before you actually get it to the consumer. Buffer management, the encoder and the player specifically, also the server. Again, you can reduce these buffers in these areas to almost nothing but, again, you run into the risk of if you have a network fluctuation or degradation, that you may have a negative impact on the playback.

Network considerations really boil down to two areas: how you optimize the delivery using the transport protocols that we talked about and the protocols that might sit on top of that. HTTP vs. RTMP vs. RTSP. Then how you reach your audience. Again, size, location, all those things matter in terms of the latency. The front-runners that people are trying really today are things like WebRTC and WebSocket. There are definitely a lot of offerings out there that have, from the ground up, written services and software that use these under the hood to do what they do. There are a lot of them that are doing really good things.

These pieces you need to just make sure, again, when you're dealing with proprietary protocols, these are standards based. But, essentially, when you're not dealing with HTTP, on the playback side, you need to have ... I call them aware clients. Basically, you can't just drop a video tag, an HTML5 video tag in a browser and have it work. You need to actually write some code around that to make it possible to do this. Then the server scale-out infrastructure piece, depending on what protocol you use, the scaling of that in either an Origin Edge, mid-tier topology, or otherwise requires a lot of servers and a lot of specifics to those protocols.

CDNs are definitely investigating and trying things and doing things in these spaces. They want to keep their caching infrastructure going. They want to support new use cases and leverage that to support them. What I call tuned HTTP, is to reduce chunk size and to reduce other aspects of the content, are what I call a front-runner today but there are CDNs considering WebRTC. There are, again, other options out there that I'll talk about in a second that don't use HTTP.