This is the preliminary specification and implementation guide for adding Low-Latency HLS to your streams.
The HTTP Live Streaming (HLS) protocol delivers live and on-demand content streams to global-scale audiences. HLS has historically favored stream reliability over latency. Low-Latency HLS extends the protocol to enable low-latency video streaming while maintaining the same degree of scalability. The new low-latency mode lowers video latencies over public networks into the range of standard television broadcasts.
Backend production tools and content delivery systems must implement new rules to enable low-latency stream playback. This document outlines Low-Latency HLS functionality and the requirements for producing and delivering Low-Latency HLS streams. It also provides examples of Low-Latency HLS playlists.
Low-Latency HLS is an extension of the existing HLS protocol documented in RFC 8216 and draft-pantos-hls-rfc8216bis. As detailed in the sections that follow, Low-Latency HLS offers new functionality in these areas:
Generation of Partial Segments
Playlist Delta Updates
Blocking of playlist reload
The Server Configuration Profile Requirements section describes the server configuration profile that distribution systems must support in order to engage the low-latency playback mode. A server indicates compatibility with the low-latency mode with a new Media Playlist tag,
Generation of Partial Media Segments
Low-Latency HLS provides a parallel channel for distributing media at the live edge of the Media Playlist, where the media is divided into a larger number of smaller files, such as CMAF Chunks. These smaller files are called HLS Partial Segments. Because each Partial Segment has a short duration, it can be packaged, published, and added to the Media Playlist much earlier than its Parent Segment. While regular Media Segments might be 6s each, an example Partial Segment might be only 200ms. A first Partial Segment might be published only 200ms after the previous segment has been published, followed by 29 of its peers, followed at last by a regular 6s Media Segment. This Media Segment contains the same media as the concatenation of its 30 Partial Segments. In order to reduce playlist bloat, Partial Segments are automatically removed from the Media Playlist once they are greater (older) than 3 target durations from the live edge.
You add Partial Segments to the Media Playlist using the new
EXT-X-PART tag. You may use other Media Segment Tags (such as
EXT-X-DISCONTINUITY) only at segment boundaries, not between Partial Segments.
Playlist Delta Updates
Playlists are transferred more frequently with Low-Latency HLS. Clients can request and servers can provide Playlist Delta Updates to reduce the transfer cost. These updates replace a considerable portion of the Playlist that the client already has with the new
Blocking of Playlist Reload
To support efficient client notification of new Media Segments and Partial Segments, Low-Latency HLS introduces the ability to block a playlist reload request. When a client issues an HTTP GET to request a Media Playlist update, it can add query parameters to specify that it wants the playlist response to contain a future segment. It is the responsibility of the server to hold onto the request (block) until a version of the playlist that contains that segment is available. The client can also ask the server to push the indicated segment to the client along with the playlist response. Blocking playlist reload eliminates polling. Server push eliminates request round trips.
When playing at low latency, the client must be able to switch renditions with a minimum number of round trips in order to perform bit-rate adaptation. To support this, the client can ask that a Media Playlist update contain Rendition Reports on different renditions in the Master Playlist. The Rendition Report is carried in the
EXT-X-RENDITION-REPORT tag and provides information such as the last Media Sequence Number and Part currently in the Media Playlist of that rendition.
Playlist Request Query Parameters for Low-Latency HLS
Clients must ensure that all query parameters of the URL of a GET request for a low-latency playlist appear in UTF-8 order within the URL. This increases CDN cache utilization. You can use the following new query parameters with Low-Latency HLS:
_HLS: Indicates that the server must hold the request until a playlist contains a Media Segment with Media Sequence Number of N or later. The server must deliver the entire playlist, even if the requested Media Segment is not the last in the playlist, or in fact if it is no longer in the playlist.
_HLS: Use in combination with
_HLSto indicate that the server must hold the request until a playlist contains Partial Segment M of Media Sequence Number of N or later. The first Partial Segment of a segment is
_HLS, the second is
_HLS, and so on. The
_HLSparameter requires an
If the client asks for a Partial Segment number greater than the final part of a segment, the server must deliver a playlist containing the first Partial Segment of the following segment.
If a client supplies an
_HLS parameter greater than the Media Sequence Number of the last segment in the Playlist plus 1, or if it supplies an
_HLS parameter greater than the last Partial Segment plus 1, then the server must return 400.
_HLS do not trigger blocking if the playlist contains an
There is a 3x target duration timeout for blocking requests, after which the server must return 503.
_HLS: Indicates whether the server must push the awaited Partial Segment along with the playlist response.
0means don’t push. The absence of an
_HLSparameter is equivalent to
_HLS: Requests that the playlist response contain an
EXT-X-RENDITION-REPORTtag for the specified rendition. The path points to the Media Playlist of the specified rendition. The path may be either relative to the URI of the Media Playlist request being made, or an absolute path (starting with /) on the same server. Multiple report parameters are allowed for different paths.
_HLS: Requests a Playlist Delta Update, in which the earlier portion of the playlist is replaced with an
EXT-X-SKIPtag. The server must ignore this parameter if the playlist contains an
New Media Playlist Tags for Low-Latency HLS
Use the following playlist tags when you implement Low-Latency HLS.
EXT-X-SERVER-CONTROL allows the server to indicate support for features such as Blocking Playlist Reload and Playlist Delta Updates. This tag is required when you implement Low-Latency HLS.
All low-latency Media Playlists must carry this tag with the same attributes and values. The attribute list can consist of the following attributes:
CAN-BLOCK-RELOAD=YES: Indicates that the server supports the processing of the
_HLSparameters. It is mandatory for Low-Latency HLS.
CAN-SKIP-UNTIL=<seconds>: (optional) Indicates that the server can produce Playlist Delta Updates in response to the
_HLSparameter. Its value is the Skip Boundary, as a floating-point number of seconds. Segments and their associated tags that are further from the live edge than the Skip Boundary can be replaced by an
EXT-X-SKIPtag in a Playlist Delta Update. The Skip Boundary must be at least 6 times the
EXT-X-TARGETDURATION. You can use this attribute in low-latency and regular HLS playlists.
HOLD-BACK=<seconds>: (optional) Indicates the server-recommended minimum distance from the live edge at which clients should begin to play or to which they should seek when NOT playing in low-latency mode (that is, conventional HLS). Its value is a floating-point number of seconds and must be at least 3 times the
PART-HOLD-BACK=<seconds>: Indicates the server-recommended hold-back time when playing in low-latency mode. It is mandatory if the Playlist contains
PART-HOLD-BACK must be at least
PART-TARGET. The recommended time is at least 3 x
EXT-X-PART-INF provides information about HLS Partial Segments in the playlist. It is required if a playlist contains one or more
EXT-X-PART tags. The attribute list consists of the following attribute:
PART-TARGET=<s>: (mandatory) Indicates the part target duration in floating-point seconds and is the maximum duration of any Partial Segment.
All Partial Segments except the last part of a segment must have a duration of at least 85% of
PART-TARGET. The server must add a new Partial Segment to the Playlist every part target duration.
EXT-X-PART identifies a Partial Segment in the playlist.
The set of
EXT-X-PART tags between
EXTINF tags must represent the same set of media as the Media Segment of the following
EXTINF tag. The Media Segment containing the same media as a set of Partial Segments is called the Parent Segment of those Partial Segments.
A Partial Segment must be completely available for download at the full speed of the link to the client at the time it is added to the playlist.
All Media Segment tags with the exception of
EXT-X-GAP that are applied to a Parent Segment must appear before the first
EXT-X-PART tag of the Parent Segment. These tags include
EXT-X-PART tags from the playlist after they are greater than 3 target durations from the end of the playlist. Partial Segments are primarily useful for navigating close to the live edge, after which their presence does not justify the increase in the playlist size and the responsibility of retaining the parallel Partial Segment stream on the server. The attribute list can consist of the following attributes:
DURATION=<s>: (mandatory) Indicates the duration of the Partial Segment in floating-point seconds.
URI=<url>: (mandatory) Indicates the URI for the Partial Segment.
INDEPENDENT=YES: Indicates that the Partial Segment contains an independent frame. It is mandatory for such Partial Segments, unless every Partial Segment contains an independent frame.
BYTERANGE=<n>[@<o>]: Indicates that the Partial Segment is a subrange of the resource specified by the URI attribute. It is mandatory for such Partial Segments.
GAP=YES: Indicates that the Partial Segment is not available. It is mandatory for such Partial Segments. The rules that apply to a Media Segment with an
EXT-X-GAP tagapplied to it also apply to Partial Segments with a
GAP=YESattribute. A Parent Segment must have an
EXT-X-GAPtag applied to it if one or more of its Partial Segments have a
EXT-X-GAPtag should appear immediately after the first
EXT-X-PARTtag in the Parent Segment with a
EXT-X-RENDITION-REPORT carries information about an associated rendition that is as up-to-date as the playlist that contains it. It is added to the playlist in response to a
_HLS query parameter.
A server may return more
EXT-RENDITION-REPORT tags than requested. The attribute list can consist of the following attributes:
URI=<uri>: (mandatory) Indicates the Media Playlist described in the report. It should be the same string as the report query parameter.
LAST-MSN=<N>: (mandatory) Indicates the media sequence number of the last segment currently in the specified rendition.
LAST-PART=<M>: Indicates the last part of the segment specified by the media sequence number currently in the specified rendition. It is mandatory if the associated playlist contains
Currently the prototype tools also generate
LAST-I-PART parameters to indicate the MSN and part of the last independent part. But these may not make it into the specification because they are currently unused.
When a server issues a Playlist Delta Update, it replaces Media Segments earlier than the Skip Boundary and their associated tags with an
EXT-X-SKIP tag replaces segment URI lines and all of the following tags that are applied to those segments:
EXT-X-BITRATE. All other tags must remain in the Playlist Delta Update. The attribute list can consist of the following attributes:
SKIPPED-SEGMENTS=<N>: (mandatory) Indicates how many Media Segments were replaced by the
EXT-X-SKIPtag, along with their associated tags.
If a client receives a playlist containing an
EXT-X-SKIP tag and discovers that it does not already have all of the information that was skipped, it must obtain a complete copy of the playlist by reissuing its playlist request without the
A playlist containing an
EXT-X-SKIP tag must have an
EXT-X-VERSION tag with a value of 9 or higher.
Server Configuration Profile Requirements
To support timely delivery of media, Low-Latency HLS requires certain transport features above and beyond what is necessary for regular HLS. Clients must verify that these features are in place before engaging low-latency mode. Because the Low-Latency HLS syntax is backward-compatible with existing HLS, clients will fall back to regular-latency HLS playback if they discover that the server does not support an aspect of the required configuration.
You must serve Low-Latency HLS streams via HTTP/2 because they require several HTTP/2 features: multistream control, H2 Push, and H2 Ping. Servers must support H2 priority control (dependencies and weights). TCP is recommended, and there is no commitment to support QUIC in the first release. Each server must offer the entire set of tiers in the master playlist. This allows rapid tier switching without connection reestablishment.
TCP implementations must support Selective Acknowledgment (SACK) across the entire route from client to server. You should also set Explicit Congestion Notification (ECN) during congestion, and use TCP timestamps, TAIL LOSS probe, and TCP RACK. These additions improve the performance of TCP loss recovery. See RFC 2018, RFC 3168, RFC 7323, and IETF draft-ietf-tcpm-rack for more information about these TCP options.
Playlist requests must be idempotent. Servers should support TLS 1.3 or higher to reduce connection time. Servers should also support TLS 1.3 0-RTT connections for Media Playlists and Media Segments.
Playlists (but not segments) must be in GZIP format. This speeds up Media Playlist reload and rendition switching.
CDNs and proxy caches must recognize client playlist requests that match an existing request that is currently outstanding to the origin, and must hold the duplicate requests until the origin responds to the existing request. This is more critical in Low-Latency HLS due to its requirements for an active origin. CDNs have different names for this feature; for example, Apache Traffic Server calls it reader-while-writer.
Low-Latency HLS allows longer caching of playlists without detriment to clients. It is recommended that you cache successful playlist requests and responses with Low-Latency HLS query parameters for 6 target durations, and cache unsuccessful requests/responses (such as 404s) for 4 target durations. (It is recommended that you cache successful responses to playlist requests that don’t contain the
_HLS query parameter for 0.5 target duration and unsuccessful responses for 1 target duration.)
Origins should use cache-control headers to indicate the desired cache lifetime.
Different renditions must update in sync, to within 1 part-target duration.
Revisions to Existing Media Authoring Rules for Low-Latency HLS Streams
Media Playlists must have
EXT-PROGRAM-DATE-TIME tags. This allows more precise mapping between segments across renditions. (Note that real-time clocks are NOT required to be synchronized between client and server). The recommended 6s target duration still applies. The recommended GOP size is 1-2s. Smaller GOPs support faster switching between renditions.