For streamers the big concern is latency. You may ask what is it? Simply defined, latency is the time it takes to get from here to there.
Now to put it in the context for streaming, it is the time content leaves the source and is played out by the intended audience. For sports, low latency is desirable and necessary. Nobody wants someone knowing about a sports play before anybody else, even if we are talking minutes.
An example of very bad latency was in the 1973 film The Sting. The gambling house knew the results of the horse race before the bets were placed. Yes, that is not good nor desirable.
For streamers, latency develops as the content passes through devices on its transport to the audience.
Let’s consider a simple audio file. First, it is played out, then the audio is processed, and next it is encoded with metadata. Then the file is sent through the network switches and routers out to the internet.
Depending on your connection, the packets may make some additional stops before reaching the CDN, which then transcodes the packets and streams them to the audience’s network connection and finally to your audience.
Yes, this takes time!
[Related: “Loudness Recommendations Honored by AES”]
Because of this time, the audience can hear a delay. It is noticeable, especially if they are comparing the stream to over-the-air content. The trick is to get the amount of latency down to the point of acceptance.
To try to lessen the inherent delay, you can use the Softvelum Low Delay Protocol (SLDP). This is a last-mile delivery protocol.
Whether you are encoding an RTMP, SRT, RTSP, NDI, MPEG-TS, HLS, Icecast or SHOUTcast stream, the SLDP protocol at the player side will pass the content to the audience with sub-second delay. SLDP is supported by modern browsers that support Media Source Extensions (MSE).
SLDP is proprietary and must be decoded with a free HTML5 player and dedicated mobile application. A custom mobile app experience can be created by subscribing to a mobile specific SDK.
The SLDP protocol also allows for synchronized playback across devices, ensuring that all members of your audience are viewing the same media at the same time. This can be incredibly important for second screen usage at live events or for any kind of real-time broadcast that both low-latency and consistent experience are important.
With sports as a key example again, imagine two viewers in a room together watching on their own devices, both getting 1- to 2-second delays, but with one about half a second ahead of the other. Each exciting play or devastating mistake spoiled for the other viewer as the quicker of the two reacts first.
Synchronized low-latency not only gives your audience a great experience compared to traditional over-the-air broadcast, but also ensures you maintain the shared experience that would otherwise be lost when viewing streamed content.
Another way is to use WebRTC, which stands for Web-based Real Time Communications. WebRTC operates very similarly to SLDP, but the issue with this Google-developed open-source solution is there is not a standard implementation. Different services are not deploying it in the same way.
WebRTC is fast. A real-time latency could be below 500 milliseconds. WebRTC is also supported by many browsers and is native to iOS.
According to StreamGuys the advantage of SLDP is the standardization of deployment.
According to Eduardo Martinez, director of technology for StreamGuys, “When you use a purpose-built protocol for ultra-low latency streaming you can significantly cut down on the delay inherent in traditional segmented streaming protocols.”
When it comes to streaming of events, mainly sports and breaking news, the audience will not tolerate high latency. In this world of multiple streams, the streamer does not want to be slower than an over-the-air broadcast. To quote Tom Petty, the waiting is the hardest part.
The author is a consultant who has held technical broadcast and streaming positions for companies like Entercom and CBS Radio. He is co-chair of the AES Technical Committee for Broadcast and Online Delivery and chair of the Metadata Usage Working Group of the National Radio Systems Committee. Contact him at [email protected] or 845-634-6595. His commentaries are a recurring feature at radioworld.com.