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. Historically, HLS has favored stream reliability over latency. Low-Latency HLS extends the protocol to enable low-latency video streaming while maintaining 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
Preload hints and blocking of Media downloads
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 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.
A Partial Segment must be in one of the Supported Media Segment Formats described by the HLS specification (sections 3.1 through 3.5).
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 include 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. Blocking Playlist reload eliminates polling.
Preload Hints and Blocking of Media Downloads
Eliminating unnecessary round trips is critical when delivering low-latency streams at global scale. Servers use a new tag, EXT-X-PRELOAD-HINT, to inform clients of upcoming Partial Segments and Media Initialization Sections. A client can issue a GET request for a hinted resource in advance; the server responds to the request as soon as the media becomes available.
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 server must add Rendition Reports on the other renditions in the Master Playlist to each Media Playlist. A 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 current Playlist plus two, or if it supplies an
_HLS parameter that exceeds the last Partial Segment in the current Playlist by the Advance Part Limit, then the server should immediately return 400. The Advance Part Limit is three divided by the PART-TARGET if the PART-TARGET is less than one second, or three otherwise.
_HLS do not trigger blocking if the Playlist contains an
A timeout of three times the target duration is recommended for blocking Playlist requests, after which the server should return 503.
_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 processing the _
_HLSparameters, blocking requests for hinted resources and the publishing of Rendition Reports. 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 six 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 three 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
EXT-X-PARTtags. This attribute's value is a floating-point number of seconds and must be at least
PART-TARGET. The recommended time is at least three times the
PART-TARGET. If different Renditions have different
PART-HOLD-BACKshould be at least three times the maximum.
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 except for
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 three target durations from the end of the Playlist. Partial Segments are 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 strongly recommended that every Partial Segment containing an independent frame carries this attribute to increase the efficiency with which clients can join and switch Renditions.
BYTERANGE=<n>[@<o>]: Indicates that the Partial Segment is a subrange of the resource specified by the URI attribute. This is mandatory if a Partial Segment is a subrange of the resource specified by the URI attribute.
GAP=YES: Indicates that the Partial Segment is not available. It is mandatory for 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-PRELOAD-HINT tag hints that a resource or a byte range of a resource will be needed to play back an upcoming part of the presentation. The hinted resource must be available for request when the
EXT-X-PRELOAD-HINT tag is added to the Playlist.
When processing requests for a URL or a byte range of a URL that includes one or more Partial Segments that are not yet completely available to be sent — such as requests made in response to an
EXT-X-PRELOAD-HINT tag — the server must refrain from transmitting any bytes belonging to a Partial Segment until all bytes of that Partial Segment can be transmitted at the full speed of the link to the client. If the requested range includes more than one Partial Segment then the server must enforce this delivery guarantee for each Partial Segment in turn. This enables the client to perform accurate Adaptive Bit Rate (ABR) measurements.
The server should respond with 404 to a request for a resource that it can't find and that isn't specified by an
EXT-X-PRELOAD-HINT tag in an active (in other words, live) Media Playlist.
The attribute list can consist of the following attributes:
TYPE=<hint-type>: (mandatory) Specifies the type of the hinted resource. If
PART, the resource is an upcoming Partial Segment. If
MAP, the resource is an upcoming Media Initialization Section.
URI=<uri>: (mandatory) Specifies the hinted resource. It must match the URI string that will be subsequently added to the Playlist as a nonhinted resource (for example, as part of an
EXT-X-PARTtag). The URI may be relative to the URI of the Playlist or it may be absolute. The hostname may or may not match.
BYTERANGE-START=<n>: Indicates that the requested resource begins at a particular byte offset from the beginning of the resource identified by the URI attribute. Its absence implies a value of 0.
BYTERANGE-LENGTH=<n>: Indicates the length of the requested resource, which may be less than the length of the resource identified by the URI attribute. Its absence indicates that the specified range extends from the start offset to the end of the resource identified by the URI attribute.
Note that when a hinted Partial Segment eventually appears in the Playlist as an
EXT-X-PART tag, it may be different than previous Partial Segment. It may have a different Discontinuity Sequence Number, Media Initialization Section, or encryption configuration. In other words, the Partial Segment can be preceded by an
EXTINF tag indicating the end of the previous Parent Segment and an
If the Playlist contains
EXT-X-PART tags and does not contain an
EXT-X-ENDLIST tag, the Playlist must contain an
EXT-X-PRELOAD-HINT tag with a
TYPE=PART attribute to hint the URI of the next
EXT-X-PART tag that is expected to be added to the Playlist (and its byte range, if applicable). Upon reading such a Playlist, a client with sufficient space in its download pipeline that is not already loading the hinted resource should issue a GET request for the hinted resource. This will typically be issued at the same time as its GET request for the next Playlist update.
If the hinted Partial Segment specified by the
TYPE=PART EXT-X-PRELOAD-HINT tag has a different Media Initialization Section than the last Partial Segment in the Playlist, the Playlist must also contain an
EXT-X-PRELOAD-HINT tag with a
TYPE=MAP attribute that identifies the Media Initialization Section of the hinted Partial Segment. A client with sufficient space in its download pipeline that has not already cached the hinted Media Initialization Section should issue a GET request for the section.
Servers should not add more than one
EXT-X-PRELOAD-HINT tag with the same
TYPE attribute to a Playlist. Clients should ignore all but the first
EXT-X-PRELOAD-HINT tag with a particular
TYPE attribute in a Playlist, and clients must ignore
EXT-X-PRELOAD-HINT tags with unrecognized
A server may choose not to publish a previously-hinted Partial Segment if the planned segmentation changes, such as the case of early return from an ad. The server should respond to client requests for that Partial Segment with a 404.
A client should abandon the download of a hinted resource if it does not appear in a subsequent Playlist update, either as in
EXT-X-PRELOAD-HINT tag or as part of another tag such as
EXT-X-PART. The client should ignore the result code of such a GET request.
If a Partial Segment is created as a subrange of a larger resource and its length is not known at the time that its hint is added to the Playlist, the
BYTERANGE-LENGTH attribute should be omitted. The
BYTERANGE-OFFSET should indicate the Partial Segment's starting offset into the larger resource. This information signals the client to issue a download request from the start of the hinted Partial Segment to the end of the resource.
A client should recognize when a Partial Segment indicated by an
EXT-X-PART tag is a subrange of a hint download and obtain the Partial Segment from the hint download. Clients must recognize contiguous ranges between existing Partial Segments and Partial Segment hints and avoid duplicate downloads.
A server should not hint a range that it does not expect to be downloaded by clients in the near term.
EXT-X-RENDITION-REPORT carries information about an associated rendition that is as up-to-date as the Playlist that contains it.
The server must add one
EXT-RENDITION-REPORT tag for each Media Playlist (Rendition) in the Master Playlist, except for the Media Playlist to which the
EXT-X-RENDITION-REPORT tag is being added and Playlists that contain the
EXT-X-I-FRAMES-ONLY tag. The attribute list can consist of the following attributes:
URI=<uri>: (mandatory) Identifies the Media Playlist of the specified Rendition. It must be relative to the URI of the Media Playlist containing the
LAST-MSN=<N>: (mandatory) Indicates the Media Sequence Number of the last segment currently in the specified rendition. If the rendition contains Partial Segments, then this value is the Media Sequence Number of the segment containing the last Partial Segment.
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
A server may omit adding an attribute to an
EXT-X-RENDITION-REPORT tag — even a mandatory attribute — if its value is the same as that of the Rendition Report of the Media Playlist to which the
EXT-X-RENDITION-REPORT tag is being added. This step reduces the size of the Rendition Report.
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 nine or higher.
Server Configuration Profile Requirements
To support timely delivery of media, Low-Latency HLS requires certain transport features 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 efficient delivery requires HTTP/2 features such as multistream control and Ping requests. 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 in order to allow rapid tier switching without connection reestablishment. Servers must support HTTP Range requests if Media Playlists contain the
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 in order to speed up Media Playlist reload and rendition switching.
CDNs and proxy caches must recognize client Playlist requests and blocking media 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. Doing so is critical in Low-Latency HLS to minimize load on the active origin.
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 six target durations, and cache unsuccessful requests and responses (such as 404s) for four target durations. (It is recommended that you cache successful responses to Playlist requests that don’t contain the
_HLS query parameter for half the target duration, and unsuccessful responses for one target duration.) It is recommended that unsuccessful responses to blocking media requests be cached for one target duration.
Origins should use cache-control headers to indicate the desired cache lifetime.
Different renditions must update in sync, to within one part-target duration.
HTTP caches used for delivery of Low-Latency HLS must set the Age HTTP Response header.
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 six-second target duration still applies. The recommended GOP size is one to two seconds. Smaller GOPs support faster switching between renditions.
Each Parent Segment in a Media Playlist that contains
EXT-X-PART tags must contain at least one independent frame.
Example: Low-Latency HLS Playlist
Example: Playlist Delta Update
Example: Byterange-addressed Parts
Appendix A: CDN Tune-In
Players and other clients of Low-Latency HLS should expect delivery of low-latency streams through CDNs and other HTTP caches. To correctly implement the server-recommended playback distance from the live feed,
PART-HOLD-BACK, the client must first obtain a reasonably up-to-date version of the Media Playlist.
There are various approaches that a client may take to obtain a recent version of a Media Playlist. The following algorithm typically requires two GET requests to obtain a Playlist that’s within one part target duration of the current Playlist:
Send a request for the Media Playlist that doesn’t include an
Record the first Playlist response, including its received time and Age header. If there’s no Age header in the first Playlist response, consider the Playlist to be up to date. (No Age header means that the response came directly from the origin, rather than being held for a period of time in an intervening HTTP cache.)
If there’s an Age header in the first Playlist response, set the
goalto match the Age value. Add one second to the
goalvalue if the part target duration is less than 1.0.
While the Age value is greater than or equal to the floor of the part target duration:
currentto be the
goalplus the amount of time since the first Playlist response.
If the current version of the Playlist has at least
currentmore media in it than the first Playlist, consider the current Playlist to be up to date.
Use the target duration and the part target duration to estimate how many more segments and parts the server will add to the Playlist to contribute at least
currentmore media to it.
Request the Media Playlist again, using the
_HLSparameters to obtain the Playlist that has the estimated additional duration of media since the first Playlist.
Update the current Playlist and the Age value from the Playlist response.
The following table describes the changes to the Protocol Extension for Low-Latency HLS (Preliminary Specification).
Added additional information related to preload hints and blocking of media downloads.
Added the CDN Tune-in appendix.
Updated MSN and part validation rules. Made server response recommended instead of mandatory. Added the requirement of the AGE header when using HTTP proxy caches.
Added new document describing Low-Latency HTTP Live Streaming.