The impact of Apple’s Protocol Extension for Low-Latency HLS

Achieving lower latency is a priority concern for most people in our industry. There have been multiple efforts in recent times to achieve this, including the work done within the community to standardise Low-Latency HLS (LHLS). Recently, Apple also announced their Protocol Extension for Low-Latency HLS (ALHLS). With the Apple ecosystem being highly used, the industry will need to implement these new changes, but what will be the impact on the end-to-end delivery chain?

Looking at Apple’s new solution, it seems to assume manifests are always generated dynamically. It is adding a high number of query parameters to manifest requests, which will need to be supported to generate new and dynamic manifests. The main drawback to this is the increased complexity and the questions it raises about scalability. In terms of scalability, manifest manipulators have been generating personalised manifests for a while now, so we assume this to be an issue that can be overcome. However, there is a significant trade-off in the added complexity for the gained advantages.

It is also clear Apple pushes HTTP/2 forward instead of HTTP/1.1. This aligns with a more future-focused solution, using the latest HTTP version, instead of building on older ones. The disadvantage to this is the support. Whilst CMAF-CTE is still being deployed, common CDNs are still showing problems running HTTP/1.1 at scale. Running HTTP/2 with push will undoubtedly require additional work for CDN vendors. It will also increase complexity for origin vendors. While upgrading CDNs will be needed to support HTTP/2, the rollout will have to be accelerated to support the ALHLS use cases.

An important omission seems to be the improvement of metrics such as zapping time and bandwidth usage. A zapping time of a few seconds has a massive impact on viewer abandonment and is absolutely unacceptable for experiences on the big screen. Similarly, while bandwidth usage for manifests can go down slightly due to improvements in the specification, the approach still seems to push you towards short segments and parts, introducing new bandwidth overhead. With bandwidth becoming a major cost driver for large streaming services, every percentage is starting to count in the bottom line.

A big problem with the new specification is that the end-to-end performance is still unclear. Tests show latency on-par with CMAF-CTE and LHLS, with between 3s and 10s of latency. While these latencies are sufficient for most OTT cases, and should allow for a switch to IP for connected devices and STBs, the ALHLS approach does not appear to add a significant improvement on top of existing solutions. Another big problem presented itself when looking at how a player could achieve this low latency; while a manifest request can be issued for a specific low latency segment and part, there is no definition of how a player can learn about the most up to date request when starting playback. As a result, a high startup latency was to be expected, a problem which Apple had to rectify in an update of the specification.

As the specification is still in draft, there is a good chance changes are still coming. A lot of vendors seem to be looking at each other to time product availability, not wanting to rush things but in fear of missing out on the opportunity. We expect this to be a major talking point during IBC, with early prototypes of this new technology becoming available. THEO will be demonstrating an early ALHLS prototype at our booth, and our team will also be on-hand to answer any questions you may have surrounding implementation and process.

Pieter-Jan Speelmans is CTO at THEO Technologies.