HK1189735B - Real-time or near real-time streaming with compressed playlists - Google Patents

Description

Real-time or near real-time streaming with compressed playlists

RELATED APPLICATIONS

This application claims benefit of U.S. provisional patent application 61/288,828 (docket No. P7437Z 6), filed on 21/12/2009, and is hereby incorporated by reference herein; and this application is also a continuation-in-part application of the following U.S. applications:

(1) claim of benefit of U.S. provisional patent application No.61/142,110 (case No. P7437Z) filed on 31/12/2008, U.S. provisional patent application No.61/160,693 (case No. P7437Z 2) filed on 16/3/2009, U.S. provisional patent application No.61/161,036 (case No. P7437Z 3) filed on 17/3/2009, U.S. provisional patent application No.61/167,524 (case No. P7437Z 4) filed on 7/4/2009, and entitled "R" filed on 5/6/2009_EAL-T_IMEOR N_EARR_EAL-T_IMES_TREAMING"application No.12/479,690 (case No. P7437US 1); and

(2) claim of benefit of U.S. provisional patent application No.61/142,110 (case No. P7437Z) filed on 31/12/2008, U.S. provisional patent application No.61/160,693 (case No. P7437Z 2) filed on 16/3/2009, U.S. provisional patent application No.61/161,036 (case No. P7437Z 3) filed on 17/3/2009, U.S. provisional patent application No.61/167,524 (case No. P7437Z 4) filed on 7/4/2009, and title "V" filed on 5/6/2009_ARIANTS_TREAMSFOR R_EAL-T_IMEOR N_EARR_EAL-T_IMES_TREAMING"application No.12/479,698 (case No. P7437US 2); and

(3) U.S. provisional patent application No.61/142,110 (case No. P7437Z) filed on 31/12/2008, and U.S. provisional patent application N filed on 16/3/2009o.61/160,693 (case No. P7437Z 2), U.S. provisional patent application No.61/161,036 (case No. P7437Z 3) filed on day 3, month 17 in 2009, U.S. provisional patent application No.61/167,524 (case No. P7437Z 4) filed on day 4, month 7 in 2009, entitled "U" filed on day 6, month 5 in 2009_PDATABLER_EAL-T_IMEOR N_EARR_EAL-T_IMES_TREAMING"application No.12/479,732 (case No. P7437US 3);

(4) claim of benefit of U.S. provisional patent application No.61/142,110 (case No. P7437Z) filed on 31/12/2008, U.S. provisional patent application No.61/160,693 (case No. P7437Z 2) filed on 16/3/2009, U.S. provisional patent application No.61/161,036 (case No. P7437Z 3) filed on 17/3/2009, U.S. provisional patent application No.61/167,524 (case No. P7437Z 4) filed on 7/4/2009, entitled "P" filed on 5/6/2009_LAYLISTSFOR R_EAL-T_IMEOR N_EARR_EAL-T_IMES_TREAMING"application No.12/479,735 (case No. P7437US 4); and

(5) application No.12/878,002 (case No. P7437X) filed on 9/8/2010, claiming the benefit of U.S. provisional patent application No.61/240,648 (case No. P7437Z 5) filed on 9/8/2009. Application No.12/878,002 (case No. P7437X) is incorporated herein by reference to the extent it is consistent with this application.

Technical Field

Embodiments of the present invention relate to data transmission technology. More particularly, embodiments of the invention relate to techniques for enabling data streaming using non-streaming protocols, such as the hypertext transfer protocol (HTTP).

Background

Streaming of content generally involves multimedia content that is continuously transmitted from a server device and received by a client device. The content is typically presented to the end user at the same time as it is delivered by the streaming server. The name refers to the delivery method of the media, not the media itself.

Current streaming services typically require dedicated servers to distribute "live" content to end users. In any large-scale deployment, this can result in significant costs and requires specialized skills to set up and operate. This results in less content pool available for streaming than desired.

Disclosure of Invention

In one embodiment, a method includes providing a request for a playlist and specifying in the request that the playlist can be compressed, and in response to the request, receiving the playlist in compressed form if the server can provide the playlist in compressed form (otherwise, the playlist may be provided by the server in uncompressed format). The playlist may be compressed (also referred to as encoded) using a compression technique or format (such as deflate or gzip) supported by existing HTTP standard compression techniques. Transmitting and receiving a playlist in a compressed format can significantly reduce the size of data transmitted and received, especially if the playlist increases over time (e.g., if the playlist is for a long baseball game). In one embodiment, the use of compression on the playlist is optional for both the client (the system that requests the playlist) and the server (the system that responds to the request by sending the playlist). The use of compression techniques or formats that are part of the HTTP standard enables any compatible web server to provide a compressed playlist and any compatible client to decompress and use the playlist.

Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.

FIG. 1 is a block diagram of one embodiment of a server and a client capable of sending and receiving content in real-time or near real-time.

FIG. 2A is a flow diagram of one embodiment of a technique for one or more server devices to support media content using a non-streaming protocol.

FIG. 2B is a flow diagram of one embodiment of a technique for one or more server devices to provide a dynamically updated playlist to one or more client devices.

Fig. 2C is a flow diagram of one embodiment of a technique for one or more server devices to provide media content to a client device using multiple bit rates.

FIG. 3A is a flow diagram of one embodiment of a technique for a client device to support streaming of content using a non-streaming protocol.

Fig. 3B is a flow diagram of one embodiment of a technique for a client device to support streaming of content using multiple bit rates.

FIG. 4 is a block diagram of one embodiment of a server stream proxy.

FIG. 5 is a block diagram of one embodiment of a client stream proxy.

FIG. 6 illustrates one embodiment of a playlist file having a plurality of tags.

FIG. 7 is a flow diagram of one embodiment of an assembled stream playback technique described herein.

FIG. 8 is a block diagram of one embodiment of an electronic system.

Fig. 9A is a flow chart illustrating an example of how a client device can switch between alternate content within a variant playlist.

Fig. 9B is a further flow chart showing how a client device can switch between content within two playlists.

Fig. 9C is a further flow diagram illustrating how a client device can switch between content using audio pattern matching.

Fig. 9D illustrates how the method of fig. 9C is implemented using audio pattern matching.

FIG. 10 is a flow diagram of one embodiment of a technique for providing multiple redundant locations for providing media content to a client device using a replacement stream.

FIG. 11 illustrates a network in which a client 1102 uses one or more URLs for bi-directional communication, according to one embodiment.

Detailed Description

Numerous specific details are set forth in the following description. However, embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.

This specification includes copyrighted material such as illustrations of graphical user interface images. Copyright owners, including the assignee of the present invention, thereby reserve their rights in such materials, including copyright rights. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office file or records, but otherwise reserves all rights whatsoever. Copyright ownership-apple Inc 2009 (CopyrightApple Inc.2009.)

In one embodiment, the techniques and components described herein may include mechanisms to deliver streaming experiences using non-streaming protocols (e.g., HTTP) and other techniques (e.g., mobile graphics experts group (MPEG) streaming). For example, a near real-time streaming experience may be provided by broadcasting "live" music or sporting events, live news, Web camera feeds, and the like using HTTP. In one embodiment, the protocol may segment incoming media data into a plurality of media files and store the segmented media files on the server. The protocol may also establish a playlist file that includes Uniform Resource Identifiers (URIs) for directing the client to the segmented media files stored on the server. When playing back a segmented media file according to the playlist(s), the client may provide a near real-time broadcast of "live" events to the user. Pre-recorded content can also be provided in a similar manner.

In one embodiment, the server may dynamically introduce supplemental or alternative media content (e.g., advertisements, statistics related to sporting events, additional media content of the primary presentation) to the broadcast event. For example, during playback of a media event by a client, the server may add an additional URI to the playlist file that may identify a location from which the client can download a supplemental media file. The client may be instructed to periodically retrieve one or more updated playlist files from the server to access any supplemental or additional (or both) media content that has been imported by the server.

In one embodiment, the server may operate in an accumulation mode or a scroll mode. In the accumulation mode, the server may create a playlist file and attach a media file identifier to the end of the playlist file. The client may then access any portion of the stream from the single playlist file at the time of stream download (e.g., the user may start from the middle of the show program). In the scroll mode, the server may limit the availability of the media files by removing the media file identifiers from the beginning of the playlist file based on the scrolling, thereby providing a sliding window of media content accessible to the client device. The server may also add media file identifiers to the playlist, and in the scrolling mode, the server may limit the availability of media files to those media files that were recently added to the playlist. The client then repeatedly downloads an updated copy of the playlist file to continue viewing. The rolling basis for playlist download may be useful when the content is potentially time-unlimited (e.g., content from a continuously operating web camera). The client may continue to repeatedly request the playlist in the scrolling mode until it finds an end tag in the playlist.

In one embodiment, the above mechanism supports bit rate switching by providing variant streams of the same presentation. For example, several versions to be served (serve) for a presentation may be stored on the server. Each version may have substantially the same content but encoded at a different bit rate. This may allow the client device to switch between bit rates depending on, for example, the detection of available bandwidth without compromising playback consistency.

In one embodiment, a protection feature may be provided, thereby preventing unauthorized use of the content. For example, non-sequential media file numbers may be used to prevent prediction. Media file encryption may also be used. Partial media content lists may also be used. Additional and/or different protection features may also be provided.

FIG. 1 is a block diagram of an embodiment of a server and a client capable of sending and receiving real-time or near real-time content. The example of fig. 1 provides a simple server-client connection coupling two clients and a server via a network. Any number of clients may be supported using the techniques and mechanisms described herein. Further, multiple servers may provide content and/or may operate together to provide content in accordance with the techniques and mechanisms described herein. For example, one server may create content, create playlists and create multiple media (e.g., files), while other servers store and transmit the created content.

The network 110 may be any type of network, wired, wireless (e.g., IEEE802.11, 802.16), or any combination thereof. For example, the network 110 may be the Internet or an intranet. As another example, the network 110 may be a cellular network (e.g., 3G, CDMA). In one embodiment, client devices 150 and 180 may have the capability to communicate over multiple network types (e.g., each device may communicate over a WiFi wireless LAN, and may also communicate over a wireless cellular telephone network). For example, clients 150 and 180 may be smart phones or cellular-enabled personal digital assistants capable of communicating via a cellular radiotelephone network as well as a data network. These devices may have the ability to switch between networks via either type of network, even on demand, to take advantage of the streaming mechanisms described herein.

The server 120 may operate as an HTTP server in any manner known in the art. It is the server 120 that includes an HTTP server proxy 145 that provides content using the HTTP protocol. Although the example of fig. 1 is described in connection with HTTP, other protocols may be utilized in a similar manner. The segmenter 130 and indexer 135 are proxies that reside on the server 120 (or servers) to provide content within the media files in conjunction with the playlist files as described herein. These media files and playlist files may be provided over network 110 through HTTP server proxy 145 (or through other servers) using the HTTP protocol. The agents described herein may be implemented by hardware, software, firmware, or a combination thereof.

The segmenter 130 may be used to segment a media data stream into multiple media files that may be transmitted over the HTTP protocol. The indexer 135 can be used to create a playlist file corresponding to the segmented media file so that the client device can reassemble the media file, thereby providing real-time or near real-time transmission of content provided by the server 120. In response to one or more requests from the client device, HTTP server proxy 145 (or other server) may transmit one or more playlist files generated by indexer 135 and media files of content generated by segmenter 130. The server 120 may also include an optional security agent 140 that provides one or more security functions (e.g., encryption) discussed herein. The server 120 may also include additional components not illustrated in fig. 1.

Client devices 150 and 180 may receive playlist files and media files from server 120 via network 110. The client device may be any type of electronic device capable of receiving data transmitted over a network and generating output using the data received over the network, e.g., a wireless mobile device, a PDA, an entertainment device, a consumer electronic device, etc. The output may be of any media type or combination of media types including, for example, audio, video, or any combination thereof.

Client device 150 may include an assembler agent 160 and an output builder agent 165. Similarly, client device 180 may include an assembler agent 190 and an output generator agent 195. Assembler agents 160 and 190 receive the playlist files from server 120 and use these playlist files to access and download media files from server 120. Output generator agents 165 and 195 generate output from client devices 150 and 180, respectively, using the downloaded media files. The output may be provided by one or more speakers, one or more display screens, a combination of speakers and display screens, or any other input or output device. The client device may also include a memory (e.g., flash memory or DRAM, etc.) that functions as a buffer to store media files (e.g., compressed media files or uncompressed media files) as received; the buffer may provide renderable content for many seconds beyond the current rendering content time, thereby enabling the buffered content to be displayed later while new content is being downloaded. The buffer is capable of providing renderable content while the client device is attempting to retrieve content over an intermittently slowed network connection, whereby the buffer is capable of masking network latency or connection problems.

Client devices 150 and 180 may also include optional security agents 170 and 185, respectively, that provide one or more of the security functions discussed herein. Client devices 150 and 180 may also include additional components not illustrated in fig. 1.

In one embodiment, the techniques discussed in this application may be used to transmit an unlimited flow of multimedia data via a non-streaming protocol (e.g., HTTP). Embodiments may also include encryption of media data and/or provision of alternate versions of the stream (e.g., providing alternate bit rates). Since media data can be transmitted soon after creation, the data can be received in near real time. Providing an exemplary file data format and actions to be taken by a server (sender) and a client (receiver) of a multimedia data stream; however, other formats can also be supported.

A media presentation that can be delivered as an emulated real-time stream (or near real-time stream) is specified by a Uniform Resource Indicator (URI) that indicates a playlist file. In one embodiment, the playlist file is an ordered list of attached URIs. Each URI in a playlist file refers to a media file that is a stream segment, which may be a single continuous stream of media data for a particular program.

To play the media data stream, the client device retrieves a playlist file from the server. The client also retrieves and plays each media data file indicated by the playlist file. In one embodiment, the client may dynamically or repeatedly reload the playlist file for additional and/or different media segments.

The playlist file may be, for example, an extended M3U playlist file. In one embodiment, additional tags are used that effectively extend the M3U format. M3U refers to a mobile graphic experts group audio layer 3 uniform resource locator (MP 3 URL) and is a format for storing multimedia playlists. The M3U file is a text file that contains the location of one or more media files for play by the media player.

In one embodiment, the playlist file is a text file in extended M3U format that is made up of individual lines. A line may be terminated by a single LF character or by a CR character following the LF character. Each line may be a URI, a blank line, or start with an annotation character (e.g., "#"). The URI identifies the media file to be played. The empty row may be ignored.

The line starting with the annotation character may be an annotation or a tag. The tag may begin with # EXT and the annotation line may begin with #. Annotation lines are typically ignored by the server and client. In one embodiment, the playlist file is encoded in UTF-8 format. UTF-8 (8-bit unicode transform format) is a variable length character encoding format. In alternative embodiments, other character encoding formats may be used.

In the following example, the extended M3U format is utilized, which includes two tags EXTM3U and EXTINF. The extension M3U file may be distinguished from the base M3U file by the first line including "# EXTM 3U".

Extlnf is a record label that describes the media file identified by the URI that follows the tag. In one embodiment, an EXTINF tag is added before each media file URI, such as:

# EXTINF: < duration >, < title >

Where "duration" specifies the duration of the media file and "title" is the title of the target media file.

In one embodiment, the following tags may be used to manage the transfer and playback of media files:

EXT-X-TARGETDURATION

EXT-X-MEDIA-SEQUENCE

EXT-X-KEY

EXT-X-PROGRAM-DATE-TIME

EXT-X-ALLOW-CACHE

EXT-X-STREAM-INF

EXT-X-ENDLIST

each of these tags will be described in detail below. Although specific formats and attributes will be described in relation to each new tag, alternative embodiments may utilize different attribute, name, format, etc. support.

The EXT-X-TARGETDURATION tag can indicate the approximate duration of the next media file to be added to the presentation. It may be included within the playback file and the format may be:

# EXT-X-TARGETDURATION: < sec >

Where "seconds" indicates the duration of the media file. In one embodiment, the actual duration may be slightly different from the target duration indicated by the tag. In one embodiment, each URI that indicates a segment will be associated with an approximate duration of the segment; for example, a URI for a segment may be prefixed with a label that indicates the approximate duration of the segment.

Each media file URI in the playlist file may have a unique sequence number. In one embodiment, the sequence number of the URI (if present) is equal to the sequence number of the URI before it plus 1. The EXT-X-MEDIA-SEQUENCE tag may indicate the SEQUENCE number of the first URI that appears within the playlist file and may be in the format:

# EXT-X-MEDIA-SEQUENCE: < number >

Where the "number" is the serial number of the URI. If the playlist file does not include the # EXT-X-MEDIA-SEQUENCE tag, the SEQUENCE number of the first URI in the playlist may be considered to be 1. In one embodiment, the sequence numbers may not be sequential; for example, non-sequential sequence numbering such as 1, 5, 7, 17, etc. can make it difficult to predict the next number in the sequence, which can help protect content from hacking. Another option for helping to protect content is to present only a portion of the playlist at any given time.

Some media files may be encrypted. The EXT-X-KEY tag provides information that can be used to decrypt a media file that follows, and may be in the format:

METHOD = < METHOD > [, URI = "< URI > ]EXT-X-KEY

The METHOD parameter specifies the encryption METHOD, while the URI parameter (if present) specifies how the key is obtained.

The encryption method NONE indicates no encryption. Various Encryption methods may be used, such as AES-128, which indicates Encryption using advanced Encryption Standard (advanced Encryption Standard) Encryption with 128-bit keys and PKCS7 padding [ see RFC3852 ]. The new EXT-X-KEY tag replaces any previous EXT-X-KEY tag.

The EXT-X-KEY tag with the URI parameters identifies the KEY file. The key file may contain cryptographic keys to be used to decrypt subsequent media files listed in the playlist file. For example, the AES-128 encryption method uses a 16-octet key. The format of the key file may be a 16 octet packed array (packed array) in binary format.

The use of AES-128 generally requires the same 16-octet Initialization Vector (IV) to be supplied in both encryption and decryption. The variation IV can be used to increase the strength of the cipher. When using AES-128 encryption, the media file's sequence number may be used as the IV when encrypting or decrypting the media file.

The EXT-X-PROGRAM-DATE-TIME tag may associate the start of the next media file with an absolute DATE and/or TIME, and can include or indicate a TIME zone. In one embodiment, the date/time representation is ISO/IEC8601: 2004. The tag format may be:

EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ss Z>

the EXT-X-ALLOW-CACHE tag may be used to indicate whether the client may CACHE the downloaded media file for subsequent playback. The tag format may be:

EXT-X-ALLOW-CACHE:<YES|NO>

the EXT-X-ENDLIST tag indicates that in one embodiment, there are no more media files to be added to the playlist file. The tag format may be:

EXT-X-ENDLIST

in one embodiment, if the playlist contains the last segment or media file, the playlist will have an EXT-X-ENDLIST tag.

The EXT-X-STREAM-INF tag may be used to indicate that the next URI in a playlist file identifies another playlist file. In one embodiment, the tag format may be:

EXT-X-STREAM-INF: [ Attribute = value ] [, Attribute = value ] < URI >

Wherein the following properties may be used. The attribute BANDWIDTH = < n > is an approximate upper limit of the stream bit rate expressed as number of bits per second. The attribute PROGRAM-ID = < i > is a number that uniquely identifies a specific presentation within the range of the playlist file. The playlist file may include multiple EXT-X-STREAM-INF URIs with the same PROGRAM-ID to describe variant STREAMs of the same presentation. Variant streams and variant playlists are further described in this disclosure (e.g., see fig. 9A-9D).

The foregoing tags and attributes may be used by the server device to organize, transmit, and process media files representing original media content. The client device uses this information to reassemble and present the media files in a manner that provides a real-time or near real-time streaming experience (e.g., viewing a live broadcast such as music or a sporting event) to the user of the client device.

Each media file URI of a playlist file identifies the media file as a segment of the original presentation (i.e., the original media content). In one embodiment, each media file is formatted as an MPEG-2 transport stream, an MPEG-2 program stream, or an MPEG-2 audio element stream. The format may be specified by a specified CODEC, and the playlist may specify the format by the specified CODEC. In one embodiment, all media files in the presentation may have the same format; however, multiple formats may be supported in other embodiments. In one embodiment, the transport stream file should contain a single MPEG-2 program, and there should be a program association table and a program map table at the beginning of each file. The file containing the video should have at least one key frame and enough information to fully initialize the video decoder. The client should be ready to process multiple tracks of a particular type (e.g., audio or video) by selecting a reasonable subset. In one embodiment, the client should ignore private streams within the transport stream that it cannot recognize. Sample encoding parameters within a stream within a media file and between corresponding streams across multiple media files should remain consistent. However, the client should handle coding changes when they are encountered, for example by scaling (scale) the video content to accommodate the resolution change.

FIG. 2A is a flow diagram of one embodiment of a technique for one or more server devices to support media content using a non-streaming protocol. The example of FIG. 2A is provided with reference to HTTP; however, other non-streaming protocols may be utilized in a similar manner. The example of FIG. 2A is provided with reference to a single server performing a particular task. However, any number of servers may be utilized. For example, a server that provides media files to client devices may be a different device than a server that segments content into multiple media files.

In operation 200, a server device receives content to be provided. The content may represent live audio and/or video (e.g., sporting events, live news, Web camera feeds). The content may also represent pre-recorded content (e.g., a concert that has been recorded, a training workshop, etc.). Whether streamed or not, the content may be received by the server according to any format and protocol known in the art. In one embodiment, the content is received by the server in the form of an MPEG-2 stream; however, other formats can be supported as well.

The server may then temporarily store at least a portion of the content at operation 210. The content or at least a portion of the content may be temporarily stored, for example, on a storage device (e.g., a hard disk within a storage area network, etc.) or within a memory. Alternatively, the content may be received via a storage medium (e.g., compact disk, flash drive), and the content may be transferred from the storage medium to a storage device or memory. In one embodiment, the server has an encoder that converts the content into one or more streams (e.g., MPEG-2) when needed. This conversion may occur without persistent storage of the received content, and in some embodiments, the storage operation 210 may be omitted or in other embodiments may be longer term storage (e.g., archival storage).

In operation 220, content to be provided is segmented into a plurality of media files. In one embodiment, the server converts the stream into separate and distinct media files (i.e., segments) that can be distributed using a standard web server. In one embodiment, the server segments the media stream at points that support efficient decoding of individual media files (e.g., on packet and key frame boundaries such as PES packet boundaries and i-frame boundaries). The media files may be portions of the original stream having approximately equal durations. The server also creates a URI for each media file. These URIs allow a client device to access media files.

Because the segments are served using an HTTP server that inherently delivers the full file, the server should make the full segmented media file available before the media file can be served to the client. The client may then delay the broadcast (in time) by at least one media file length. In one embodiment, the size of the media file is based on a balance between latency and having too many files.

In one embodiment, two session types (live session and event session) are supported. For live sessions, only the fixed-size portion of the stream is reserved. In one embodiment, expired content media files are removed from the program playlist file and may be removed from the server. The second type of session is an event session in which the client can tune to an arbitrary point of the broadcast (e.g., start from the beginning, start from an intermediate point). Such sessions may be used for re-broadcasting, for example.

At operation 230, the media file is stored in the server memory. The media file may be protected by a security feature such as encryption before the file is stored in operation 230. The media files are stored as files ready for transfer using a network protocol (e.g., HTTP or HTTPs) supported by a Web server application on the server device (or supported by another device that is transferring).

At operation 240, one or more playlist files are generated to indicate the order in which the media files should be assembled to reconstruct the original content. The playlist file(s) can utilize the extension M3U tags and the tags described herein to provide information for the client device to access and reassemble media files to provide a streaming experience on the client device. The URI for each media file is included within the playlist file(s) in the order in which the media files are to be played. The server may also create one or more URIs for the playlist file(s) to allow the client device to access the playlist file(s).

At operation 250, the playlist file(s) may be stored on the server. Although the creation and storage of the media file and playlist file(s) is presented in a particular order in fig. 2A, a different order may be used. For example, the playlist file(s) may be created prior to media file creation or storage. As another example, the playlist file(s) and media files may be created before either is stored.

If the media file is to be encrypted, the playlist file(s) may define a URI that allows an authorized client device to obtain a key file containing an encryption key for decrypting the media file. The encryption key may be transmitted using a secure connection (e.g., HTTPS). As another example, the playlist file(s) may be transferred using HTTPS. As another example, the media files may be arranged in an unpredictable order such that the client cannot recreate the stream without the playlist file(s).

If the encryption method is AES-128, AES-128CBC encryption may be applied to the individual media files, for example. In one embodiment, the entire file is encrypted. In one embodiment, the cipher block links are not typically applied across media files. The sequence of media files is used as an IV as described above. In one embodiment, the server adds the EXT-X-KEY tag with the KEY URI to the end of the playlist file. The server then encrypts all subsequent media files using the key until the encryption configuration is changed.

To switch to a new encryption key, the server may make the new key available through a new URI that is different from all previous key URIs used in the rendering. The server also adds the EXT-X-KEY tag with the new KEY URI to the end of the playlist file and encrypts all subsequent media files using the new KEY.

To end the encryption, the server may add an EXT-X-KEY tag with encryption method NONE to the end of the playlist file. This label (with "NONE" as a method) does not include the URI parameter in one embodiment. All subsequent media files are not encrypted until the encryption configuration changes as described above. If the playlist file contains a URI for the media file encrypted with the KEY, the server does not remove the EXT-X-KEY tag from the playlist file. At operation 270, the server may transmit the playlist file(s) and media files over the network in response to a client request, as will be described in more detail below with reference to FIG. 3A.

In one embodiment, the server transmits the playlist file to the client device in response to a request for the playlist file received from the client device. The client device may access/request the playlist file using the URI that has been provided to the client device. The URI indicates the location of the playlist file on the server. In response, the server may provide the playlist file to the client device. The client device may utilize the tags and URIs (or other identifiers) in the playlist file to access the plurality of media files.

In one embodiment, the server may limit the availability of media files to those media files that have been recently added to the playlist file(s). To this end, each playlist file may include only one EXT-X-MEDIA-SEQUENCE tag, and this value may be incremented by 1 for each MEDIA file URI removed from the playlist file. The media file URIs may be removed from the playlist file(s) in the order in which they were added. In one embodiment, when the server removes the media file URI from the playlist file(s), the media file remains available to the client for a period of time equal to the duration of the media file plus the duration of the longest playlist file in which the media file has appeared.

The duration of a playlist file is the sum of the durations of the media files within the playlist file. Other durations may also be used. In one embodiment, unless the EXT-X-ENDLIST tag is present, the server may maintain at least three primary presentation media files in the playlist at all times.

FIG. 2B is a flow diagram of one embodiment of a technique for one or more server devices to provide a dynamically updated playlist to one or more client devices. The playlist may be updated using the accumulation mode or the scroll mode described herein. The example of FIG. 2B is provided with reference to HTTP; however, other non-streaming protocols (e.g., HTTPS, etc.) may also be utilized in a similar manner. The example of FIG. 2B is provided with reference to a server performing a particular task. However, any number of servers may be utilized. For example, a server that provides media files to client devices may be a different device than a server that segments content into multiple media files.

In operation 205, the server device receives content to be provided. The server may then temporarily store at least a portion of the content at operation 215. Operation 215 may be similar to operation 210 in fig. 2A. In operation 225, content to be provided is segmented into a plurality of media files. At operation 235, the media file may be stored in server memory. The media file may be protected by a security feature such as encryption before the file is stored in operation 235.

At operation 245, one or more playlist files are generated to indicate the order in which the media files should be assembled to recreate the original content. At operation 255, the playlist file(s) may be stored on the server. Although the creation and storage of the media file and playlist file(s) is presented in a particular order in fig. 2B, a different order may be used.

At operation 275, the server (or another server) may transmit the playlist file(s) and media files over the network in response to a client request, as will be described in more detail below with reference to FIGS. 3A-3B.

The playlist file(s) may be updated by the server for various reasons. At operation 285, the server may receive additional data to be provided to the client device. The additional data may be received after storing the playlist file(s) at operation 255. The additional data may be, for example, additional parts of a live presentation, or additional information of an existing presentation. The additional data may include advertising or statistical information (e.g., scores or data related to sporting events). The additional data may be overlaid (through translucency) on the presentation or may be presented within the sidebar user interface. The additional data can be segmented in the same way as the originally received data. If the additional data constitutes an advertisement or other content to be inserted into the program represented by the playlist, the additional data may be stored (at least temporarily) at operation 215, segmented at operation 225, and stored at operation 235; each segment of the additional data may be encrypted before storing the additional data of the segment. An updated playlist containing the program and additional data may then be generated at operation 245. The playlist is updated based on the additional data and is stored again in operation 255. Changes to the playlist file(s) should be made atomically from the perspective of the client device. In one embodiment, the updated playlist replaces the previous playlist. As will be discussed in more detail below, the client device may request the playlist multiple times. These requests enable the client device to utilize the most recent playlist. In one embodiment, the additional data may be metadata; in this case, the playlist need not be updated, but the segments can be updated to include the metadata. For example, the metadata may contain timestamps that can be matched to timestamps within the segments, and the metadata may be added to the segments having the matching timestamps.

The updated playlist may also result in the removal of the media files. In one embodiment, the server should remove the URIs for the media files from the playlist in the order in which they were added to the playlist. In one embodiment, if the server removes the entire presentation, the playlist file(s) are made unavailable to the client device. In one embodiment, the server maintains the media file and playlist file(s) for the duration of the longest playlist file(s) containing the media files to be removed, thereby allowing the current client device to complete access to the presentation. Thus, each media file URI within a playlist file may be prefixed with an EXT-X-STREAM-INF tag to indicate the approximate cumulative duration of the media file indicated by the playlist file. In an alternative embodiment, the media file and playlist file(s) may be removed immediately.

At operation 275, a subsequent request for a playlist from the client device causes the server to provide an updated playlist. In one embodiment, the playlist is updated regularly, for example, for a period of time related to the target duration. Periodic updating of the playlist file allows the server to provide the server with access to dynamically changing presentations.

Fig. 2C is a flow diagram of one embodiment of a technique for one or more server devices to provide media content to a client device using multiple bit rates (as one form of using alternate streams). The example of FIG. 2C is provided with reference to HTTP; however, other non-streaming protocols may be utilized in a similar manner. The example of FIG. 2C is provided with reference to a server performing a particular task. However, any number of servers may be utilized. For example, a server that provides media files to client devices may be a different device than a server that segments content into multiple media files.

In one embodiment, the server may provide multiple playlist files, or a single playlist file with multiple media file lists within a single playlist file, thereby providing different encodings of the same presentation. If different encodings are provided, the playlist file(s) may include each variant stream that provides a different bitrate, thereby allowing the client device to dynamically switch between encodings (as will be further described in conjunction with FIGS. 9A-9D). The playlist file with variant STREAMs may include an EXT-X-STREAM-INF tag for each variant STREAM. Each EXT-X-STREAM-INF tag used for the same presentation may have the same PROGRAM-ID attribute value. The PROGRAM-ID value for each presentation is unique within these variant streams.

In one embodiment, the server complies with the following constraints when generating variant streams. Each variant stream may be composed of identical content including alternative content that is not part of the main presentation. The server may make the same time period of content available for all variant streams within the accuracy of the minimum target duration of the stream. The media files of the variant streams are in one embodiment MPEG-2 transport streams or MPEG-2 program streams with sample timestamps that match the corresponding content in all variant streams. Likewise, all variant streams should contain the same audio coding in one embodiment. This allows the client device to switch between variant streams without losing content.

Referring to fig. 2C, in operation 202, a server apparatus receives content to be provided. The server may then at least temporarily store the content at operation 212. In operation 222, content to be provided is segmented into a plurality of media files. At operation 232, each media file is encoded at a selected bit rate (or selected value of other encoding parameter) and stored on the server. For example, media files may target high, medium, and low bandwidth connections. The media file may be encrypted prior to storage. The encoding of the media file targeting various types of connections may be selected to provide a streaming experience at a target bandwidth level.

In one embodiment, variant playlists having tags indicating various encoding levels described herein are generated at operation 242. The tags may include, for example, an EXT-X-STREAM-INF tag for each encoding level with a URI for the corresponding media playlist file.

This variant playlist may include URIs for the media playlist files for various encoding levels. The client device may then select a target bit rate from the alternatives provided in the variant playlist indicating the encoding level and retrieve the corresponding playlist file. In one embodiment, the client device may switch between bit rates during playback (e.g., as described with reference to fig. 9A-9D). At operation 252, variant playlists indicating the various encoding levels are stored on the server. In operation 242, each playlist referenced in the variant playlist may be generated and subsequently stored in operation 252.

At operation 272, the server may transmit variant playlists indicating various encoding levels in response to a request from a client device. At operation 282, the server may receive a request for one of the media playlists specified in the variant playlist that corresponds to the selected bitrate. In operation 292, in response to the request, the server transmits a media playlist file corresponding to the request from the client device. The client device may then use the media playlist to request a media file from the server. At operation 297, the server provides the media file to the client device in response to the request.

FIG. 3A is a flow diagram of one embodiment of a technique for a client device to support streaming of content using a non-streaming protocol. The example of FIG. 3A is provided with reference to HTTP; however, other non-streaming protocols may be utilized in a similar manner. The method illustrated in fig. 3A-3B may be performed by one client device or by several separate client devices. For example, in the case of any of these methods, a single client device may perform all of the operations (e.g., request a playlist file, request a media file using a URI within the playlist file, assemble the media file to generate and provide a presentation/output), or several different client devices may perform some, but not all, of the operations (e.g., a first client device may request a playlist file, request a media file using a URI within the playlist file, and be able to store the media files for use by a second client device that is able to process the media files to generate and provide a presentation/output).

In operation 300, a client device may request a playlist file from a server. In one embodiment, the request is made according to a protocol that conforms to HTTP. The request utilizes a URI for the initial playlist file stored on the server. In alternative embodiments, other non-streaming protocols may also be supported. In response to the request, the server transmits the corresponding playlist file to the client via the network. As discussed above, the network may be wired or wireless, and may be any combination of wired or wireless networks. Further, the network may be a data network (e.g., IEEE802.11, IEEE 802.16) or a cellular telephone network (e.g., 3G).

At operation 310, the client device may receive a playlist file. At operation 320, the playlist file may be stored in a memory of the client device. The memory may be, for example, a hard disk, flash memory, random access memory. In one embodiment, each time a playlist file is loaded or reloaded from a playlist URI, the client checks to determine if the playlist file begins with the # EXTM3U tag and does not continue if the tag is not present. As discussed above, a playlist file includes one or more tags and one or more URIs for media files.

The client device may include an assembler agent that reassembles the original content using the playlist file by requesting the media file indicated by the URI in the playlist file at operation 330. In one embodiment, the assembler agent is a plug-in module that is part of a standard Web browser application. In another embodiment, the assembler agent may be a standalone application that interacts with the Web browser to receive media files and assemble the media files using the playlist file(s). As another example, the assembler agent may be a dedicated hardware or firmware component embedded within the client device.

The populator causes a download from the server of the media file indicated by the URI in the playlist file. If the playlist file includes an EXT-X-ENDLIST tag, any media files indicated by the playlist file may be played first. If the EXT-X-ENDLIST tag does not exist, any media files other than the first to last and second to last media files may be played first. Once the first media file to play is selected, subsequent media files within the playlist file are loaded, in one embodiment, in the order in which the media files appear in the playlist file (otherwise the content presented would be out of order). In one embodiment, the client device attempts to load these media files (and store them in a buffer) before they are needed to provide uninterrupted playback and to compensate for temporary changes in network latency and throughput.

At operation 340, the downloaded media file(s) may be stored in memory on the client device. The memory in which content can be stored may be any type of memory on the client device, such as random access memory, a hard disk, or a video buffer. The storage may be temporary storage that allows playback, or permanent storage. If the playlist file contains an EXT-X-ALLOW-CACHE tag and its value is NO, the client does not store the downloaded media files after they are played. If the playlist file contains an EXT-X-ALLOW-CACHE tag and its value is YES, the client may store the media file indefinitely for subsequent playback. The client device may use the value of the EXT-X-PROGRAM-DATE-TIME tag to display the TIME of PROGRAM origination to the user. In one embodiment, the client may buffer multiple media files to make them less sensitive to network jitter to provide a better user experience.

In one embodiment, if the decryption method is AES-128, AES-128CBC decryption is applied to each individual media file. The entire file is decrypted. In one embodiment, the cipher block links are not applied across media files. The sequence number of the media file may be used as an initialization vector as described above.

From the memory, the content may be output from the client device at operation 350. The output or presentation may be, for example, an audio output via a built-in speaker or a headset. The output may include video output via a screen or projected from a client device. Any type of output known in the art may be utilized. At operation 351, the client device determines whether there are any other media files in the stored current playlist that have not yet been played or otherwise rendered. If such media files are present (and if they have not been requested), processing returns to operation 330 where one or more media files are requested and the process repeats. If no such media file exists (i.e., all of the media files in the current playlist have been played), then processing proceeds to operation 352 where a determination is made as to whether the playlist file includes an end tag.

If the playlist includes an end tag (e.g., EXT-X-ENDLIST) at operation 352, playback is stopped when the media file indicated by the playlist file has been played. If there is no end tag in the playlist, the client device again requests the playlist from the server and returns to operation 300 to obtain a further or updated playlist for the program.

As discussed in further detail with reference to fig. 2B, the server may update the playlist file to introduce supplemental content (e.g., an additional media file identifier corresponding to the additional media content in a live broadcast) or additional content (e.g., content further downstream of the stream). To access the supplemental or additional content, the client may reload the updated playlist from the server. This can provide a mechanism by which the playlist file can be dynamically updated, even during playback of media content associated with the playlist file. The client may request reloading of the playlist file based on multiple triggers. The absence of an end tag is one such trigger.

In one embodiment, the client device periodically reloads the playlist file(s) unless the playlist file contains an EXT-X-ENDLIST tag. When the client device loads the playlist file for the first time, or reloads the playlist file and finds that the playlist file has changed since the last load, the client may wait for a period of time before attempting to reload the playlist file again. This time period is referred to as the initial minimum reload delay. This is measured from the moment the client starts loading the playlist file.

In one embodiment, the initial minimum reload delay is the shorter of the duration of the last media file in the playlist file and three times the target duration. The media file duration is specified by the extlnf tag. If the client reloads the playlist file and finds that it has not changed, the client may wait a period of time before retrying. The minimum delay is, in one embodiment, the shorter of three times the target duration and a multiple of the initial minimum reload delay. In one embodiment, this multiple is 0.5 for the first attempt, 1.5 for the second attempt, and 3.0 for the third attempt; however, other multiples may be used.

Each time a playlist file is loaded or reloaded, the client device examines the playlist file to determine the next media file to load. The first file to be loaded is the media file selected to play first as described above. If the first MEDIA file to be played has been loaded and the playlist file does not contain an EXT-X-MEDIA-SEQUENCE tag, the client can verify that the current playlist file contains the URI of the last-loaded MEDIA file at the offset where the last-loaded MEDIA file was originally found, and terminate playback if the file is not found. The next media file to be loaded may be the first media file URI in the playlist file following the last URI loaded.

If the first to-be-played file has been loaded and the playlist file contains an EXT-X-MEDIA-SEQUENCE tag, the next to-be-loaded MEDIA file may be the MEDIA file with the smallest SEQUENCE number that is greater than the SEQUENCE number of the last loaded MEDIA file. If the playlist file contains an EXT-X-KEY tag that specifies the URI of the KEY file, the client device obtains the KEY file and uses the KEYs in the KEY file to decrypt the media file following the EXT-X-KEY tag until another EXT-X-KEY tag is encountered.

In one embodiment, the client device downloads the playlist file using the same URI as the URI used previously. Thus, if changes have been made to the playlist file, the client device may retrieve media files using the updated playlist file and provide output based on the media files.

Changes to the playlist file may include, for example, deleting URIs for media files, adding URIs for new media files, and replacing URIs for replacement media files. When changes are made to the playlist file, one or more tags may be updated to reflect the change(s). For example, if a change to a media file results in a change in the playback duration of the media file indicated by the playlist file, the duration tag may be updated.

Fig. 3B is a flow diagram of one embodiment of a technique for streaming of multiple bit rate support content (as one form of a substitution stream) for a client device. The example of FIG. 3B is provided with reference to HTTP; however, other non-streaming protocols may be utilized in a similar manner.

At operation 370, the client device may request a playlist file. As discussed above, the playlist file may be retrieved using a URI provided to the client device. In one embodiment, the playlist file includes a list of variant streams of the media file, thereby providing the same content at different bit rates; in other words, a single playlist file includes URIs of media files for each of a plurality of variant streams. The example shown in fig. 3B uses this embodiment. In another embodiment, the variant stream may be represented by a plurality of different playlist files, each providing the same content at a different bit rate, that are provided separately to the client, and the variant playlist may provide a URI for each of the plurality of different playlist files. This enables the client device to select a bit rate based on the client conditions.

At operation 375, the playlist file(s) may be retrieved by the client device. At operation 380, the playlist file(s) may be stored in the client device memory. At operation 385, the client device may select a bit rate to be used based on the current network connection speed. In operation 390, a media file from the server is requested using a URI corresponding to the selected bit rate included in the playlist file. The retrieved media files may be stored in the client device memory. At operation 394, the output is provided by the client device using the media file, and the client device determines whether to change the bit rate.

In one embodiment, the client device initially selects the lowest available bit rate. While playing media, the client device may monitor the available bandwidth (e.g., current network connection bit rate) to determine whether the available bandwidth can support the use of a higher bit rate for playback. If so, the client device may select a higher bitrate and access the media files indicated by the higher bitrate media playlist file. The opposite may also be supported. If playback consumes too much bandwidth, the client device may select a lower bitrate and access the media file indicated by the lower bitrate media playlist file.

If the client device has changed bit rate, for example, in response to a change in available bandwidth or in response to user input in operation 394, the client device may select a different bit rate in operation 385. In one embodiment, to select a different bit rate, the client device may utilize a different URI list included in the playlist file that corresponds to the newly selected bit rate. In one embodiment, the client device may change the bit rate during access to the media files within the playlist.

If the bit rate has not changed at operation 394, the client device determines if any other media files in the current playlist that have not been played have not been retrieved and presented. If such media files exist, processing returns to operation 390 and one or more media files are retrieved using the URIs for those files in the playlist. If no such media files exist (i.e., all of the media files in the current playlist have been played), then processing proceeds to operation 396 where it is determined whether the playlist includes an end tag. If yes, ending the playback of the program and completing the processing; if not, the process returns to operation 370 and the client device requests that the playlist for the program be reloaded and the process repeats through the method illustrated in FIG. 3B.

FIG. 4 is a block diagram of one embodiment of a server stream proxy. It will be understood that the elements of the server streaming proxy 400 may be distributed across several server devices. For example, a first server device may include segmenter 430, indexer 440, and security agent 450, but not file server 460, and a second server may include file server 460, but not segmenter 430, indexer 440, and security agent 450. In this example, the first server device will prepare the playlist and media files, but will not transmit them to the client device, while the one or more second server devices will receive and optionally store the playlist and media files, and will transmit them to the client device. The server flow proxy 400 includes control logic 410 that implements logical function control to direct the operation of the server flow proxy 400, as well as hardware associated with directing the operation of the server flow proxy 400. Logic may be hardware logic circuits, or software routines or firmware. In one embodiment, server flow proxy 400 includes one or more applications 412, applications 412 representing code sequences and/or programs that provide instructions to control logic 410.

The server flow proxy 400 includes a memory 414, the memory 414 representing a memory device or access to memory resources that store data or instructions. The memory 414 may include memory local to the server streaming proxy 400, and may additionally or alternatively include memory of the host system on which the server streaming proxy 400 resides. The server flow proxy 400 also includes one or more interfaces 416, the interfaces 416 representing access interfaces (input/output interfaces) that the server flow proxy 400 sends/receives with respect to (electronic or human) entities external to the server flow proxy 400.

The server streaming proxy 400 may also include a server streaming engine 420, the server streaming engine 420 representing one or more functions that enable the server streaming proxy 400 to provide real-time or near real-time streaming as described herein. The example of FIG. 4 provides several components that may be included within the server flow engine 420; however, different or additional components may be included. Exemplary components that may be involved in providing a streaming environment include segmenter 430, indexer 440, security agent 450, and file server 460. Each of these components may further include other components that provide other functionality. As used herein, a component refers to a routine, subsystem, etc., that may be implemented by hardware, software, firmware, or some combination thereof.

Segmenter 430 segments the content to be provided into media files that may be transferred as files using a Web server protocol (e.g., HTTP). For example, the segmenter 430 may segment the content into predetermined, fixed-size data blocks in a predetermined file format.

The indexer 440 may provide one or more playlist files that provide addresses or URIs for the media files created by the segmenter 430. Indexer 440 may, for example, create one or more files with an ordered list of identifiers corresponding to each file created by segmenter 430. The identifier may be created or assigned by the segmenter 430 or the indexer 440. The indexer 440 may also include one or more tags in the playlist file to support access to and/or utilization of the media files.

Security agent 450 may provide security features such as those discussed above (e.g., encryption). Web server 460 may provide Web server functionality related to providing files stored on a host system to a remote client device. Web server 460 may support, for example, a protocol that conforms to HTTP.

FIG. 5 is a block diagram of one embodiment of a client stream proxy. It will be understood that the elements of the client streaming proxy may be distributed across several client devices. For example, a first client device may include assembler 530 and security agent 550 and may provide the decrypted media file stream to a second client device that includes output generator 540 (but not assembler 530 and security agent 550). In another example, the primary client device may retrieve a playlist and provide them to the secondary client device, which then retrieves the media files specified in the playlist and generates output for rendering the media files. The client flow proxy 500 includes control logic 510 that implements logical function control to direct the operation of the client flow proxy 500, as well as hardware associated with directing the operation of the client flow proxy 500. Logic may be hardware logic circuits, or software routines or firmware. In one embodiment, the client flow proxy 500 includes application(s) 512, which represent a code sequence or program that provides instructions to the control logic 510.

The client streaming proxy 500 includes a memory 514 that represents a memory device or access to memory resources for storing data and/or instructions. The memory 514 may include memory local to the client streaming proxy 500 and may additionally or alternatively include memory of the host system on which the client streaming proxy 500 resides. The client streaming proxy 500 also includes one or more interfaces 516 that represent access interfaces (input/output interfaces) that the client streaming proxy 500 sends/receives with respect to (electronic or human) entities external to the client streaming proxy 500.

The client streaming proxy 500 may also include a client streaming engine 520 that represents one or more functions that enable the client streaming proxy 500 to provide real-time or near real-time streaming as described herein. The example of FIG. 5 provides several components that may be included within the client flow engine 520; however, different or additional components may be included. Exemplary components that may be involved in providing a streaming environment include assembler 530, output builder 540, and security agent 550. Each of these components may further include other components that provide other functionality. As used herein, a component refers to a routine, subsystem, etc., that may be implemented by hardware, software, firmware, or some combination thereof.

Assembler 530 may utilize the playlist file received from the server to access the media files from the server via a Web server protocol (e.g., HTTP). In one embodiment, populator 530 may cause the downloading of the media file as indicated by the URI in the playlist file. Assembler 530 may be responsive to tags included within the playlist file.

Output generator 540 may provide the received media file as audio or video output (or both audio and video) on the host system. Output generator 540 may, for example, cause audio to be output to one or more speakers and cause video to be output to a display device. Security agent 550 may provide security features such as those discussed above.

FIG. 6 illustrates one embodiment of a playlist file having a plurality of tags. The exemplary playlist of fig. 6 includes a particular number and order of tabs. This is provided for descriptive purposes only. Some playlist files may include more, fewer, or different combinations of tabs, and the tabs may be arranged in a different order than shown in fig. 6.

The start tag 610 may indicate the start of the playlist file. In one embodiment, the start tag 610 is a # EXTM3U tag. The duration tab 620 may indicate the duration of the playback list. I.e., the playback duration of the media files indicated by the playback list 600. In one embodiment, the duration tag 620 is an EXT-X-TARGETDURATION tag; however, other labels may be used.

The date/time tag 625 may provide information related to the date and time of content provided by the media files indicated by the playback list 600. In one embodiment, the DATE/TIME tag 625 is an EXT-X-PROGRAM-DATE-TIME tag; however, other labels may be used. The sequence tag 630 may indicate the order of the playlist file 600 in the playlist sequence. In one embodiment, the SEQUENCE tag 630 is an EXT-X-MEDIA-SEQUENCE tag; however, other labels may be used.

The security tag 640 may provide information related to security and/or encryption applied to the media files indicated by the playlist file 600. For example, security tag 640 may specify a decryption key to decrypt the file specified by the media file indicator. In one embodiment, security tag 640 is an EXT-X-KEY tag; however, other labels may be used. Variant list tag 645 may indicate whether variant streams are provided by playlist 600 and the information (e.g., how much, bit rate) associated with those variant streams. In one embodiment, variant list tab 645 is an EXT-X-STREAM-INF tab.

The media file indicator 650 may provide information related to the media file to be played. In one embodiment, the media file indicator 650 includes URIs for a plurality of media files to be played. In one embodiment, the order of the URIs in the playlist 600 corresponds to the order in which the media files should be accessed and/or played. The subsequent playlist indicator 660 may provide information related to one or more playback files to be used after the playback file 600. In one embodiment, the subsequent playlist indicator 660 may include URIs for one or more playlist files to be used after the media files of the playlist 600 have been played.

Memory tag 670 can indicate whether and/or how long the client device can store the media file after playback of the media file content. In one embodiment, memory tag 670 is an EXT-X-ALLOW-CACHE tag. The end tag 680 indicates whether the playlist file 600 is the last playlist file for presentation. In one embodiment, end tag 680 is an EXT-X-ENDLIST tag.

The lower section includes several exemplary playlist files according to one embodiment.

Simple playlist file

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST

_______________________________________________

Sliding window playlist using HTTPS

#EXTM3U

#EXT-X-TARGETDURATION:8

#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:8,

https://priv.example.com/fileSequence2680.ts

#EXTINF:8,

https://priv.example.com/fileSequence2681.ts

#EXTINF:8,

https://priv.example.com/fileSequence2682.ts

________________________________________________

Playlist files with encrypted media files

#EXTM3U

#EXT-X-MEDIA-SEQUENCE:7794

#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-128,URI="

https://priv.example.com/key.php?r=52"

#EXTINF:15,

http://media.example.com/fileSequence7794.ts

#EXTINF:15,

http://media.example.com/fileSequence7795.ts

#EXTINF:15,

http://media.example.com/fileSequence7796.ts

#EXT-X-KEY:METHOD=AES-128,URI="

https://priv.example.com/key.php?r=53"

#EXTINF:15,

http://media.example.com/fileSequence7797.ts

________________________________________________

Variant playlist file

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000

http://example.com/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example.com/mid.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"

http://example.com/audio-only.m3u8

________________________________________________

FIG. 7 is a flow diagram of one embodiment of an assembled stream playback technique described herein. In one embodiment, playback of a received media file may be started, stopped, rewound, etc. as controlled by a user. A playlist file is received by a client device in operation 700. The media file indicated by the playlist file is retrieved in operation 710. An output is generated based on the received media file in operation 720. Receiving and generating output based on the media file may be accomplished as described above.

If a control input is detected at operation 730, the client device can determine whether the input indicates a stop at operation 740. If the input is stop, the process ends and playback stops. If the input indicates a rewind or forward request at operation 750, the client device may generate output based on the previously played media file that is still stored in memory at operation 760. If the files are no longer in the cache, processing returns to operation 710 to retrieve the media files and repeat the process. In an alternative embodiment, the playback may support a pause feature that suspends playback rather than ending playback as a stop input.

The method for transitioning from one stream to another is further described with reference to fig. 9A-9D. A client device may perform each of these methods, or the operations of each of these methods may be distributed across multiple client devices as described herein; for example, in a distributed scenario, one client device may retrieve a variant playlist and two media playlists and provide those playlists to another client device, which in turn retrieves the media files specified by the two media playlists and switches between the two streams provided by the retrieved media files. It will be appreciated that in alternative embodiments, the order of the operations shown may be modified or there may be more or less operations than shown in the figures. These methods may use variant playlists to select different streams. The variant playlist may be retrieved and processed at operation 901 to determine the available streams of the program (e.g., sporting event). Operation 901 may be performed by a client device. A first stream may be selected from the variant playlist in operation 903 and the client device may then retrieve a media playlist for the first stream. The client device may process the media playlist for the first stream at operation 905 and may also measure or otherwise determine a bit rate of the network connection for the first stream at operation 907. It will be appreciated that the sequence of operations may be performed in a different order than that shown in FIG. 9A; for example, operation 907 may be performed during operation 903, and so on. In operation 911, the client device selects an alternative media playlist from the variant playlists based on the bit rate measured in operation 907; the replacement media playlist may be at a second bitrate higher than an existing bitrate of the first stream. This typically means that the replacement stream will have a higher resolution than the first stream. The replacement media playlist may be selected if it matches better than the current playlist for the first stream based on current conditions (e.g., bit rate measured in operation 907). In operation 913, an alternate media playlist for the alternate stream is retrieved and processed. This typically means that the client device can receive and process both the first stream and the alternate stream to make both available for rendering; while one stream is being presented, the other stream is ready to be presented. The client device then selects a transition point to switch between versions of the stream at operation 915, stops presenting the first stream and starts presenting the alternate stream. Examples of how this switching can be achieved are presented in connection with fig. 9B-9D. In some embodiments, the client device may stop receiving the first stream before making the switch.

Fig. 9B illustrates that the client device retrieves, stores, and presents content (e.g., a first stream) specified by the first media playlist in operations 921 and 923, while the content specified by the first media playlist is being presented, the client device also retrieves and stores content (e.g., a second stream) specified by the second media playlist in operation 925. The retrieval and storage (e.g., in a temporary buffer) of the content specified by the second media playlist while the content retrieved from the first media playlist is being presented creates an overlap 955 in time of the program content (as shown in fig. 9D), which allows the client device to switch between versions of the program without substantially interrupting the program. In this way, switching between versions of a program may be accomplished without the user noticing that a switch has occurred (although in some cases the user may notice a higher resolution image after the switch) or in many cases without substantially interrupting presentation of the program. In operation 927, the client device determines a transition point to switch from content specified by the first media playlist to content specified by the second media playlist; an example of the transition point (transition point 959) is shown in fig. 9D. The content specified by the second media playlist is then presented after the transition in operation 931.

The methods shown in FIGS. 9C and 9D represent one embodiment for determining a transition point; this embodiment relies on pattern matching of audio samples from the two streams 951 and 953 to determine the transition point. It will be appreciated that alternative embodiments may use pattern matching of the video samples, or may use timestamps or the like in both streams to determine the transition point. The method may include, at operation 941, storing content (e.g., stream 951) specified by a first media playlist in a buffer; the buffer may be used for presentation of content and may also be used for pattern matching operations. Stream 951 includes both audio samples 951A and video samples 951B. The video samples may use compression techniques that rely on i-frames or key frames that have all the content necessary for displaying a single video frame. The content in the stream 951 may include timestamps that specify a time (e.g., an elapsed time from the beginning of a program), and these timestamps may mark the beginning of each sample (e.g., the beginning of each audio sample 951A and the beginning of each video sample 951B). In some cases, the timestamp comparison between two streams may not be useful for determining transition points because they may not be sufficiently accurate, or because of differences in sample boundaries in the two streams; nonetheless, a comparison of the timestamp ranges may be used to verify that there is an overlap 955 in time between the two streams. In operation 943, the client device stores the content specified by the second media playlist in the buffer; the content is for the same program as the content obtained from the first media playlist and may also include a timestamp. In one embodiment, if a timestamp is not present within the stream, a timestamp may be added to the playlist of the stream; for example, in one embodiment, an ID3 tag including one or more timestamps may be added to an entry within a playlist (such as a variant playlist or a media playlist). The entry may be located, for example, in the URI of the first sample of the audio stream. Fig. 9D shows an example of content 953 obtained from the second media playlist, the content 953 including an audio sample 953A and a video sample 953B. At operation 945, the client device may perform pattern matching on the audio samples in the two streams 951 and 953 to select a transition point 959 from the overlap 955, which transition point 959 may be the next self-contained video frame (e.g., i-frame 961) after the matching audio segment (e.g., segment 957) in one embodiment. Starting with the i-frame 961 (and its associated audio sample), the presentation of the program uses a second stream obtained from a second media playlist. The foregoing method may be used in one embodiment for both changes from slower to faster bit rates and changes from faster to slower bit rates, but in another embodiment the method is used only for changes from slower to faster bit rates, while another method (e.g., not attempting to locate a transition point, but rather attempting to store and render content from a slower bit rate stream as fast as possible) is used for changes from faster to slower bit rates.

FIG. 10 is a flow diagram of one embodiment of a technique for providing multiple redundant locations for providing playlists or media content or both to client devices using alternate streams. If the playlist includes alternate streams as discussed above, the alternate streams may operate not only as bandwidth or device alternatives, but also as fail-back (failurefallback). For example, if the client cannot re-stream the playlist file (e.g., due to a 404 error or a network connection error), the client may attempt to switch to an alternate stream. Referring to fig. 10, to implement failover (failover) protection, a first server device or first content distribution service is configured to create a stream or a plurality of alternative bandwidth streams as discussed in connection with the description of fig. 2C at operation 1002. In operation 1004, the first server device or the first content distribution service generates playlist file(s) from the stream(s) generated in operation 1002. The second server device or second content distribution service may create a parallel stream or set of streams and may also create a playlist at operation 1006. These parallel stream(s) may be considered as backup streams. Next, a list of alternate streams is added to the playlist file(s) at operation 1008 so that the alternate stream(s) at each bandwidth are listed after the main stream. For example, if the primary stream is from server ALPHA and the alternate stream is located on server BETA, the playlist file may be as follows:

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000

http://ALPHA.mycompany.com/low/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000

http://BETA.mycompany.com/low/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000

http://ALPHA.mycompany.com/mid/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000

http://BETA.mycompany.com/mid/prog_index.m3u8

note that the alternate streams are mixed with the main stream in a playlist, where the alternate streams at each bandwidth are listed after the main stream for that bandwidth. The client is not limited to a single set of standby streams. In the above examples, ALPHA and BETA may be followed by, for example, GAMMA. Similarly, a complete set of parallel streams need not be provided. For example, a single low bandwidth stream may be provided on the standby server.

In operation 1010, the client downloads the playlist file(s) from the first URL using a first stream associated with the first server device or the first content distribution service. FIG. 11 illustrates a network in which a client 1102 is in two-way communication with one or more URLs, server devices, or content distribution services, according to one embodiment. The playlist file(s) may be transmitted from the first URL, server device, or content distribution service to the client 1102 at operation 1012. If the client is unable to download the playlist file(s) from the first URL, the server device, or the content distribution service (e.g., due to an error in recalling the stream index file), the client attempts to switch to an alternate stream. In the event that a failure (e.g., an index load failure) exists on one stream (e.g., operation 1010), the client selects an alternate stream of the highest bandwidth supported by the network connection at operation 1014. If there are multiple alternatives of the same bandwidth, the client selects from them in the order listed in the playlist. For example, if the client 1102 fails to download successfully from the URL1, it may download from the URL2 or another URL, in which case the playlist file(s) are transmitted to the client from the alternate URL. This feature provides a redundant stream that will allow media to reach the client even if there are several local failures, such as a server crash or a content distributor node down.

Failover protection provides the ability to provide multiple redundant locations from which clients can retrieve playlists and media files. Thus, if the client cannot retrieve a stream from the first location, it may attempt to access the stream from a second, third, etc. location.

In one embodiment, to indicate additional locations from which a client may retrieve playlists, the same variant playlist label will be provided with a new URI of the same bandwidth, but with a redundant location. The client may initially attempt to access a first URL associated with a desired bandwidth. If the client cannot download a playlist from the first URL, it can then attempt to access the next URL proposed for the bandwidth until it has exhausted all possibilities.

The following example includes 1 redundant location for 2560000 bandwidth and 2 redundant locations for 7680000 bandwidth.

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000

http://example.com/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example.com/mid.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example1.com/mid-redundant2.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example2.com/hi-redudant2.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example3.com/hi-redudant3.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CO DECS="mp4a.40.5"

http://example.com/audio-only.m3u8

Note that in this example, the file name (e.g., mid-redundant2.m3u 8) and the actual URL (e.g.,http:// example2.com<http://example2.com/>、http://example3.com<http://example3.com/>) Both vary. However, in one embodiment, the redundant location may be a change in only the file name, or only a change in the website.

In one embodiment, the playlist may be compressed by the server device and sent to the client device in a compressed form. Compressed playlists typically require fewer bits to represent a playlist than uncompressed playlists, and thus compressed playlists use less available bandwidth of a network, such as a wireless cellular telephone network, when transmitted or received. In one embodiment, the playlist may be compressed by the web server according to a built-in compression technique or facility used by the web server that conforms to or is compatible with a transport protocol, such as the HTTP1.1 standard protocol; an example of such a compression technique or facility is the deflate or gzip compression facility of HTTP 1.1. Other standards-based compression facilities that are part of the standards-based transport protocol may be used in other embodiments. The use of a compressed playlist may be an optional feature of the server device and the client device in one embodiment. In one embodiment, the playlist may be textual content (e.g., a text file) and may be efficiently compressed by a standards-based web server using deflate or gzip and then automatically decompressed by the client device. A description of one version of gzip compression facility can be found at www.ietf.org/rfc 1952. txt; and a version of the deflate compression facility can be found at www.ietf.org/rfc 1951. txt. Many web servers, as well as many web browsers on client devices, are capable of automatically supporting deflate or gzip facilities.

In one embodiment, the client device may periodically request an updated playlist; for example, the client device may request an updated playlist from the server every few seconds (e.g., every 10 seconds, 20 seconds, 30 seconds, or other time period). A growing playlist, such as a live game playlist that allows a client to view from the beginning of a live game at any time during the live ongoing baseball game, may become large enough to enable the use of compression to limit the network bandwidth consumed as the growing playlist is repeatedly transmitted over the network.

In one embodiment, the client device may optionally specify when to request a playlist (such as an updated playlist), what compression techniques it can support (such as deflate or gzip); support for these techniques means that the client device is able to decompress or decode the compressed or encoded content. The client device's request for a playlist (and optional specifications for compression techniques) is received by a web server, which in one embodiment is not required to support compression techniques for playlists, but is required to be able to send uncompressed playlists. The web server may respond to the client device's request by sending an uncompressed playlist to the client device or a playlist compressed using one of the compression techniques specified in the client device's request for a playlist. The client device receives the playlist and uses the playlist as described herein; if the playlist is compressed, decoding is performed using a decoder on the client device, such as a decoder within a web browser on the client device.

FIG. 8 is a block diagram of one embodiment of an electronic system. The electronic system illustrated in FIG. 8 is intended to represent a range of electronic systems (wired or wireless) including, for example, desktop computer systems, laptop computer systems, cellular telephones, PDAs including cellular-enabled Personal Digital Assistants (PDAs), set top boxes, entertainment systems, or other consumer electronic devices. Alternative electronic systems may include more, fewer, and/or different components. The electronic system of fig. 8 may be used to provide a client device and/or a server device.

Electronic system 800 includes bus 805 or other communication device for communicating information, and processor 810 coupled to bus 805 and capable of processing information. Although electronic system 800 is illustrated as having a single processor, electronic system 800 may also include multiple processors and/or co-processors. Electronic system 800 may further include a Random Access Memory (RAM) or other dynamic storage device 820 (referred to as main memory), coupled to bus 805 and may store information and instructions that may be executed by processor 810. Main memory 820 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 810.

Electronic system 800 may also include a Read Only Memory (ROM) or other static storage device 830 coupled to bus 805 and may store static information and instructions for processor 810. A data storage device 840 may be coupled to bus 805 to store information and instructions. A data storage device 840, such as a flash memory or a magnetic or optical disk and corresponding drive, may be coupled to electronic system 800.

Electronic system 800 may also be coupled via bus 805 to a display device 850, such as a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD), for displaying information to a user. Electronic system 800 may also include an alphanumeric input device 860, including alphanumeric and other keys, that may be coupled to bus 805 to communicate information and command selections to processor 810. Another type of user input device is cursor control 870, such as a touchpad, mouse, trackball, or cursor direction keys for communicating direction information and command selections to processor 810 and for controlling cursor movement on display 850.

Electronic system 800 may also include one or more network interfaces 880 to provide access to a network, such as a local area network. Network interface(s) 880 may include, for example, a wireless network interface having an antenna 885 (which may represent one or more antennas). Electronic system 800 may include a combination of multiple wireless network interfaces, such as WiFi, Bluetooth, and cellular telephone interfaces. Network interface(s) 880 may also include, for example, a wired network interface to communicate with remote devices via a network cable 887, where network cable 887 may be, for example, an ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

In one embodiment, network interface(s) 880 may provide access to a local area network, e.g., by conforming to the ieee802.11b and/or ieee802.11g standards, and/or a wireless network interface may provide access to a private area network, e.g., by conforming to the Bluetooth standard. Other wireless network interfaces and/or protocols may also be supported.

In addition to, or in lieu of, communicating via wireless LAN standards, network interface(s) 880 may provide wireless communication using, for example, Time Division Multiple Access (TDMA) protocols, global system for mobile communications (GSM) protocols, Code Division Multiple Access (CDMA) protocols, and/or any other type of wireless communication protocol.

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Appendix

The following appendix is a draft specification of a protocol according to a specific embodiment of the invention. It will be understood that the use of certain keywords (e.g., MUST (MUST NOT), MUST NOT (MUST NOT), should (all), should NOT (all NOT), etc.) in this appendix applies to this particular embodiment and NOT to other embodiments described in this disclosure.

Abstract

This document describes protocols for transmitting an unlimited multimedia data stream. The document specifies the data format of the file and the actions to be taken on the stream by the server (sender) and the client (receiver). The document describes version 3 of the protocol.

Content table

1. Introduction to

2. Overview

3. Playlist file

3.1. Introduction to

3.2. New label

3.2.1.EXT-X-TARGETDURATION

3.2.2.EXT-X-MEDIA-SEQUENCE

3.2.3.EXT-X-KEY

3.2.4.EXT-X-PROGRAM-DATE-TIME

3.2.5.EXT-X-ALLOW-CACHE

3.2.6.EXT-X-ENDLIST

3.2.7.EXT-X-STREAM-INF

3.2.8.EXT-X-DISCONTINUITY

3.2.9.EXT-X-VERSION

4. Media files

5. Key file

5.1. Introduction to

5.2. IV for AES-128

6. Client/server actions

6.1. Introduction to

6.2. Server processing

6.2.1. Introduction to

6.2.2. Sliding window playlist

6.2.3. Encrypting media files

6.2.4. Providing variant streams

6.3. Client processing

6.3.1. Introduction to

6.3.2. Loading playlist files

6.3.3. Playing a playlist file

6.3.4. Reloading playlist files

6.3.5. Determining the next file to load

6.3.6. Decrypting encrypted media files

7. Protocol version compatibility

8. Examples of the present invention

8.1. Introduction to

8.2. Simple playlist file

8.3. Sliding window playlist using HTTPS

8.4. Playlist files with encrypted media files

8.5. Variant playlist file

9. Safety considerations

10. Reference to the literature

10.1. Normative reference

10.2. Reference to documents

1. Introduction to

This document describes protocols for transmitting an unlimited multimedia data stream. The protocol supports encryption of media data and provision of alternate versions of the stream (e.g., bit rate). The media data may be transferred soon after it is created, which enables it to be played in near real-time. Data is typically carried via HTTP [ RFC2616 ].

External references describing related standards such as HTTP are listed in section 11.

2. Overview

The multimedia presentation is specified by a URI [ RFC3986] to a playlist file, which is an ordered list of media URIs and informational tags. Each media URI refers to a media file that is a segment of a single continuous stream.

To play the stream, the client first retrieves a playlist file and then retrieves and plays each media file in the playlist. Which reloads the playlist file as described in this document to find additional segments.

The keywords "MUST" (MUST), "MUST" (MUST NOT), "REQUIRED" (REQUIRED), "answer" (all), "NOT" (all), "answer" (answer) and "answer" (answer NOT), "SHOULD" (answer), "SHOULD)", "SHOULD" (answer NOT), "RECOMMENDED" (RECOMMENDED), "MAY" (MAY) and "OPTIONAL" (option) in this document will be explained as described in RFC2119[ RFC2119 ].

3. Playlist file

3.1. Introduction to

The playlist must be an extended M3U playlist file M3U.

This document extends the M3U file format by defining additional tags.

The M3U playlist is a text file composed of individual lines. A line is terminated by a single LF character or by a CR character following the LF character. Each line is a URI, a blank line, or starts with an annotation character (e.g., "#"). The empty row is ignored. No space character is permitted, except for elements in which a space character is explicitly specified.

The URI line identifies the media file or variant playlist file (see section 3.2.7).

The URI may be relative. The opposite URI must be resolvable to the URI of the playlist file containing the URI.

The lines starting with the annotation character "#" are annotations or tags. The tag starts with # EXT. All other lines starting with "#" are annotations and should be ignored.

The duration of a playlist file is the sum of the durations of the media files within it.

M3u8 and/or M3U playlist files with HTTP content type "application/vnd. applet. mpeg" are encoded as UTF-8[ RFC3629 ]. Files whose name ends with m3u and/or with the HTTP content type [ RFC2616] "audio/mpeg" are encoded in US-ASCII [ US _ ASCII ].

The playlist file must have a name that ends with.m 3u8 and/or that has the HTTP content type "application/vnd. applet. mpeg" or that ends with.m 3u and/or that has the HTTP content type "audio/mpeg" (for compatibility).

The extended M3U file format defines two tags: EXTM3U and EXTINF. The extended M3U file is distinguished from the basic M3U file by the first line, which must be "# EXTM 3U".

Extinnf is a record label that describes the media file identified by the URI that follows it. Each media file URI must be preceded by an extinnf tag. The format is as follows:

# EXTINF: < duration >, < title >

"duration" is an integer or floating point number that specifies the duration of a media file in seconds. The integer duration should be rounded to the nearest integer. If the protocol version of the playlist file is less than 3, the duration must be an integer. The remainder of the line following the comma is the title of the media file, which is an optional human-readable information title of the media segment.

This document defines the following new tags: EXT-X-TARGETDURATION, EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X-ALLOW-CACHE, EXT-X-STREAM-INF, EXT-X-ENDLIST, EXT-X-DISCONTENT, and EXT-X-VERSION.

3.2. New label

3.2.1.EXT-X-TARGETDURATION

The EXT-X-TARGETDURATION tag specifies the maximum media file duration. The extinnf duration for each media file in the playlist file must be less than or equal to the target duration. The tag must appear once in the playlist file. The format is as follows:

#EXT-X-TARGETDURATION:<s>

where s is an integer indicating a target duration in seconds.

3.2.2.EXT-X-MEDIA-SEQUENCE

Each media file URI in the playlist has a unique integer sequence number. This sequence number of a URI is equal to the sequence number of its preceding URI plus 1. The EXT-X-MEDIA-SEQUENCE tag indicates the SEQUENCE number of the first URI that appears in the playlist file. The format is as follows:

# EXT-X-MEDIA-SEQUENCE: < number >

Playlists are not allowed to contain more than one EXT-X-MEDIA-SEQUENCE tag. If the playlist file does not contain an EXT-X-MEDIA-SEQUENCE tag, the SEQUENCE number of the first URI in the playlist should be considered to be 0.

The sequence number of the media file need not appear within its URI.

For information on handling the EXT-X-MEDIA-SEQUENCE tag see section 6.3.2 and section 6.3.5.

3.2.3.EXT-X-KEY

The media file may be encrypted. The EXT-X-KEY tag provides the information needed to decrypt the media file that follows it. The format is as follows:

# EXT-X-KEY: METHOD = < METHOD > [, URI = "< URI > ] [, IV = < IV > ]

The method attribute specifies an encryption method. Two encryption methods are defined: NONE and AES-128.

The encryption method NONE means that the media file is not encrypted. If the encryption method is NONE, the URI and IV attributes must not be present.

The encryption method AES-128 means that the media file is encrypted using the advanced encryption Standard [ AES-128] with 128-bit keys and PKCS7 padding [ RFC5652 ]. If the encryption method is AES-128, the URI attribute must be present. The IV attribute may exist; see section 5.2.

The URI attribute (if present) specifies how the key is to be obtained. The IV attribute (if present) specifies the initialization vector to be used with the key. The IV attribute appears in protocol version 2.

The new EXT-X-KEY tag replaces any previous EXT-X-KEY.

If the playlist file does not contain an EXT-X-KEY tag, the media file is not encrypted.

See section 5 for the key file format and section 5.2, section 6.2.3 and section 6.3.6 for additional information about media file encryption.

3.2.4.EXT-X-PROGRAM-DATE-TIME

The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next media file with an absolute DATE and/or TIME. The date/time representation is ISO/IEC8601:2004 ISO _8601 and should indicate a time zone. For example:

#EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>

for more information on the EXT-X-PROGRAM-DATE-TIME tag, see section 6.2.1 and section 6.3.3.

3.2.5.EXT-X-ALLOW-CACHE

The EXT-X-ALLOW-CACHE tag indicates that the client may or may not CACHE the downloaded media file for later playback. It may appear anywhere within the playlist file; it must not occur more than once. The EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. The format is as follows:

#EXT-X-ALLOW-CACHE:<YES|NO>

for more information on the EXT-X-ALLOW-CACHE tag, see section 6.3.3.

3.2.6.EXT-X-ENDLIST

The EXT-X-ENDLIST tag indicates that no more media files are to be added to the playlist file. It may appear anywhere within the playlist file; it must not occur more than once. The format is as follows:

#EXT-X-ENDLIST

3.2.7.EXT-X-STREAM-INF

the EXT-X-STREAM-INF tag indicates that the next URI in the playlist file identifies another playlist file. The format is as follows:

# EXT-X-STREAM-INF: [ Attribute = value ] [, Attribute = value ] < URI >

An attribute is not allowed to appear more than once within the same EXT-X-STREAM-INF tag. The following attributes are defined:

BANDWIDTH=<n>

where n is an integer number of bits per second. Which must be an upper limit on the total bit rate of each media file, is calculated as the container overhead that is included or will occur in the playlist.

PROGRAM-ID=<i>

Where i is an integer that uniquely identifies a particular presentation within the scope of the playlist file.

The playlist file may contain multiple EXT-X-STREAM-INF tags with the same PROGRAM-ID to identify different encodings of the same presentation. These variant playlists may contain additional EXT-X-STREAM-INF tags.

CODES = "[ format ] [, format ] - ]"

Where each format specifies the type of media sample present in a media file in the playlist file.

The valid format identifier is an identifier in the ISO file format namespace defined by RFC4281[ RFC4281 ].

RESOLUTION = < N > x < M > where N is the approximate encoded horizontal RESOLUTION (expressed in number of pixels) of the video within the stream and M is the approximate encoded vertical RESOLUTION. N and M are integers.

3.2.8.EXT-X-DISCONTINUITY

The EXT-X-DISCONTINUITY tag indicates an encoding DISCONTINUITY between the media file that follows it and the media file that precedes it. The set of characteristics that can be changed is as follows:

o file format

Number and type of o-tracks

o coding parameters

o coding sequence

o sequence of time stamps

The format is as follows:

#EXT-X-DISCONTINUITY

for more information on the EXT-X-distinguity label, see section 4, section 6.2.1, and section 6.3.3.

3.2.9.EXT-X-VERSION

The EXT-X-VERSION tag indicates a compatible VERSION of the playlist file. The playlist file, its associated media, and its server must comply with all the terms of the most recent version of this document that describes the protocol version indicated by the tag value.

The format is as follows:

#EXT-X-VERSION:<n>

where n is an integer indicating the protocol version.

The playlist file must not contain more than one EXT-X-VERSION tag. A playlist file that does not contain an EXT-X-VERSION tag must conform to VERSION 1 of the protocol.

4. Media files

Each media file URI within a playlist file must identify the media file as a segment of the entire presentation. Each media file must be formatted as an MPEG-2 transport stream or an MPEG-2 audio element stream ISO _ 13818.

The transport stream file must contain a single MPEG-2 program. There should be a program association table and a program mapping table at the beginning of each file. The file containing the video should have at least one key frame and enough information to fully initialize the video decoder.

The media files in the playlist must be a continuation of the encoded stream at the end of the media file with the previous sequence number unless it is the first media file that was present in the playlist file or it is prefixed with an EXT-X-disconnect tag.

The client should be ready to process multiple tracks of a particular type (e.g., audio or video). A client without other preferences should select the track with the lowest digital PID that it can play.

The client must ignore private streams within the transport stream that it does not recognize.

Sample encoding parameters within a stream within a media file and between corresponding streams across multiple media files should remain consistent. However, the client should handle coding changes when they are encountered, for example by scaling the video content to accommodate the resolution change.

5. Key file

5.1. Introduction to

The EXT-X-KEY tag with the URI attribute identifies the KEY file. The key file contains cryptographic keys that must be used to decrypt subsequent media files in the playlist.

The AES-128 encryption method is a 16-octet key. The format of the key file is simply a 16 octet packed array in binary format.

5.2. IV for AES-128

128-bit AES requires the same 16-octet Initialization Vector (IV) to be supplied in both encryption and decryption. Changing this IV increases the cryptographic strength.

If the EXT-X-KEY tag has an IV attribute, the implementation must use the attribute value as the IV when encrypting or decrypting using the KEY. This value must be interpreted as a 128-bit hexadecimal number and must be prefixed with 0X or 0X.

If the EXT-X-KEY tag does not have the IV attribute, the implementation must use the serial number of the media file as the IV when encrypting or decrypting the media file. The most significant first (big-endian) binary representation of the sequence number should be placed in the 16-octet buffer and filled (on the left) with zeros.

6. Client/server actions

6.1. Introduction to

This section describes how the server generates playlists and media files, and how the client should download and play these playlists and media files.

6.2. Server processing

6.2.1. Introduction to

The generation of MPEG-2 streams is outside the scope of this document, which simply assumes a source containing a continuous stream of the presentation.

The server must segment the stream into individual media files of roughly equal duration. The server should attempt to segment the stream at a point that supports efficient decoding of individual media files (e.g., on packet and key frame boundaries).

The server must create a URI for each media file that will allow its client to obtain the file.

The server must create a playlist file. The playlist file must conform to the format described in section 3. The URI for each media file that the server wishes to make available must appear in the playlist in the order in which it is to be played. The entire media file must be available to the client with its URI in the playlist file.

The playlist file must contain the EXT-X-TARGETDURATION tag. Its value must be equal to or greater than the extinn value of any media file that appears or is about to appear in the playlist file. Its value must not change. A typical target duration is 10 seconds.

The playlist file should contain an EXT-X-VERSION tag indicating a compatible VERSION of the stream. The value of which must be the lowest protocol version to which the server, playlist file, and associated media files all conform.

The server must create a URI for the playlist file that will allow its client to retrieve the file.

If the playlist file is distributed via HTTP, the server should support client requests to encode using "gzip" content.

Changes to the playlist file must be made atomically from the client's perspective.

The server does not ALLOW the value of the EXT-X-ALLOW-CACHE tag to be changed.

Each media file URI in the playlist must be prefixed with an extinnf tag that indicates the (rounded) duration of the media file.

The server may associate the media file with an absolute DATE and TIME by prefixing the URI of the media file with an EXT-X-PROGRAM-DATE-TIME tag. The date and time values provide an informational mapping of the timeline of media to the appropriate wall clock time, which can be used as a basis for lookup, display, or other purposes. If the server provides this mapping, it should place an EXT-X-PROGRAM-DATE-TIME tag after each EXT-X-DISCONTINUITY tag in the playlist file.

If the playlist contains the final media file for the presentation, the playlist file must contain the EXT-X-ENDLIST tag.

If the playlist does not contain an EXT-X-ENDLIST tag, the server must make available a new version of the playlist file that contains at least one new media file URI. The new version of the playlist file must be made available with respect to the time at which the previous version was made available: no earlier than half the target duration after the time and no later than 1.5 times the target duration after the time.

If the server wishes to remove the entire presentation, it must make the playlist file unavailable to the client. It should ensure that all media files within the playlist file remain available to the client at the time of removal for at least the duration of the playlist file.

6.2.2. Sliding window playlist

The server may limit the availability of media files to those media files that were recently added to the playlist. For this reason, the playlist file must always contain exactly one EXT-X-MEDIA-SEQUENCE tag. The tag value must be incremented by 1 for each media file URI removed from the playlist file.

The media file URIs must be removed from the playlist file in the order in which they were added.

If the duration of the playlist file minus the duration of the media file is less than three times the target duration, the server does not allow the media file URI to be removed from the playlist file.

When the server removes the media file URI from the playlist file, the media file should remain available to the client for a period of time equal to the duration of the media file plus the duration of the longest playlist file in which the media file has appeared.

If the server plans to remove a media file after it is delivered to the client via HTTP, it should ensure that the HTTP response contains an expiration header that reflects the plan lifetime.

(the duration of a playlist file that does not contain an EXT-X-ENDLIST tag must be at least three times the target duration).

6.2.3. Encrypting media files

If the media file is to be encrypted, the server must define a URI that will allow the authorized client to obtain the key file containing the decryption key. The key file must conform to the format described in section 5.

The server may set an HTTP expiration header in the key response to indicate that the key may be cached.

If the encryption method is AES-128, AES-128CBC encryption should be applied to each individual media file. The entire file must be encrypted. The cipher block link must not be applied across media files. The IV used for encryption must be the serial number of the media file or the value of the IV attribute of the EXT-X-KEY tag, as described in section 5.2.

The server must encrypt each media file in the playlist using the method and other attributes specified by the EXT-X-KEY tag in the playlist file immediately preceding the URI of the media file. Media files that are preceded by an EXT-X-KEY tag (in the NONE approach), or media files that are not preceded by any EXT-X-KEY tag, are not permitted to be encrypted.

If the playlist file contains a URI for the media file encrypted with the KEY, the server does not allow the EXT-X-KEY tag to be removed from the playlist file.

6.2.4. Providing variant streams

The server may serve multiple playlist files to provide different encodings of the same presentation. If the server does so, it should provide a variant playlist file that lists each variant stream that allows the client to dynamically switch between encodings.

The variant playlist must contain an EXT-X-STREAM-INF tag for each variant STREAM. Each EXT-X-STREAM-INF tag used for the same presentation must have the same PROGRAM-ID attribute value. The PROGRAM-ID value for each presentation must be unique within the variant playlist.

If the EXT-X-STREAM-INF tag contains the CODEC attribute, the attribute value must include every format present in any media file that appears or is to appear in the playlist file as defined by [ RFC4281 ].

The server must comply with the following constraints when generating variant streams:

each variant stream must present the same content including stream discontinuities.

Each variant playlist file must have the same target duration.

Content that appears in one variant playlist file but does not appear in another variant playlist file must appear at the beginning or end of the playlist file and not longer than the target duration.

The matching content in the variant stream must have a matching timestamp. This allows the client to synchronize the various streams.

The element audio stream file must signal the timestamp of the first sample within the file by prepending the ID3PRIV tag [ ID3] with the owner identifier "com. The binary data must be a 33-bit MPEG-2 program element stream time stamp (expressed as the most significant preceding 8-octet number).

Furthermore, all variant streams should contain the same encoded audio bitstream. This allows the client to switch between streams without an audible glitch (glotch) signal.

6.3. Client processing

6.3.1. Introduction to

How the client obtains a URI for a playlist file is outside the scope of the document; assume that the client has already done so.

The client must retrieve the playlist file from the URI. If the playlist file thus obtained is a variant playlist, the client must obtain the playlist file from the variant playlist.

This document does not specify the handling of variant streams by clients.

6.3.2. Loading playlist files

Whenever a playlist file is loaded or reloaded from a playlist URI:

the client must ensure that the playlist file begins with the EXTM3U tag and that the EXT-X-VERSION tag (if present) specifies the protocol VERSION supported by the client; if not, the client does not attempt to use the playlist.

The client should ignore any tags and attributes that it does not recognize.

The client must determine the next media file to load as described in section 6.3.5.

If the playlist contains an EXT-X-MEDIA-SEQUENCE tag, the client should assume that each MEDIA file in the playlist will become unavailable at the time the playlist file is loaded plus the duration of the playlist file. The duration of a playlist file is the sum of the durations of the media files within it.

6.3.3. Playing a playlist file

The client should select the media file to be played first from the playlist at the beginning of playback. If the EXT-X-ENDLIST tag is not present and the client is intended to play the media regularly (i.e., in playlist order at the nominal playback rate), the client should not select a file whose start is less than three times the target duration from the end of the playlist file. Doing so triggers playback stop.

To achieve regular playback, the media files must be played in the order in which they appear in the playlist file. The client may present the media in any manner it desires, including regular playback, random access, and trick modes (cockmode).

The client must be ready to reset its parser(s) and decoder(s) before playing the media file preceded by the EXT-X-disconnect tag.

The client should attempt to load the media files before being required to play them back without interruption to compensate for temporary variations in latency and throughput.

If the playlist file contains an EXT-X-ALLOW-CACHE tag and its value is NO, the client does not ALLOW caching of the downloaded media files after they are played. Otherwise, the client may cache the downloaded media file indefinitely for subsequent playback.

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 should consider it; but if not, the client must not infer the originating time zone.

The client must not rely on the correctness or persistence of the value of the EXT-X-PROGRAM-DATE-TIME tag.

6.3.4. Reloading playlist files

The client must periodically reload the playlist file unless the playlist file contains an EXT-X-ENDLIST tag.

However, the client attempts to reload the playlist file no more frequently than is specified in this section.

When the client device first loads the playlist file, or reloads the playlist file and finds that the playlist file has changed since the last load, the client must wait a period of time before attempting to reload the playlist file again. This time period is referred to as the initial minimum reload delay. This is measured from the moment the client starts loading the playlist file.

The initial minimum reload delay is the duration of the last media file in the playlist. The media file duration is specified by the extlnf tag.

If the client reloads the playlist file and finds that it has not changed, the client must wait a period of time before retrying. The minimum delay is a multiple of the target duration. This multiple is 0.5 for the first attempt, 1.5 for the second attempt, and 3.0 for the subsequent attempts.

6.3.5. Determining the next file to load

The client must examine the playlist file each time it is loaded or reloaded to determine the next media file to enter.

The first file to load must be the file that the client has chosen to play first, as described in section 6.3.3.

If the first MEDIA file to be played has been loaded and the playlist file does not contain an EXT-X-MEDIA-SEQUENCE tag, the client must verify that the current playlist file contains the URI of the last loaded MEDIA file at the offset where the last loaded MEDIA file was originally found and terminate playback if the file is not found. The next media file to be loaded must be the first media file URI in the playlist following the last URI loaded.

If the first to be played file has been loaded and the playlist file contains an EXT-X-MEDIA-SEQUENCE tag, the next to be loaded MEDIA file should be the MEDIA file with the smallest SEQUENCE number that is larger than the SEQUENCE number of the last loaded MEDIA file.

6.3.6. Decrypting encrypted media files

If the playlist file contains an EXT-X-KEY tag that specifies the URI of the KEY file, the client must obtain the KEY file and use the KEYs within the KEY file to decrypt all media files that follow the EXT-X-KEY tag until another EXT-X-KEY tag is encountered.

If the encryption method is AES-128, AES-128CBC decryption should be applied to each individual media file. The entire file must be decrypted. The cipher block link is not permitted to be applied across media files. The IV used for decryption must be the serial number of the media file or the value of the IV attribute of the EXT-X-KEY tag, as described in section 5.2.

If the encryption method is NONE, the client must treat all media files following the EXT-X-KEY label as plaintext (not encrypted) until another EXT-X-KEY label is encountered.

7. Protocol version compatibility

The client and server must implement protocol version 2 or higher to use:

IV attribute of o EXT-X-KEY tag.

The client and server must implement protocol version 3 or higher to use:

o floating point EXTINF duration value.

8. Examples of the present invention

8.1. Introduction to

This section contains several example playlist files.

8.2. Simple playlist file

#EXTM3U

#EXT-X-TARGETDURATION:5220

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST

8.3. Sliding window playlist using HTTPS

#EXTM3U

#EXT-X-TARGETDURATION:8

#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:8,

https://priv.example.com/fileSequence2680.ts

#EXTINF:8,

https://priv.example.com/fileSequence2681.ts

#EXTINF:8,

https://priv.example.com/fileSequence2682.ts8.4. Playlist files with encrypted media files

#EXTM3U

#EXT-X-MEDIA-SEQUENCE:7794

#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-

128,URI="https://priv.example.com/key.php?r=52"

#EXTINF:15,

http://media.example.com/fileSequence52-1.ts

#EXTINF:15,

http://media.example.com/fileSequence52-2.ts

#EXTINF:15,

http://media.example.com/fileSequence52-3.ts

#EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53"

#EXTINF:15,

http://media.example.com/fileSequence53-1.ts

8.5. Variant playlist file

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000

http://example.com/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example.com/mid.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-

ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"

http://example.com/audio-only.m3u8

9. Safety considerations

Since the present protocol typically uses HTTP to transfer data, most of the same security considerations apply. See section 15 of RFC2616[ RFC2616 ].

Media file parsers are often subject to "fuzzing" (fuzzing) attacks. The client should take care when receiving the parser file from the server, thereby rejecting incompatible files.

The playlist file contains URIs that the client will use to make network requests for any entity. The client should perform a range check on the response to prevent buffer overflow. See also the section on Security considerations of RFC3986[ RFC3986 ].

The client should slowly and slowly load the resource identified by the URI to avoid contributing to a denial of service attack.

HTTP requests typically include session state ("cookies") that may contain private user data. The implementation must comply with cookie restrictions and expiration rules as specified in RFC2965[ RFC2965 ]. See also the sections for security considerations of RFC2965 and RFC2964[ RFC2964 ].

The encryption key is specified by the URI. Delivery of these keys should be guaranteed by mechanisms such as HTTP over TLS [ RFC5246] (formerly SSL) in conjunction with the security realm or session cookie.

10. Reference to the literature

10.1. Normative reference

[AES_128]U.S.Department of Commerce/National Institute of Standardsand Technology,"Advanced Encryption Standard(AES),FIPS PUB197",November2001,

<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>>.

[ISO_13818]

International Organization for

Standardization,"ISO/IEC International Standard13818;Generic codingof moving pictures and associated audio information",October2007,

<http://www.iso.org/iso/catalogue_detail?csnu mber=44169>.

[ISO_8601]

International Organization for Standardization,"ISO/IEC InternationalStandard8601:2004;Data elements and interchange formats--Informationinterchange--Representation of dates and times",December2004,

<http://www.iso.org/iso/catalogue_detail?csnu mber=40874>.

[RFC2046]Freed,N.and N.Borenstein,"Multipurpose Internet MailExtensions(MIME)Part Two:Media Types",RFC2046,November1996.

[RFC2119]Bradner,S.,"Key words for use in RFCs to IndicateRequirement Levels",BCP14,RFC2119,March1997.

[RFC2616]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,Leach,P.,and T.Berners-Lee,"Hypertext Transfer Protocol--HTTP/1.1",RFC2616,June1999.

[RFC2964]Moore,K.and N.Freed,"Use of HTTP State Management",BCP44,RFC2964,October2000.

[RFC2965]Kristol,D.and L.Montulli,"HTTP State Management Mechanism",RFC2965,October2000.

[RFC3629]Yergeau,F.,"UTF-8,a transformation format of ISO10646",STD63,RFC3629,November2003.

[RFC3986]Berners-Lee,T.,Fielding,R.,and L.

Masinter,"Uniform Resource Identifier(URI):Generic Syntax",STD66,RFC3986,January2005.

[RFC4281]Gellens,R.,Singer,D.,and P.Frojdh,"The Codecs Parameter for"Bucket"Media Types",RFC4281,November2005.

[RFC5246]Dierks,T.and E.Rescorla,"The Transport Layer Security(TLS)Protocol Version1.2",RFC5246,August2008.

[RFC5652]Housley,R.,"Cryptographic Message Syntax (CMS)",STD70,RFC5652,September2009.

[US_ASCII]

American National Standards Institute,"ANSI X3.4-1986,InformationSystems--Coded Character Sets7-Bit American NationalStandard Code forInformation Interchange(7-Bit ASCII)",December1986.

10.2. Reference to documents

[ID3]ID3.org<http://ID3.org/>,"The ID3audio file data taggingformat",

<http://www.id3.org/Developer_Information>.

[M3U]Nullsoft,Inc.,"The M3U Playlist format,originally invented forthe Winamp media player",<http://wikipedia.org/wiki/M3U>.

Claims (16)

1. A data processing system comprising:

means for requesting, with a client device, a playlist file for a program over a network using a transport protocol, wherein the request specifies at least one compression protocol;

means for receiving, with the client device, the playlist file compressed according to the at least one compression protocol and decompressing, with the client device, the playlist file having a uniform resource indicator, URI, indicating a plurality of media files and a plurality of tags having parameters related to playback of the plurality of media files, wherein a playlist file contains an EXT-X-TARGETDURATION tag having a target duration value equal to or greater than a duration of each of the plurality of media files;

means for requesting one or more of the media files in an order indicated by the requested playlist file using the transport protocol;

means for receiving the requested one or more media files over the network using the transport protocol;

means for determining, with the client device, whether the playlist file includes an EXT-X-ENDLIST tag in the playlist file, the EXT-X-ENDLIST tag indicating that no more media files are to be added to the playlist file;

means for requesting, with the client device, an updated playlist file for the program, the request specifying the at least one compression protocol, wherein requesting the updated playlist file is responsive to determining that the EXT-X-ENDLIST tag is not included in the playlist file;

for receiving the updated playlist file in a compressed format and decompressing the updated playlist file, the updated playlist file including the URIs of the media files in the playlist file and the new URIs of new media files not in the playlist file, with the client device using the playlist file prior to receiving the updated playlist file, wherein a duration of the updated playlist file is a sum of durations of media files referenced in the updated playlist file, and the duration of the updated playlist file is at least three times a target duration when the updated playlist file does not contain an EXT-X-ENDLIST tag.

2. The system of claim 1, wherein the system further comprises:

means for generating an audio and/or video output representing a content stream by playing media files with the client device in the order indicated by the playlist file.

3. The system of claim 2, wherein the compression protocol is compatible with a standards-based HTTP implementation of the transport protocol.

4. The system of claim 3, wherein the compression protocol is one of deflate or gzip.

5. The system of claim 4, wherein the playlist file is a text file.

6. The system of claim 1, wherein the use of the compression protocol by the server is optional.

7. The system of claim 5, wherein the order of the media files in the playlist file represents an order of presentation, wherein the playlist file includes a duration of each media file and the duration of the respective media file precedes each respective media file.

8. A data processing system comprising:

means for receiving a request over a network for a playlist file of a program using a transport protocol, the request specifying at least one compression protocol in transit from a client device, wherein the compression protocol is compatible with a standards-based HTTP implementation of the transport protocol and wherein the compression protocol is one of deflate and gzip;

means for transmitting a playlist file in a compressed format using the at least one compression protocol to a client device, wherein the playlist file does not include the EXT-X-ENDLIST tag, wherein the playlist file includes URIs that indicate a plurality of media files and a plurality of tags having parameters related to playback of the plurality of media files, wherein an order of the media files in the playlist file represents an order of presentation, wherein the playlist file includes a duration of each media file and the duration of the respective media file precedes each respective media file, and the playlist file contains an EXT-X-TARGETDURATION tag having a target duration value that is equal to or greater than the duration of each of the plurality of media files;

means for receiving a request from a client device for one or more of the media files in an order indicated by the playlist file;

means for sending the requested one or more media files over the network to a client device using the transport protocol, the client device generating audio and/or video output representing a content stream by playing the media files with the client device in the order indicated by the playlist file;

means for receiving a request for an updated playlist file from a client device, the request specifying the at least one compression protocol; and

means for transmitting the updated playlist file to a client device in a compressed format, wherein the updated playlist file includes URIs of media files in the playlist file and new URIs of new media files not in the playlist file, wherein a duration of the updated playlist file is a sum of durations of media files referenced in the updated playlist file, and the duration of the updated playlist file is at least three times a target duration when the updated playlist file does not contain an EXT-X-ENDLIST tag.

9. A machine-implemented method, comprising:

requesting, with a client device, a playlist file for a program over a network using a transport protocol, wherein the request specifies at least one compression protocol;

receiving, with the client device, a playlist file compressed according to the at least one compression protocol and decompressing, with the client device, the playlist file, wherein the playlist file has uniform resource indicators, URIs, that indicate a plurality of media files and a plurality of labels having parameters related to playback of the plurality of media files, wherein the playlist file contains an EXT-X-TARGETDURATION label having a target duration value that is equal to or greater than a duration of each of the plurality of media files;

requesting one or more of the media files in an order indicated by the requested playlist file using the transport protocol;

receiving the requested one or more media files over the network using the transport protocol;

determining, with the client device, whether the playlist file includes an EXT-X-ENDLIST tag in the playlist file, the EXT-X-ENDLIST tag indicating that no more media files are to be added to the playlist file;

requesting, with the client device, an updated playlist file for the program, the request specifying the at least one compression protocol, wherein requesting the updated playlist file is in response to determining that the EXT-X-ENDLIST tag is not included in the playlist file;

receiving, with the client device, the updated playlist file in a compressed format and decompressing the updated playlist file, the updated playlist file including the URIs of the media files in the playlist file and new URIs of new media files not in the playlist file, wherein the client device uses the playlist file before receiving the updated playlist file, wherein a duration of the updated playlist file is a sum of durations of media files referenced in the updated playlist file, and the duration of the updated playlist file is at least three times a target duration when the updated playlist file does not contain an EXT-X-ENDLIST tag.

10. The method of claim 9, wherein the method further comprises:

generating audio and/or video output representing a content stream by playing media files with the client device in the order indicated by the playlist file.

11. The method of claim 10, wherein the compression protocol is compatible with a standards-based HTTP implementation of the transport protocol.

12. The method of claim 11, wherein the compression protocol is one of deflate or gzip.

13. The method of claim 12, wherein the playlist file is a text file.

14. The method of claim 9, wherein the use of the compression protocol by the server is optional.

15. The method of claim 13, wherein the order of the media files in the playlist file represents an order of presentation, wherein the playlist file includes a duration of each media file and the duration of the respective media file precedes each respective media file.

16. A machine-implemented method, comprising:

receiving a request over a network for a playlist file of a program using a transport protocol, the request specifying at least one compression protocol in a transfer from a client device, wherein the compression protocol is compatible with a standards-based HTTP implementation of the transport protocol and wherein the compression protocol is one of deflate and gzip;

transmitting a playlist file in a compressed format using the at least one compression protocol to a client device, wherein the playlist file does not include the EXT-X-ENDLIST tag, wherein the playlist file includes URIs that indicate a plurality of media files and a plurality of tags having parameters related to playback of the plurality of media files, wherein an order of the media files in the playlist file represents an order of presentation, wherein the playlist file includes a duration of each media file and the duration of the respective media file precedes each respective media file, and the playlist file contains an EXT-X-TARGETDURATION tag having a target duration value that is equal to or greater than the duration of each of the plurality of media files;

receiving a request from a client device for one or more of the media files in an order indicated by the playlist file;

transmitting the requested one or more media files over the network to a client device using the transport protocol, the client device generating audio and/or video output representing a content stream by playing the media files with the client device in an order indicated by the playlist file;

receiving a request from a client device for the updated playlist file, the request specifying the at least one compression protocol; and

transmitting the updated playlist file to a client device in a compressed format, wherein the updated playlist file includes the URIs of the media files in the playlist file and the new URIs of new media files not in the playlist file, wherein a duration of the updated playlist file is a sum of durations of the media files referenced in the updated playlist file, and the duration of the updated playlist file is at least three times a target duration when the updated playlist file does not contain an EXT-X-ENDLIST tag.