Apple recently announced their Protocol Extension for Low-Latency HLS (Preliminary Specification). In this blogpost we will talk through a few of the exciting new features, and a few that we aren't so sure about yet.
If you want to know the basics about HLS, or a previous solution for Low Latency HLS (LHLS) you can check out our other blogpost here: Blogpost - HLS and Low Latency HLS (LHLS).
What we're excited about...
Reduced Latency HLS
It goes without saying that the enabling of low latency in HLS is more than a substantial improvement. The promise of enabling 6-8 seconds latency with broadcast encoding qualities or to 2-3 seconds for specialist scenarios is without a doubt the biggest improvement for HLS in recent years. It will put OTT delivery finally on par with traditional live streaming for all devices.
Although, Apple are coming a little late to the party, with other methods for reducing latency for HLS having previously been attempted, including LHLS (check out our Blogpost on HLS and Low Latency HLS).
Backwards compatible with regular HLS
Another thing we are excited about with the Protocol Extension for Low-Latency HLS, is the backwards compatibility with regular HLS. Players that do not understand the protocol extension will playback the content, as if nothing has changed. Non optimised players will play back the same streams, with a higher (regular) latency. This allows publishers to offer a single HLS solution both for optimised and non-optimised players.
Available for both MP4 AND transport stream
Contrary to expectations Apple has made available the Protocol Extension for Low-Latency for both Transport Stream and MP4 containers. As older iOS versions only play back transport stream, this means we can deliver low latency streams to iOS versions below iOS 10.
What we aren't sure about yet...
Missed opportunity for a simpler solution
I’m sure we aren’t the only ones surprised that Apple didn’t opt for a CMAF-CTE (chunked transfer encoding) solution. This type of low latency solution would have streamlined and made easier the process for those also distributing low latency content via DASH streams. While it is possible to use the same chunked CMAF video container if you go with CMAF HLS (not transport stream), the infrastructure delivery requirements are greatly different. Whereas CMAF-CTE depends on simple HTTP 1.1 chunked transfer, Apple’s implementation requires specific HTTP 2 features and a dedicated manifest controller.
Questionable potential for affordable scalability
Although the preliminary specification release describes this new extension as maintaining the current scalability, there are some questions as to the affordability/ scalability. The concerns surrounding this are based on increase in server requirements for this protocol extension. The new protocol extension requires a number of HTTP/2 features (including multi stream control, H2 push and H2 ping) therefore you are required to serve Low Latency HLS streams via HTTP/2. We don't believe any of the major CDN’s are ready for this today.
Certainly, blocking playlist reloads will put significant strain on the server that could have been avoided using other techniques, it also opens the door to easily exploitable DOS attacks.
Requires a complex CDN logic, delaying implementation.
Probably the biggest concern is that the specification requires an intimate collaboration between the manifest manipulator and the CDN. Tying together both manifest generation and data delivery (through segment push) will require new algorithms and scalability strategies for CDN providers. This is likely to take considerable time and cost to implement.
Positives and negatives aside, there is one thing for sure; that we are looking forward to seeing the progression of the new Protocol Extension for Low-Latency HLS.
Want to know more about how THEOplayer can support low latency on HLS? Get in touch with our team.