Low Latency HLS (LL-HLS) Explained for Developers

Low Latency HLS (LL-HLS) is an extension of the standard HLS protocol that reduces segment delivery delay by enabling playback of partial segments before full segments are complete. It modifies playlist behavior to include partial segment references, uses preload hints to signal upcoming data, and relies on HTTP/2 or HTTP/3 for chunked transfer and concurrent request handling. These changes are intended to lower playback latency while maintaining compatibility with the HLS infrastructure.

Protocol Characteristics

LL-HLS builds on standard HLS but introduces features that allow clients to fetch video data before an entire segment is written. The key differences include:

• Use of partial segments (a.k.a. "parts") before full segment availability.
• Preload hints in the playlist to notify clients of upcoming data.
• Blocking playlist reloads to wait for new parts.
• HTTP/2 or HTTP/3 is required to support chunked transfer and concurrent requests.

Playlist Behavior

In LL-HLS, the .m3u8 media playlist includes both regular segments and additional #EXT-X-PART tags representing partial segments. These allow the player to begin downloading incomplete segments.

LL-HLS Playlist Example:

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-TARGETDURATION:4
#EXT-X-PART-INF:PART-TARGET=0.333
#EXT-X-MEDIA-SEQUENCE:1234

#EXTINF:4.000,
segment_1234.ts

#EXT-X-PART:DURATION=0.333,URI="segment_1235_part0.ts"
#EXT-X-PART:DURATION=0.333,URI="segment_1235_part1.ts"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="segment_1235_part2.ts"

Each #EXT-X-PART represents a fragment of a segment. The #EXT-X-PRELOAD-HINT helps the player initiate early requests.

Explanation:

• #EXTM3U: Marks the file as an extended M3U playlist, the standard format for HLS streaming.
• #EXT-X-VERSION:9: Declares compatibility with HLS protocol version 9, which supports Low-Latency HLS (LL-HLS) features like PART segments and preload hints.
• #EXT-X-TARGETDURATION:4: Sets the maximum duration (in seconds) of any full segment in the playlist to 4 seconds.
• #EXT-X-PART-INF:PART-TARGET=0.333: Indicates the duration target (0.333 seconds) for partial segments.
• #EXT-X-MEDIA-SEQUENCE:1234: Specifies the sequence number of the first media segment in the playlist, useful for synchronizing playback.
• #EXTINF:4.000, followed by segment_1234.ts: Declares a full segment with a duration of 4 seconds and its URI.
• #EXT-X-PART tags: Define partial segments of the next full segment (segment_1235).
• #EXT-X-PRELOAD-HINT: Signals what segment_1235_part2.ts is expected next, allowing the player to preemptively request it.

Generating LL-HLS with FFmpeg

As of recent FFmpeg versions, LL-HLS support is experimental and depends on the muxer configuration. Use hls_flags to generate partial segments and preload hints.

ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f hls -hls_time 4 -hls_part_size 0.333 -hls_flags split_by_time+program_date_time+independent_segments+append_list -hls_playlist_type event -hls_segment_type fmp4 -master_pl_name master.m3u8 -segment_filename "segment_%d.m4s" llhls_output.m3u8

Explanation:

• -hls_time 4: Target segment length in seconds
• -hls_part_size 0.333: Partial segment duration
• -hls_flags append_list: Required for continuous playlist growth
• -hls_segment_type fmp4: LL-HLS requires fragmented MP4 segments (.m4s)

Server Requirements

LL-HLS requires HTTP/2 or HTTP/3 to support:

• Chunked transfer encoding (partial segment delivery)
• Low-latency playlist reloads (blocking behavior)

NGINX Configuration (with HTTP/2)

Ensure HTTP2 is enabled and CORS is configured properly.

server {
listen 443 ssl http2;

location /llhls/ {
add_header Access-Control-Allow-Origin *;
add_header Cache-Control no-cache;

types {
application/vnd.apple.mpegurl m3u8;
video/mp4 m4s;
}
}
}

Explanation:

• server block: Configures an HTTPS server with HTTP/2 support to serve Low-Latency HLS (LL-HLS) content under the /llhls/ path, with appropriate headers and MIME types for streaming.
• listen 443 ssl http2;: Listens on port 443 (HTTPS) with SSL/TLS encryption and enables the HTTP/2 protocol for improved performance and multiplexing.
• location /llhls/ { ... }: Defines handling rules for all requests starting with /llhls/, typically the LL-HLS playlist and segment URIs.
• add_header Access-Control-Allow-Origin *;: Adds CORS headers allowing cross-origin requests from any domain.
• add_header Cache-Control no-cache;: Instructs browsers and proxies not to cache LL-HLS content.
• types { ... }: Maps file extensions to appropriate MIME types for streaming compatibility.
• application/vnd.apple.mpegurl m3u8;: Sets .m3u8 playlist files as HLS manifests.
• video/mp4 m4s;: Sets .m4s files as fragmented MP4 segments commonly used in LL-HLS and DASH streaming.

For production deployments, consider using a CDN that supports HTTP/2 push and cache bypass for .m3u8 and .m4s files.

Playback Behavior

Client players that support LL-HLS (e.g., Safari, hls.js with experimental flags) fetch #EXT-X-PART files continuously and adjust the buffer strategy dynamically.

Tuning Playback

• Set PART-HOLD-BACK in the playlist to 1.5x PART-TARGET
• Enable blocking reloads to wait for new parts instead of polling

Player configuration must allow for smaller buffer windows and rapid manifest updates to realize latency gains.

Limitations and Considerations

Monitoring LL-HLS Segment Availability and Latency in Real-Time

For LL-HLS to work as expected, segments and partial parts must be delivered with minimal delay. Developers can validate LL-HLS behavior using network tracing, segment inspection, and manifest polling to ensure that .m4s files are published fast enough for sub-5-second playback.

Real-Time Manifest Polling with curl

To simulate the client"s behavior and measure manifest update intervals:

while true; do
curl -s https://yourdomain.com/llhls/llhls_output.m3u8 | grep EXT-X-PART
sleep 0.5
done

Explanation:

• while true; do ... done: Continuously polls a Low-Latency HLS (LL-HLS) playlist to monitor the availability of partial video segments for near real-time streaming diagnostics.
• curl -s https://yourdomain.com/llhls/llhls_output.m3u8: Fetches the LL-HLS media playlist silently from the specified server URL.
• grep EXT-X-PART: Filters and outputs only the lines containing EXT-X-PART tags, which represent partial segments of the live stream.
• sleep 0.5: Pauses the loop for half a second between requests to reduce server load while maintaining frequent polling to capture live stream changes.

Measuring Segment Generation Time

To measure the time taken between segment availability and client fetch:

curl -w "@curl-format.txt" -o /dev/null -s \
https://yourdomain.com/llhls/segment_1235_part0.m4s

With curl-format.txt:

time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_starttransfer: %{time_starttransfer}\n
total_time: %{time_total}\n

Explanation:

• curl -w "@curl-format.txt" -o /dev/null -s https://yourdomain.com/llhls/segment_1235_part0.m4s: Performs a silent HTTP request to fetch a specific Low-Latency HLS partial segment.
• -w "@curl-format.txt": Uses a custom format file (curl-format.txt) to print detailed timing information after the request completes.
• -o /dev/null: Discards the downloaded content and focuses on measuring the request performance without saving data.
• -s: Runs silently, suppressing progress and error messages.
• https://yourdomain.com/llhls/segment_1235_part0.m4s: URL of a specific partial media segment (.m4s file) in the LL-HLS stream.
• time_namelookup: Time taken to resolve the domain name to an IP address.
• time_connect: Time taken to establish the TCP connection to the server.
• time_starttransfer: Time until the first byte of the response is received, indicating server response latency.
• total_time: Total time taken for the entire HTTP request.

This provides millisecond-level visibility into CDN delivery time for .m4s chunks.

Best Practices for LL-HLS Deployment

• Keep part size and GOP size aligned (ideally 1"2 seconds) for optimal latency and smooth ABR.
• Use HTTP/2 or HTTP/3 for all segment and playlist delivery.
• Monitor segment and part availability in real time to catch issues early.
• Test across multiple players (Safari, hls.js, etc.) to ensure compatibility.
• Regularly tune encoder and buffer settings to match your network and audience needs.