How to Choose the Right Server Software for HTTP Low Latency

Many producers are seeking a low-latency technology for their streaming applications. In general, there are two primary technologies to choose from, HTTP Low Latency and WebRTC. This article will discuss considerations for choosing the right streaming server for the first solution, HTTP Low Latency streaming.

What Is HTTP Low Latency?

HTTP Low Latency describes technologies that use CMAF-formatted media to distribute streams to HLS and DASH players over HTTP. This includes Apple’s new Low-Latency HLS spec and low-latency CMAF for DASH.

Though it’s technically feasible to deploy HTTP Low Latency streams without a server, using one adds significant flexibility. For example, Wowza Streaming Engine™ media server software will be able to deliver HTTP Low Latency streams as just another output format, so you can use your existing on-premise capture hardware and protocols like SRT to minimize latency and maintain signal quality. A server such as Wowza Streaming Engine can also help manage caching efficiency and allow you to scale low latency broadcasts for large audiences.

If you’re using an existing streaming server or solutions provider for your live or VOD broadcasts, check whether that company provides an HTTP Low Latency solution. Using an existing provider will likely prove the most efficient and economical approach. If you decide to evaluate other providers, here’s a list of items to consider.

Integration Across Service Providers

Design flexibility —HTTP Low latency solutions have multiple components, including an encoder, streaming server, and player, as well as service providers like CDNs. If you have significant investment in any of these components or existing relationships with key service providers, you’ll want the flexibility to keep using these. So check the integrations offered by your prospective service provider to ensure you can continue to use current components and service providers. You may want to avoid vendors that lock you into their own components, as this essentially is the same as choosing a proprietary technology.

Also, check the depth of these integrations. HTTP Low Latency streaming presents a range of unique challenges not faced by typical streaming. For example, what happens if playback stops for a few moments due to loss of bandwidth? Do you resume at the break, immediately jump to the live feed, or catch up over time? Can the player vary playback speed automatically to ensure that all viewers are synchronized? The service provider must provide an API that enables this type of decision-making and a rigorous QA program to ensure optimal performance. If you’re designing your own multi-vendor solution, choose a server vendor with the market presence to ensure compatibility with other vendors.

On the other hand, HTTP Low Latency streaming requires a balancing act between latency, quality, scalability, and playback robustness. Vendors that offer a full end-to-end workflow can promote overall performance via communications between the encoder, server, and player. So if you’re seeking ultimate performance or don’t have existing components or providers, consider a vendor that can provide an integrated solution.

Feature Set

Though HTTP Low Latency streaming is based on industry standards, there are many features that may or may not be implemented by different providers. These include:

Protocol support — CMAF supports HTTP streaming for both HLS and DASH. Most first-generation solutions will likely initially support only HLS, but DASH support will expand the list of target platforms and should at least be on the drawing board.

DRM support — Many low latency applications will also need access protection, so check which DRMs and DRM providers are supported to ensure that you can reach all required platforms.

Push/pull delivery — Most players will pull the low latency stream from the server, but some players and CDNs will want the stream pushed to them. Virtually all providers will support pull, but if a push-based workflow is critical to your application, make sure it’s in the plans.

Single or multiple bitrate — Most first-generation HTTP Low Latency solutions will output a single bitrate, but the specification also supports adaptive bitrate streaming, which is obviously desirable. If your application could benefit from adaptive bitrate delivery, be sure to ask if it’s on the drawing board.

Performance and scalability — HTTP Low Latency streaming should be able to support glass-to-glass latency of three seconds or less, so be sure to check this in your tests. If you’re renting or licensing a server, determine how many simultaneous streams the server can support. If these figures aren’t available, check performance numbers for HLS output, which should be fairly similar.

Configuration and control — As mentioned, HTTP Low Latency streaming is a balancing act, and your technology should provide the controls necessary for you to customize the operation to fit your unique requirements. For example, you must able to configure chunk sizes for the number of included frames, tune your transcoding configuration, and have access to APIs for controlling metadata, subtitles, and captions.

Analytics and reporting — You’ll want sufficient real-time data to identify and respond to any technical issues during live events, as well as the data necessary to gauge overall performance. Features to look for here include stream health monitoring, active sessions and stream counts, and bytes in and out.

Conclusion

Though HTTP Low Latency seems exotic today, it will quickly become just another format available from streaming providers. As such, check with your existing service provider first to assess when and how well they intend to deploy and support HTTP Low Latency streaming. If you decide to change service providers to deliver HTTP Low Latency streams, be sure to assess the candidate’s ability to deploy existing streaming protocols as well.