6. Client/Server Responsibilities
This section describes how the server generates the Playlist and
Media Segments and how the client should download them for playback.
6.2. Server Responsibilities
6.2.1. General Server Responsibilities
The production of the source media is outside the scope of this
document, which simply presumes a source of continuous encoded media
containing the presentation.
The server MUST divide the source media into individual Media
Segments whose duration is less than or equal to a constant target
duration. Segments that are longer than the planned target duration
can trigger playback stalls and other errors.
The server SHOULD attempt to divide the source media at points that
support effective decode of individual Media Segments, e.g., on
packet and key frame boundaries.
The server MUST create a URI for every Media Segment that enables its
clients to obtain the segment data. If a server supports partial
loading of resources (e.g., via HTTP Range requests), it MAY specify
segments as sub-ranges of larger resources using the EXT-X-BYTERANGE
Any Media Segment that is specified in a Playlist loaded by a client
MUST be available for immediate download, or playback errors can
occur. Once download starts, its transfer rate SHOULD NOT be
constrained by the segment production process.
HTTP servers SHOULD transfer text files -- such as Playlists and
WebVTT segments -- using the "gzip" Content-Encoding if the client
indicates that it is prepared to accept it.
The server must create a Media Playlist file (Section 4) that
contains a URI for each Media Segment that the server wishes to make
available, in the order in which they are to be played.
The value of the EXT-X-VERSION tag (Section 220.127.116.11) SHOULD NOT be
greater than what is required for the tags and attributes in the
Playlist (see Section 7).
Changes to the Playlist file MUST be made atomically from the point
of view of the clients, or playback errors MAY occur.
The server MUST NOT change the Media Playlist file, except to:
o Append lines to it (Section 6.2.1).
o Remove Media Segment URIs from the Playlist in the order that they
appear, along with any tags that apply only to those segments
o Increment the value of the EXT-X-MEDIA-SEQUENCE or EXT-X-
DISCONTINUITY-SEQUENCE tags (Section 6.2.2).
o Add an EXT-X-ENDLIST tag to the Playlist (Section 6.2.1).
A Media Playlist has further constraints on its updates if it
contains an EXT-X-PLAYLIST-TYPE tag. An EXT-X-PLAYLIST-TYPE tag with
a value of VOD indicates that the Playlist file MUST NOT change. An
EXT-X-PLAYLIST-TYPE tag with a value of EVENT indicates that the
server MUST NOT change or delete any part of the Playlist file; it
MAY append lines to it.
The value of the EXT-X-TARGETDURATION tag in the Media Playlist MUST
NOT change. A typical target duration is 10 seconds.
Playlist changes other than those allowed here can trigger playback
errors and inconsistent client behavior.
Each Media Segment in a Media Playlist has an integer Discontinuity
Sequence Number. The Discontinuity Sequence Number can be used in
addition to the timestamps within the media to synchronize Media
Segments across different Renditions.
A segment's Discontinuity Sequence Number is the value of the EXT-X-
DISCONTINUITY-SEQUENCE tag (or zero if none) plus the number of EXT-
X-DISCONTINUITY tags in the Playlist preceding the URI line of the
The server MAY associate an absolute date and time with a Media
Segment by applying an EXT-X-PROGRAM-DATE-TIME tag to it. This
defines an informative mapping of the (wall-clock) date and time
specified by the tag to the first media timestamp in the segment,
which may be used as a basis for seeking, for display, or for other
purposes. If a server provides this mapping, it SHOULD apply an EXT-
X-PROGRAM-DATE-TIME tag to every segment that has an EXT-
X-DISCONTINUITY tag applied to it.
The Server MUST NOT add any EXT-X-PROGRAM-DATE-TIME tag to a Playlist
that would cause the mapping between program date and Media Segment
to become ambiguous.
The server MUST NOT remove an EXT-X-DATERANGE tag from a Playlist if
any date in the range maps to a Media Segment in the Playlist.
The server MUST NOT reuse the ID attribute value of an EXT-
X-DATERANGE tag for any new Date Range in the same Playlist.
Once the Following Range of a Date Range with an END-ON-NEXT=YES
attribute is added to a Playlist, the Server MUST NOT subsequently
add a Date Range with the same CLASS attribute whose START-DATE is
between that of the END-ON-NEXT=YES range and its Following Range.
For Date Ranges with a PLANNED-DURATION attribute, the Server SHOULD
signal the actual end of the range once it has been established. It
can do so by adding another EXT-X-DATERANGE tag with the same ID
attribute value and either a DURATION or an END-DATE attribute or, if
the Date Range has an END-ON-NEXT=YES attribute, by adding a
If the Media Playlist contains the final Media Segment of the
presentation, then the Playlist file MUST contain the EXT-X-ENDLIST
tag; this allows clients to minimize unproductive Playlist reloads.
If a Media Playlist does not contain the EXT-X-ENDLIST tag, the
server MUST make a new version of the Playlist file available that
contains at least one new Media Segment. It MUST be made available
relative to the time that the previous version of the Playlist file
was made available: no earlier than one-half the target duration
after that time, and no later than 1.5 times the target duration
after that time. This allows clients to utilize the network
If the server wishes to remove an entire presentation, it SHOULD
provide a clear indication to clients that the Playlist file is no
longer available (e.g., with an HTTP 404 or 410 response). It MUST
ensure that all Media Segments in the Playlist file remain available
to clients for at least the duration of the Playlist file at the time
of removal to prevent interruption of in-progress playback.
6.2.2. Live Playlists
The server MAY limit the availability of Media Segments by removing
Media Segments from the Playlist file (Section 6.2.1). If Media
Segments are to be removed, the Playlist file MUST contain an EXT-X-
MEDIA-SEQUENCE tag. Its value MUST be incremented by 1 for every
Media Segment that is removed from the Playlist file; it MUST NOT
decrease or wrap. Clients can malfunction if each Media Segment does
not have a consistent, unique Media Sequence Number.
Media Segments MUST be removed from the Playlist file in the order
that they appear in the Playlist; otherwise, client playback can
The server MUST NOT remove a Media Segment from a Playlist file
without an EXT-X-ENDLIST tag if that would produce a Playlist whose
duration is less than three times the target duration. Doing so can
trigger playback stalls.
When the server removes a Media Segment URI from the Playlist, the
corresponding Media Segment MUST remain available to clients for a
period of time equal to the duration of the segment plus the duration
of the longest Playlist file distributed by the server containing
that segment. Removing a Media Segment earlier than that can
interrupt in-progress playback.
If the server wishes to remove segments from a Media Playlist
containing an EXT-X-DISCONTINUITY tag, the Media Playlist MUST
contain an EXT-X-DISCONTINUITY-SEQUENCE tag. Without the EXT-X-
DISCONTINUITY-SEQUENCE tag, it can be impossible for a client to
locate corresponding segments between Renditions.
If the server removes an EXT-X-DISCONTINUITY tag from the Media
Playlist, it MUST increment the value of the EXT-X-DISCONTINUITY-
SEQUENCE tag so that the Discontinuity Sequence Numbers of the
segments still in the Media Playlist remain unchanged. The value of
the EXT-X-DISCONTINUITY-SEQUENCE tag MUST NOT decrease or wrap.
Clients can malfunction if each Media Segment does not have a
consistent Discontinuity Sequence Number.
If a server plans to remove a Media Segment after it is delivered to
clients over HTTP, it SHOULD ensure that the HTTP response contains
an Expires header that reflects the planned time-to-live.
A Live Playlist MUST NOT contain the EXT-X-PLAYLIST-TYPE tag, as no
value of that tag allows Media Segments to be removed.
6.2.3. Encrypting Media Segments
Media Segments MAY be encrypted. Every encrypted Media Segment MUST
have an EXT-X-KEY tag (Section 18.104.22.168) applied to it with a URI that
the client can use to obtain a Key file (Section 5) containing the
A Media Segment can only be encrypted with one encryption METHOD,
using one encryption key and IV. However, a server MAY offer
multiple ways to retrieve that key by providing multiple EXT-X-KEY
tags, each with a different KEYFORMAT attribute value.
The server MAY set the HTTP Expires header in the key response to
indicate the duration for which the key can be cached.
Any unencrypted Media Segment in a Playlist that is preceded by an
encrypted Media Segment MUST have an EXT-X-KEY tag applied to it with
a METHOD attribute of NONE. Otherwise, the client will misinterpret
those segments as encrypted.
If the encryption METHOD is AES-128 and the Playlist does not contain
the EXT-X-I-FRAMES-ONLY tag, AES encryption as described in
Section 22.214.171.124 SHALL be applied to individual Media Segments.
If the encryption METHOD is AES-128 and the Playlist contains an EXT-
X-I-FRAMES-ONLY tag, the entire resource MUST be encrypted using
AES-128 CBC with PKCS7 padding [RFC5652]. Encryption MAY be
restarted on 16-byte block boundaries, unless the first block
contains an I-frame. The IV used for encryption MUST be either the
Media Sequence Number of the Media Segment or the value of the IV
attribute of the EXT-X-KEY tag, as described in Section 5.2. These
constraints allow a client to load and decrypt individual I-frames
specified as sub-ranges of regular encrypted Media Segments, and
their Media Initialization Sections.
If the encryption METHOD is SAMPLE-AES, media samples MAY be
encrypted prior to encapsulation in a Media Segment.
The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if
it applies to any Media Segment in the Playlist file, or clients who
subsequently load that Playlist will be unable to decrypt those Media
6.2.4. Providing Variant Streams
A server MAY offer multiple Media Playlist files to provide different
encodings of the same presentation. If it does so, it SHOULD provide
a Master Playlist file that lists each Variant Stream to allow
clients to switch between encodings dynamically.
Master Playlists describe regular Variant Streams with EXT-X-STREAM-
INF tags and I-frame Variant Streams with EXT-X-I-FRAME-STREAM-INF
If an EXT-X-STREAM-INF tag or EXT-X-I-FRAME-STREAM-INF tag contains
the CODECS attribute, the attribute value MUST include every media
format [RFC6381] present in any Media Segment in any of the
Renditions specified by the Variant Stream.
The server MUST meet the following constraints when producing Variant
Streams in order to allow clients to switch between them seamlessly:
o Each Variant Stream MUST present the same content.
o Matching content in Variant Streams MUST have matching timestamps.
This allows clients to synchronize the media.
o Matching content in Variant Streams MUST have matching
Discontinuity Sequence Numbers (see Section 126.96.36.199).
o Each Media Playlist in each Variant Stream MUST have the same
target duration. The only exceptions are SUBTITLES Renditions and
Media Playlists containing an EXT-X-I-FRAMES-ONLY tag, which MAY
have different target durations if they have an EXT-X-PLAYLIST-
TYPE of VOD.
o Content that appears in a Media Playlist of one Variant Stream but
not in another MUST appear either at the beginning or at the end
of the Media Playlist file and MUST NOT be longer than the target
o If any Media Playlists have an EXT-X-PLAYLIST-TYPE tag, all Media
Playlists MUST have an EXT-X-PLAYLIST-TYPE tag with the same
o If the Playlist contains an EXT-X-PLAYLIST-TYPE tag with the value
of VOD, the first segment of every Media Playlist in every Variant
Stream MUST start at the same media timestamp.
o If any Media Playlist in a Master Playlist contains an EXT-X-
PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent
mappings of date and time to media timestamps.
o Each Variant Stream MUST contain the same set of Date Ranges, each
one identified by an EXT-X-DATERANGE tag(s) with the same ID
attribute value and containing the same set of attribute/value
In addition, for broadest compatibility, Variant Streams SHOULD
contain the same encoded audio bitstream. This allows clients to
switch between Variant Streams without audible glitching.
The rules for Variant Streams also apply to alternative Renditions
(see Section 188.8.131.52.1).
6.3. Client Responsibilities
6.3.1. General Client Responsibilities
How the client obtains the URI to the Playlist file is outside the
scope of this document; it is presumed to have done so.
The client obtains the Playlist file from the URI. If the Playlist
file so obtained is a Master Playlist, the client can select a
Variant Stream to load from the Master Playlist.
Clients MUST ensure that loaded Playlists comply with Section 4 and
that the EXT-X-VERSION tag, if present, specifies a protocol version
supported by the client; if either check fails, the client MUST NOT
attempt to use the Playlist, or unintended behavior could occur.
If any URI element in a Playlist contains an URI scheme that the
client cannot handle, the client MUST stop playback. All clients
MUST support HTTP schemes.
To support forward compatibility, when parsing Playlists, clients
o ignore any unrecognized tags.
o ignore any attribute/value pair with an unrecognized
o ignore any tag containing an attribute/value pair of type
enumerated-string whose AttributeName is recognized but whose
AttributeValue is not recognized, unless the definition of the
attribute says otherwise.
Algorithms used by the client to switch between Variant Streams are
beyond the scope of this document.
6.3.2. Loading the Media Playlist File
Every time a Media Playlist is loaded or reloaded from a Playlist
URI, the client MUST determine the next Media Segment to load, as
described in Section 6.3.5, if it intends to play the presentation
normally (i.e., in Playlist order at the nominal playback rate).
If the Media Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the
client SHOULD assume that each Media Segment in it will become
unavailable at the time that the Playlist file was loaded plus the
duration of the Playlist file.
A client MAY use the segment Media Sequence Number to track the
location of a Media Segment within a Playlist when the Playlist is
A client MUST NOT assume that segments with the same Media Sequence
Number in different Variant Streams or Renditions have the same
position in the presentation; Playlists MAY have independent Media
Sequence Numbers. Instead, a client MUST use the relative position
of each segment on the Playlist timeline and its Discontinuity
Sequence Number to locate corresponding segments.
A client MUST load the Media Playlist file of every Rendition
selected for playback in order to locate the media specific to that
Rendition. But, to prevent unnecessary load on the server, it SHOULD
NOT load the Playlist file of any other Rendition.
For some Variant Streams, it is possible to select Renditions that do
not include the Rendition specified by the EXT-X-STREAM-INF tag. As
noted above, the client SHOULD NOT load that Rendition in those
6.3.3. Playing the Media Playlist File
The client SHALL choose which Media Segment to play first from the
Media Playlist when playback starts. If the EXT-X-ENDLIST tag is not
present and the client intends to play the media normally, the client
SHOULD NOT choose a segment that starts less than three target
durations from the end of the Playlist file. Doing so can trigger
Normal playback can be achieved by playing the Media Segments in the
order that they appear in the Playlist. The client MAY present the
available media in any way it wishes, including normal playback,
random access, and trick modes.
The encoding parameters for samples in a Media Segment and across
multiple Media Segments in a Media Playlist SHOULD remain consistent.
However, clients SHOULD deal with encoding changes as they are
encountered, for example, by scaling video content to accommodate a
resolution change. If the Variant Stream includes a RESOLUTION
attribute, clients SHOULD display all video within a rectangle with
the same proportions as that resolution.
Clients SHOULD be prepared to handle multiple tracks of a particular
type (e.g., audio or video). A client with no other preference
SHOULD choose the track with the lowest numerical track identifier
that it can play.
Clients SHOULD ignore private streams inside Transport Streams that
they do not recognize. Private streams can be used to support
different devices with the same stream, although stream authors
SHOULD be sensitive to the additional network load that this imposes.
The client MUST be prepared to reset its parser(s) and decoder(s)
before playing a Media Segment that has an EXT-X-DISCONTINUITY tag
applied to it; otherwise, playback errors can occur.
The client SHOULD attempt to load Media Segments in advance of when
they will be required for uninterrupted playback to compensate for
temporary variations in latency and throughput.
The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to
display the program origination time to the user. If the value
includes time zone information, the client SHALL take it into
account; if it does not, the client MAY assume the time to be local.
Note that dates in Playlists can refer to when the content was
produced (or to other times), which have no relation to the time of
If the first EXT-X-PROGRAM-DATE-TIME tag in a Playlist appears after
one or more Media Segment URIs, the client SHOULD extrapolate
backward from that tag (using EXTINF durations and/or media
timestamps) to associate dates with those segments. To associate a
date with any other Media Segment that does not have an EXT-X-
PROGRAM-DATE-TIME tag applied to it directly, the client SHOULD
extrapolate forward from the last EXT-X-PROGRAM-DATE-TIME tag
appearing before that segment in the Playlist.
6.3.4. Reloading the Media Playlist File
The client MUST periodically reload a Media Playlist file to learn
what media is currently available, unless it contains an EXT-X-
PLAYLIST-TYPE tag with a value of VOD, or a value of EVENT and the
EXT-X-ENDLIST tag is also present.
However, the client MUST NOT attempt to reload the Playlist file more
frequently than specified by this section, in order to limit the
collective load on the server.
When a client loads a Playlist file for the first time or reloads a
Playlist file and finds that it has changed since the last time it
was loaded, the client MUST wait for at least the target duration
before attempting to reload the Playlist file again, measured from
the last time the client began loading the Playlist file.
If the client reloads a Playlist file and finds that it has not
changed, then it MUST wait for a period of one-half the target
duration before retrying.
After reloading a Media Playlist, the client SHOULD verify that each
Media Segment in it has the same URI (and byte range, if specified)
as the Media Segment with the same Media Sequence Number in the
previous Media Playlist. It SHOULD halt playback if it does not, as
this normally indicates a server error.
In order to reduce server load, the client SHOULD NOT reload the
Playlist files of Variant Streams or alternate Renditions that are
not currently being played. If it decides to switch playback to a
different Variant Stream, it SHOULD stop reloading the Playlist of
the old Variant Stream and begin loading the Playlist of the new
Variant Stream. It can use the EXTINF durations and the constraints
in Section 6.2.4 to determine the approximate location of
corresponding media. Once media from the new Variant Stream has been
loaded, the timestamps in the Media Segments can be used to
synchronize the old and new timelines precisely.
A client MUST NOT attempt to use the Media Sequence Number to
synchronize between streams (see Section 6.3.2).
6.3.5. Determining the Next Segment to Load
The client MUST examine the Media Playlist file every time it is
loaded or reloaded to determine the next Media Segment to load, as
the set of available media MAY have changed.
The first segment to load is generally the segment that the client
has chosen to play first (see Section 6.3.3).
In order to play the presentation normally, the next Media Segment to
load is the one with the lowest Media Sequence Number that is greater
than the Media Sequence Number of the last Media Segment loaded.
6.3.6. Decrypting Encrypted Media Segments
If a Media Playlist file contains an EXT-X-KEY tag that specifies a
Key file URI, the client can obtain that Key file and use the key
inside it to decrypt all Media Segments to which that EXT-X-KEY tag
A client MUST ignore any EXT-X-KEY tag with an unsupported or
unrecognized KEYFORMAT attribute, to allow for cross-device
addressability. If the Playlist contains a Media Segment to which
only EXT-X-KEY tags with unrecognized or unsupported KEYFORMAT
attributes are applied, playback SHOULD fail.
A client MUST NOT attempt to decrypt any segments whose EXT-X-KEY tag
has a METHOD attribute that it does not recognize.
If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be
applied to individual Media Segments, whose encryption format is
described in Section 184.108.40.206.
If the encryption METHOD is AES-128 and the Media Segment is part of
an I-frame Playlist (Section 220.127.116.11) and it has an EXT-X-BYTERANGE
tag applied to it, special care needs to be taken in loading and
decrypting the segment, because the resource identified by the URI is
encrypted in 16-byte blocks from the start of the resource.
The decrypted I-frame can be recovered by first widening its byte
range, as specified by the EXT-X-BYTERANGE tag, so that it starts and
ends on 16-byte boundaries from the start of the resource.
Next, the byte range is widened further to include a 16-byte block at
the beginning of the range. This 16-byte block allows the correct IV
for the following block to be calculated.
The widened byte range can then be loaded and decrypted with AES-128
CBC using an arbitrary IV. The number of bytes added to the
beginning and the end of the original byte range are discarded from
the decrypted bytes; what remains is the decrypted I-frame.
If the encryption METHOD is SAMPLE-AES, AES-128 decryption SHALL be
applied to encrypted media samples within the Media Segment.
An EXT-X-KEY tag with a METHOD of NONE indicates that the Media
Segments it applies to are not encrypted.
7. Protocol Version Compatibility
Protocol compatibility is specified by the EXT-X-VERSION tag. A
Playlist that contains tags or attributes that are not compatible
with protocol version 1 MUST include an EXT-X-VERSION tag.
A client MUST NOT attempt playback if it does not support the
protocol version specified by the EXT-X-VERSION tag, or unintended
behavior could occur.
A Media Playlist MUST indicate an EXT-X-VERSION of 2 or higher if it
o The IV attribute of the EXT-X-KEY tag.
A Media Playlist MUST indicate an EXT-X-VERSION of 3 or higher if it
o Floating-point EXTINF duration values.
A Media Playlist MUST indicate an EXT-X-VERSION of 4 or higher if it
o The EXT-X-BYTERANGE tag.
o The EXT-X-I-FRAMES-ONLY tag.
A Media Playlist MUST indicate an EXT-X-VERSION of 5 or higher if it
o The KEYFORMAT and KEYFORMATVERSIONS attributes of the EXT-X-KEY
o The EXT-X-MAP tag.
A Media Playlist MUST indicate an EXT-X-VERSION of 6 or higher if it
o The EXT-X-MAP tag in a Media Playlist that does not contain EXT-
A Master Playlist MUST indicate an EXT-X-VERSION of 7 or higher if it
o "SERVICE" values for the INSTREAM-ID attribute of the EXT-X-MEDIA
The EXT-X-MEDIA tag and the AUDIO, VIDEO, and SUBTITLES attributes of
the EXT-X-STREAM-INF tag are backward compatible to protocol version
1, but playback on older clients may not be desirable. A server MAY
consider indicating an EXT-X-VERSION of 4 or higher in the Master
Playlist but is not required to do so.
The PROGRAM-ID attribute of the EXT-X-STREAM-INF and the EXT-X-I-
FRAME-STREAM-INF tags was removed in protocol version 6.
The EXT-X-ALLOW-CACHE tag was removed in protocol version 7.
8.6. Master Playlist with Alternative Audio
In this example, the CODECS attributes have been condensed for space.
A '\' is used to indicate that the tag continues on the following
line with whitespace removed:
8.7. Master Playlist with Alternative Video
This example shows three different video Renditions (Main,
Centerfield, and Dugout) and three different Variant Streams (low,
mid, and high). In this example, clients that did not support the
EXT-X-MEDIA tag and the VIDEO attribute of the EXT-X-STREAM-INF tag
would only be able to play the video Rendition "Main".
Since the EXT-X-STREAM-INF tag has no AUDIO attribute, all video
Renditions would be required to contain the audio.
In this example, the CODECS attributes have been condensed for space.
A '\' is used to indicate that the tag continues on the following
line with whitespace removed:
8.8. Session Data in a Master Playlist
In this example, only the EXT-X-SESSION-DATA is shown:
VALUE="This is an example"
VALUE="Este es un ejemplo"
8.9. CHARACTERISTICS Attribute Containing Multiple Characteristics
Certain characteristics are valid in combination, as in:
8.10. EXT-X-DATERANGE Carrying SCTE-35 Tags
This example shows two EXT-X-DATERANGE tags that describe a single
Date Range, with an SCTE-35 "out" splice_insert() command that is
subsequently updated with an SCTE-35 "in" splice_insert() command.
... Media Segment declarations for 60s worth of media
9. IANA Considerations
IANA has registered the following media type [RFC2046]:
Type name: application
Subtype name: vnd.apple.mpegurl
Required parameters: none
Optional parameters: none
Encoding considerations: encoded as UTF-8, which is 8-bit text. This
media type may require encoding on transports not capable of handling
8-bit text. See Section 4 for more information.
Security considerations: See Section 10.
Compression: this media type does not employ compression.
Interoperability considerations: There are no byte-ordering issues,
since files are 8-bit text. Applications could encounter
unrecognized tags, which SHOULD be ignored.
Published specification: see Section 4.
Applications that use this media type: Multimedia applications such
as the iPhone media player in iOS 3.0 and later and QuickTime Player
in Mac OS X version 10.6 and later.
Fragment identifier considerations: no Fragment Identifiers are
defined for this media type.
Deprecated alias names for this type: none
Magic number(s): #EXTM3U
File extension(s): .m3u8, .m3u (see Section 4)
Macintosh file type code(s): none
Person & email address to contact for further information: David
Intended usage: LIMITED USE
Restrictions on usage: none
Author: Roger Pantos
Change Controller: David Singer
10. Security Considerations
Since the protocol generally uses HTTP to transfer data, most of the
same security considerations apply. See Section 15 of HTTP
Media file parsers are typically subject to "fuzzing" attacks.
Implementors SHOULD pay particular attention to code that will parse
data received from a server and ensure that all possible inputs are
Playlist files contain URIs, which clients will use to make network
requests of arbitrary entities. Clients SHOULD range-check responses
to prevent buffer overflows. See also the Security Considerations
section of "Uniform Resource Identifier (URI): Generic Syntax"
Apart from URL resolution, this format does not employ any form of
Clients SHOULD limit each playback session to a reasonable number of
concurrent downloads (e.g., four) to avoid contributing to denial-of-
HTTP requests often include session state ("cookies"), which may
contain private user data. Implementations MUST follow cookie
restriction and expiry rules specified by "HTTP State Management
Mechanism" [RFC6265] to protect themselves from attack. See also the
Security Considerations section of that document, and "Use of HTTP
State Management" [RFC2964].
Encryption keys are specified by URI. The delivery of these keys
SHOULD be secured by a mechanism such as HTTP Over TLS [RFC2818]
(formerly SSL) in conjunction with a secure realm or a session token.
11.1. Normative References
[AC_3] Advanced Television Systems Committee, "Digital Audio
Compression (AC-3) (E-AC-3) Standard", ATSC
Standard A/52:2010, November 2010, <http://atsc.org/
[AES_128] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197,
DOI 10.6028/NIST.FIPS.197, November 2001,
[CEA608] Consumer Electronics Association, "ANSI/CEA 608-E: Line 21
Data Services", April 2008.
[CEA708] Consumer Technology Association, "Digital Television (DTV)
Closed Captioning", ANSI/CTA Standard CEA-708-E, August
International Organization for Standardization,
"Information technology -- MPEG systems technologies --
Part 7: Common encryption in ISO base media file format
files", ISO/IEC 23001-7:2016, February 2016,