The Impact of Apple's Update of LL-HLS: Removing HTTP/2 Push Requirements
by THEOplayer on January 13, 2020
Last Friday Apple announced an update of their Low Latency HLS specification. In the new update, Apple is stepping away from the HTTP/2 push requirement stated in earlier specifications and seems to be moving closer to the community version of LHLS. In the overview below we will go through the most important changes and give some insights on the impact of this change.
Apple shared the update over a newly created mailing list, containing those who expressed interest in LL-HLS with a preview of the new update. While during time of writing this blog you cannot yet find it on the developer.apple.com page, it is expected to become public soon, together with new tools to setup a test environment.
“Apple had warned changes would still happen, but after a number of smaller tweaks, this update feels like the specification has been changed drastically.” - Pieter-Jan Speelmans, Founder and CTO of THEO Technologies.
The update completely removes the HTTP/2 push requirement, which was debated heavily in the industry. The HTTP/2 push requirement was causing friction: while it is clear the web is moving to new technologies, most commercial CDNs are not ready to supply this as a service yet. While some implementations were already under way and previews on certain CDN providers are becoming available, the implementations’ effort will no longer be relevant for LL-HLS anymore.
Instead of using HTTP/2 push, Apple is instead adding a new tag called #EXT-X-PRELOAD-HINT. With this tag, a server publishing a low latency HLS stream is required to announce the most likely location of the next media data which will become available. This allows a player client to perform a request, allowing the data to flow in as soon as the next part of a segment becomes available. This process can then be repeated, allowing the removal of additional round-trip time when loading new media data (which was the main reason to use HTTP/2 push).
As an additional benefit, the process makes it easier for media players to measure the bandwidth to the server (which significantly simplifies measurements for adaptive bitrate in comparison with LL-DASH scenarios, where chunks can be delivered as they are being produced).
Along with new changes, there is also attention on media delivery for those who intend to leverage range requests. A packager can now announce the next segment in a preload hint and, as parts become available and get delivered in a chunked response (which is the approach used by LHLS and LL-DASH), playlist updates can reflect the internal segment structure by publishing new #EXT-X-PART information. As the request can remain open until all parts of the segment have been provided, it efficiently eliminates overhead and can reduce the number of requests needed to play an LL-HLS stream by half. It does not, however, impact the amount of playlist updates which need to be scheduled once every part duration. This can still provide a challenge for servers, but this feels like a challenge which can be resolved.
Additionally, the update presents another advantage as it eases compatibility with the major alternative low latency solutions currently on the market, such as LL-DASH and community LHLS. In fact, the new LL-HLS specification feels like a superset of LHLS, which also makes use of a tag to announce the location of the next segment. LL-HLS has the additional benefit of describing part structure, and a number of other interesting capabilities, but it is hard not to see the similarities. Over the last year, there was already a lot of consideration to finding a way to create interoperability between LL-HLS, LHLS and LL-DASH. Akamai’s Will Law ended Demuxed with a great talk on the topic a few months ago.
Another benefit which seems to still be under the radar is the impact this has on possible server-side ad insertion solutions. With HTTP/2 push, a server publishing the LL-HLS playlist had to have been able to also publish the media data.
As most playlist manipulator services don’t control the media data itself, this caused some headache with SSAI vendors. The new change again removes this requirement and allows media to be on a different server. As a result, parts and segments containing ad data can easily be hosted on a different endpoint, and external playlist manipulation services can still be used.
The change itself likely requires significant changes to those (THEO included) who had already started implementation of LL-HLS tools. The advantages due to the new change however are significant for the industry and will remove the HTTP/2 push adoption barrier, simplifying deploying the technology. It also clearly shows that LL-HLS is still in flux. Apple had warned changes would still happen, but after a number of smaller tweaks, this update feels like the specification has been changed drastically. It is still unclear when Apple will “finalize” the LL-HLS specification. It would not be unlikely for a final version to be announced during WWDC in 2020 (which is expected in June), with an actual move to production when the new OS versions start hitting devices (which is to be expected in September).
Feel free to subscribe to our insights and we’ll make sure to keep you up to date on how the specification evolves!
If you have any questions about LL-HLS updates and THEOplayer, don't hesitate to contact our experts.