Fundamentals 19 min read

Understanding HLS Protocol and Apple’s Low‑Latency Extensions

This article explains the HTTP Live Streaming (HLS) protocol, its standard playlist and segment structure, the latency challenges of traditional HLS, and details Apple’s low‑latency HLS draft with five technical improvements, demo implementation, and a comparison to Periscope’s LHLS approach.

Huajiao Technology
Huajiao Technology
Huajiao Technology
Understanding HLS Protocol and Apple’s Low‑Latency Extensions

HTTP Live Streaming (HLS) is an Apple‑originated adaptive bitrate streaming protocol defined in RFC 8216 and widely supported by browsers, operating systems, and streaming servers. It works by breaking a live or on‑demand stream into small HTTP‑downloadable files referenced in M3U8 playlists, allowing bitrate switching and firewall traversal.

Because HLS uses standard HTTP, it can pass through firewalls and be delivered via existing HTTP CDNs, simplifying deployment and enabling basic DRM through encryption and HTTPS key distribution. The protocol supports both live and VOD use cases.

Apple’s low‑latency HLS draft, announced at WWDC 2019, introduces five key enhancements to reduce end‑to‑end latency from 10‑30 seconds to under 2 seconds:

Reduce segment publishing delay by introducing #EXT-X-PART and #EXT-X-PART-INF tags, allowing parts of a segment to be published before the full segment is ready.

Optimize segment discovery with a blocking M3U8 load mechanism using #EXT-X-SERVER-CONTROL (e.g., CAN-BLOCK-RELOAD=YES ).

Eliminate segment request RTT by leveraging HTTP/2 server push ( #EXT-X-SERVER-CONTROL with CAN-BLOCK-RELOAD and push parameters).

Introduce incremental playlist updates so clients receive only changes, reducing bandwidth.

Accelerate bitrate switching by adding #EXT-X-RENDITION-REPORT tags that report the current state of alternate renditions.

Example master playlist with multiple bitrates:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=2000000,CODECS="avc1.640028,mp4a.40.2"
2M/mid.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4000000,CODECS="avc1.640028,mp4a.40.2"
4M/high.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=500000,CODECS="avc1.640028,mp4a.40.2"
0.5M/low.m3u8

Typical media playlist snippet:

#EXTM3U
#EXT-X-TARGETDURATION:4
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:3.96667,
fileSequence0.ts
#EXTINF:3.96667,
fileSequence1.ts
#EXTINF:3.96667,
fileSequence2.ts
#EXTINF:3.96667,
fileSequence3.ts

Key tag descriptions (excerpt from the RFC) are presented in a table, covering tags such as EXTM3U , EXT-X-VERSION , EXTINF , EXT-X-STREAM-INF , EXT-X-TARGETDURATION , and EXT-X-MEDIA-SEQUENCE .

Latency analysis shows that the target duration (often equal to the GOP size) and CDN cache TTL add significant delay, sometimes exceeding 18 seconds on mobile networks.

Apple’s five improvements are illustrated with code examples. For reducing segment publishing delay, a playlist using #EXT-X-PART looks like:

#EXTM3U
#EXT-X-TARGETDURATION:4
#EXT-X-VERSION:3
#EXT-X-PART-INF:PART-TARGET=0.202000
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:3.96667,
fileSequence0.ts
#EXT-X-PART:DURATION=0.20000,URI="filePart7.1.ts"
#EXT-X-PART:DURATION=0.20000,INDEPENDENT=YES,URI="filePart7.2.ts"
…
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,CAN-SKIP-UNTIL=24,PART-HOLD-BACK=0.610

The blocking load mechanism uses #EXT-X-SERVER-CONTROL and client requests such as GET https://example.com/live.m3u8?_HLS_msn=1803 or with part and push parameters to receive data as soon as it becomes available.

Incremental updates are signaled with #EXT-X-SERVER-CONTROL:CAN-SKIP-UNTIL=36.0 and the client can request only the delta using _HLS_skip=YES .

Rendition reports accelerate bitrate switches:

#EXT-X-RENDITION-REPORT:URI="../1M/waitForMSN.php",LAST-MSN=273,LAST-PART=3
#EXT-X-RENDITION-REPORT:URI="../4M/waitForMSN.php",LAST-MSN=273,LAST-PART=3

A practical demo requires an HTTP/2‑enabled server (e.g., Nginx with listen 443 ssl http2 ) and PHP scripts to serve the playlists and parts. Tests on iOS 13 beta Safari showed playback but latency remained 8‑15 seconds, indicating incomplete client support for the low‑latency extensions.

The analysis concludes that deploying Apple’s low‑latency HLS incurs high operational cost and complexity. An alternative, Periscope’s Low‑Latency HLS (LHLS), uses HTTP/1.1 chunked transfer encoding to broadcast upcoming segments early, achieving comparable latency with lower infrastructure requirements, though it lacks precise bandwidth estimation for adaptive bitrate switching.

References include the HLS RFC 8216, Apple’s low‑latency specification, WWDC video, and several RFCs related to TCP and HTTP/2.

CDNlow-latency streamingHTTP/2HLSm3u8Media Protocol
Huajiao Technology
Written by

Huajiao Technology

The Huajiao Technology channel shares the latest Huajiao app tech on an irregular basis, offering a learning and exchange platform for tech enthusiasts.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.