Doing Interactive Streaming the Right Way: Ultra-Low Latency Streaming at Scale With HESP

In recent years, the High Efficiency Streaming Protocol, commonly known as HESP, has significantly enhanced the cost-effectiveness and performance of large-scale ultra-low latency streaming.

In use cases that require interactivity, latency plays a crucial role in determining the viewer quality of experience. Interactive scenarios, such as online auctions, live concerts with fan engagement, or interactive TV formats that involve voting, are particularly sensitive to long delays, which can negatively impact the user experience. In some cases, delays can cause missed opportunities, while in others, content creators may need to incorporate artificial waiting periods into their content to allow time for viewer feedback. There are also more subtle examples where latency can affect the user experience, such as when watching a sports game and facing potential spoilers from sources like noisy neighbors, push notifications with score updates, or text messages from friends expressing their excitement about something that has happened.

HESP is an HTTP-based protocol. This means it can leverage standard content delivery networks (CDNs). These CDNs serve as the backbone of the Internet and are continuously delivering billions of assets, ranging from web pages and images to video files, to a global audience. By leveraging these capabilities, HESP can provide ultra-low latency streaming at any scale. This is in contrast with other ultra-low latency protocols such as WebRTC, where scaling is complex and expensive, as it takes place through spinning up additional server infrastructure in the backend.

Figure 1. High efficiency streaming through HESP brings a high viewer quality of experience.

High-efficiency streaming through HESP does not only provide for ultra-low latency at scale. It additionally brings benefits such as fast channel change and improved adaptive bitrate (ABR), almost instantly changing qualities upon changing network conditions. Other benefits of HESP are full compatibility with studio-approved DRM, and the possibility of cost savings when working at broadcast latencies of about 5–7 seconds, as it then provides more time for encoding, compared to protocols such as LL-HLS and LL-DASH.

In its essence, HESP is quite simple and feels familiar to those already working with streaming protocols such as Apple’s HLS or MPEG-DASH. During main playback, streaming is nearly identical to that of these protocols: A media player is simply downloading a list of chunked media segments and playing them one after the other. This group of segments, in HESP lingo, is called the Continuation Stream.

The special sauce of HESP can be found in the so-called Initialization Stream. The Initialization Stream is a specially crafted stream from which a client will load a single packet when performing stream startup, or when switching between alternative qualities to adapt to the network. These packets, for which a numbered, individually addressable packet can exist for each frame in the video, contain all the information required to perform video startup… fast. An Initialization Packet will often contain decoder configuration, DRM configuration, a full picture frame (I-frame), and a reference to where in the Continuation Stream the next frame can be found.

When a media client wants to start playback, the process is very simple: You collect the Initialization Packet where you want to start playback and follow its reference to start downloading the Continuation Stream. Upon receipt of the Initialization Packet, clients can already start retrieving DRM licenses, and render out the first picture to the viewer. During playback, when the client reaches the end of a segment in the
Continuation Stream, it simply requests the next one, and so on, and so on. Simple, but efficient.

HESP’s low-latency capabilities stem from the same principle. By allowing startup of a stream on any frame, and by being able to execute this very fast, client buffers required to ensure stability can be reduced, effectively reducing latency as well. In current tests, production deployments of HESP can perform stream startup within a few hundred milliseconds, allowing for stable playback at latencies as low as 700ms–900ms.

Today the number of solutions that offer HESP capabilities is growing. The HESP Alliance, an industry body dedicated to publishing and evolving the HESP IETF specification, promoting the protocol, and ensuring inter-vendor compatibility, maintains a growing list of HESP-Ready solutions. This includes a wide range of industry brands such as encoders and packagers from Synamedia and NativeWaves, DRM solutions from BuyDRM and EZDRM, and CDNs from Akamai and G-Core, as well as the THEOplayer media player and the THEOlive real-time streaming platform. The ecosystem is expanding further with an even broader set of companies listed as members working on compatible products: Arena.TV, Ceeblue, Hoki, Mainstreaming, MediaMelon, Scalstrm, SyncWords, and Videon.

Figure 2. The number of solutions that offer HESP capabilities is growing.

Today, the HESP technology can already be found in production for a notable group of different use cases such as live auctions, online health and fitness, live event streaming, sportsbook betting, interactive TV, and more. This list will likely expand more into mainstream content as the number of solutions increases.

If you’re interested in learning more about HESP or have questions about how to get started with HESP, please email us at contact@hespalliance.org.

About HESP Alliance

The HESP Alliance, founded by Synamedia and THEO Technologies, brings together streaming video vendors and media companies to provide superior online video quality of experience at reduced cost through standardizing and advancing the High Efficiency Streaming Protocol (HESP) and marketing of HESP solutions.

For more information, please visit www.hespalliance.org.

This article is Sponsored Content