3 Ways Apple Low Latency HLS (ALHSL) Insufficiently Reduces Latency

The process of video live streaming involves an array of codecs and protocols and the team at Red5 Pro has spent over 14 years examining and analyzing them. With a guiding focus on reducing latency and increasing latency, decisions have been made about the specific protocols used in the Red5 Pro Platform.

One such decision made was to not use HLS variants such as Apple Low Latency HLS (ALHSL). As a part of our ongoing series of technical articles, this post outlines three ways that Apple Low Latency HLS lowers the latency of standard HLS, but ultimately is not fast enough to provide real-time latency.

HLS and the Evolution to ALHSL

As we’ve covered before, HLS is a delivery technology used for sending and receiving live video that originally developed by Apple to run on their devices. To optimize a stream for delivery, the file is split into small media segments or chunks. This allows for a much faster transmission as sending out small files is much more efficient than sending one long, continuous file.

Initially, Apple recommended a chunk size of 10 seconds and had their player buffer three segments before starting the stream. Accordingly, that created a latency of 30 to 40 seconds. While this made for a reliable stream, it made any sort of interactivity impossible. You can’t have a conversation when you need to wait for 30+ seconds in between responses.

Something faster was needed…

Apple Low Latency HLS

Apple extended the HLS protocol creating their own low latency HLS. It reduces latency through the use of 3 approaches:

Generation of Partial Segments

Apple Low Latency HLS divides the full media file into smaller parts of TS or CMAF chunks. Otherwise known as HLS Partial Segments, these smaller files can be packaged, published, and added to the Media Playlist much earlier than its full Parent Segment.

For example, regular Media Segments may be 6 seconds each but the Partial Segment might only be 200ms. Accordingly, the partial segment may be be published immediately after the previous segment has been delivered. It will then be followed by 29 more partial segments with the regular 6 second Media Segment delivered last.

The regular segment contains the full concatenation of its 30 Partial Segments. However, Partial Segments are automatically removed from the Media Playlist once they are more than 3 target durations from the live edge, in order to reduce playlist bloat.

To increase the processing speed, these parts are advertised at the head of the HLS playlist so that players can download smaller groups of frames right after they are encoded. To further increase the speed with which the parts are retrieved by a player the new protocol uses HTTP/2 push. In this way, once the player makes a playlist request it will automatically receive the parts via HTTP/2 push.

Playlist Delta Updates

Using Apple Low Latency HLS, playlists are transferred more frequently. Clients can request and servers can provide Playlist Delta Updates to reduce the transfer cost.

Blocking of Playlist Reload

Apple Low Latency HLS added the ability to block a playlist reload request in order to support efficient client notification of new Media Segments and Partial Segments. When a client issues an HTTP GET call to request a Media Playlist update, it can add query parameters to specify that it wants the playlist response to contain a future segment. Upon receipt of the request, the server is tasked with holding onto the request (block) until a version of the playlist that contains that segment is available. The client can also ask the server to push the indicated segment to the client along with the playlist response.

In other words, this makes it possible to create “delta” playlists which contain only some of the segments of the overall playlist. Using that method, a player can download the full playlist only once and then use the much smaller delta playlist to get the latest few segments.

What is the Actual Latency?

Despite all the modifications to HLS, Apple Low Latency HLS still results in latency from 3 – 7 seconds. As we’ve stated again and again –and again– seconds of latency will always be too high for fully interactive, real-time live streaming.

With the increased use of mobile devices, the already quickly moving pace of information flow is still accelerating. High latency leaves users vulnerable to spoilers and a poor user experience. Drone surveillance, live auctions, broadcasting live events, and social media chatting, are some of the many use-cases that require real-time latency.

Plus, additional configurations such as enabling HTTP/2 Push are needed for full support of CDN networks.

Furthermore, since ALHSL is controlled by Apple, it is NOT a community-based standard. Thus solutions built around Apple Low Latency HLS may face issues if Apple decides to make any changes to how it works as any changes won’t be subject to community review or debate.

Lastly, the implementation of ALHSL is more complex than Community Low Latency HLS without real-time latency results.

So What Now?

Red5 Pro integrated with WebRTC resulting in an industry leading, sub 500 milliseconds of latency. That is the only way to achieve true real-time live streaming. Importantly, Red5 Pro maintains that performance even when scaling to millions of broadcasters and subscribers.

For a more in-depth view of how Red5 Pro works along with all the live streaming protocols in general (WebRTC, WebSockets and MSE, CMAF, and more), take a look at our whitepaper.

Looking for something else? Send an email to info@red5.net or schedule a call.