Latency Sucks Less: Advancements in Low-Latency Live Streaming

September 10, 2018 by

Everywhere you turn in the streaming industry, the talk in mid-2018 is less about formats than it is about latency.

It started as a trickle in 2016, around the time that StreamingMedia.com published my article “Latency Sucks!”—appropriately titled due to the limited low-latency options available at the time. Since then, it has turned into a deluge of offerings around low latency, ultra-low-latency and real-time streaming.

Wowza was early to the low-latency party, as a quick read of previous posts on this very blog will attest, and the company published a very handy graphic that showed the continuum of delay versus scale.

This image continues to resonate, even in 2018, where the discussion has moved from latencies in the tens of seconds to the low-single-digit seconds.

 

Technologies for Low-Latency Live Video Streaming

Here are just a few of the technologies that are being used to address low latency:

WebRTC and WebSocket.

This is an area where a number of advances have been made, yet WebRTC and WebSocket are two discrete solutions attempting to solve a common issue.

First, WebRTC, which has been touted by many as a way to replace the venerable Real-Time Messaging Protocol (RTMP) that’s been the mainstay of low-latency live streaming. Like RTMP, WebRTC can be used for very low-latency streaming, and works well for one-to-one or one-to-few scenarios. However, it doesn’t scale well on its own. When used with a media server, such as Wowza Streaming Engine™ software, WebRTC can be used to stream to larger audiences while alleviating concerns over quality and scalability, though this comes at the expense of low latency.

Technically, WebRTC is actually more akin to the original Real-Time Streaming Protocol (RTSP), but also securely delivers RTP (a non-secure transport protocol) via a protocol known as SRTP. By delivering a secure real-time stream to the browser, WebRTC eliminates the need for a plug-in. It also works nicely with HTML5, which has video and audio tags as well as the ability to create graphics with transparency, so that in-browser delivery can be graphically equivalent to a branded mobile app.

WebSocket, on the other hand, is just what it sounds like: The technology is composed of sockets used by a web browser to perform a specific function. In the past, sockets used in the browser could be triggered for a short period of time, but lacked the persistence of state required for long-form video delivery or real-time streaming. WebSocket provides low-latency video streaming delivery through the use of persistent connections in JavaScript.

WebSocket allows for custom protocols to be delivered directly to the browser, which is where the majority of ultra-low-latency streaming is currently focused.

 

Server-side ad insertion.

While the idea of focusing on lower latency by way of a combination of live-linear and pre-recorded content might seem a non sequitur, a legacy technology is proving to be beneficial for lowering overall latencies when it comes to ad-supported live content.

Advertisements in streaming video have traditionally been focused more towards on-demand timelines. These pre-roll, mid-roll (known as “interstitials”) or post-roll ads were inserted at the client level, to be played back between portions of the main on-demand content.

To seamlessly allow on-demand video to play back-to-back with interstitial ads, the pre-recorded advertisement had to be sent to the end user’s video player before the on-demand content finished playing. Not only did this cause a bottleneck for those viewers on limited data networks, but it also meant that the end user’s player ideally used two video players: one for ads, and one for primary, on-demand content.

In addition, the advertisement itself had to be positioned on the client device—meaning ad placement had to be coordinated days or weeks ahead of time.

To get around this, a newer process called “server-side ad insertion” was invented. In this scenario, pre-recorded ads are served as part of the live-linear stream, but “stitched” together with the live-linear content so that the end user’s video player didn’t face the additional player or bandwidth constraints noted above.

The byproduct of all this was an ability to optimize the connection between the streaming server, the ad server and the end user—normalizing bandwidth, smoothing out playback and decreasing overall latency.

Allen Wolk, a contributor to Forbes who covers “the future of television, from broadcast to digital to social,” summed it up nicely in an August 2018 article about Verizon Digital Media Services:

Since “the viewer receives a single, unbroken stream,” writes Wolk, ”that all but eliminates the sort of latency issues (e.g., delays) that can happen with client-side ad servers… [and] also eliminates any threats from ad-blocking software, as, from a code perspective, the ads become indistinguishable from the programming.”

 

What about HTTP delivery?

When the original specifications for HTTP-based video delivery were announced more than a decade ago, it was clear that the sweet spot for solutions—from Apple HTTP Live Streaming (HLS) to Adobe Dynamic Adaptive Streaming to Microsoft Smooth Streaming—was to address scalability at the expense of latency.

HLS, for instance, recommended segment (or “chunk”) lengths of two to 10 seconds, and best practices required at least three of these segments to be downloaded to the end user’s video player prior to the start of playback.

The benefit of delivering the stream as a series of thousands of small files, using the web standard of HTTP, appealed to network administrators. Similarly, the ability for the HTTP-based streaming solution to choose between a handful of data rates (known as adaptive bitrate streaming) appealed to content owners who wanted to get their content out to both wireless mobile devices and wired desktop or over-the-top (OTT) players.

Fast-forward a decade, and we’re now seeing much more work being done around single-second segment sizes. This allows companies such as Wowza to offer “sub-three-second end-to-end latency on a global scale” coupled with HTTP delivery through new, proprietary technology.

Wowza sees this as low enough latency “for near-real-time” streaming, thanks to the Wowza Streaming Cloud service with Ultra Low Latency, which can be employed to deliver streaming apps and services that allow for more authentic interactions.

Wowza also offers the ability to use WebRTC as both ingest and playback, with the Wowza Streaming Cloud service acting as the scaling mechanism—and enhanced functionality for WebRTC ingest is coming soon. (To be notified when this becomes available, sign up here.)

 

Connect With Wowza at IBC.

Wowza will provide several demonstrations of the new capabilities for Wowza Streaming Engine, Wowza ClearCaster and Wowza Streaming Cloud with Ultra Low Latency during the IBC Show. This year, there are multiple ways to connect with Wowza at IBC:

  • Stop by Wowza stand 14.E08 at any time.
  • Visit us in the Facebook Video Solutions pavilion at 14.C45.
  • Come see us in the Microsoft Azure partner pavillion stand 1.C27.

IBC Special Promotions

To schedule a meeting and take advantage of these special promotions onsite, visit: https://calendly.com/wowza/ibc-2018