HTTP live Streaming media streaming architecture

HTTP Media Stream Architecturehttp://www.apple.com.cn/developer/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/ Httpstreamingarchitecture/httpstreamingarchitecture.html#//apple_ref/doc/uid/tp40008332-ch101-sw2

HTTP Live media streaming allows you to send live or pre-recorded video and audio to a device running iOS 3.0 and above or to a QuickTime x and later desktop computer via a regular Web server and to support encryption and user authentication. Overview

The HTTP live media stream consists of three parts: the server component, the distribution component, and the client.

The server component is responsible for digitally encoding the incoming media stream and encapsulating it in a format suitable for publication, and then preparing to publish.

The distribution component consists of a standard Web server that accepts client requests and sends ready media content and related resources to the client. For large-scale deployments, edge networks or other content distribution networks may be used.

The client is responsible for requesting the appropriate media content, downloading the media resources, and reassembling the media content to the user in the form of continuous media streaming. In iOS 3.0 and later versions of the device, the client has been built into the QuickTime X and later versions of the desktop computer.

In a typical configuration, the hardware encoder accepts audio-video input, uses MPEG-4 encoding, outputs MPEG-2 TS streams, and then divides the segmented software into a series of short time periods and saves them as media files. These media files are deployed on the Web server. Segmented software also creates and maintains index files that contain references to these media files. The URL of the index file is published on the Web server. The client reads the index files, and then requests the media files sequentially to the server and displays them without pausing.

An example of a simple HTTP live media stream configuration is shown in Figure 1-1. Figure 1-1 Basic Configuration

Input can be real-time or pre-recorded content, usually encoded into MPEG-2 TS streams by existing hardware. The MPEG2 TS Stream is then divided into a series of time periods and saved as a. TS media file. This step is usually done by software tools, such as Apple's media streaming segment.

Audio-only media streams can be a series of simple MPEG files, coded formats or MP3, or AAC with Adts headers.

The staging device also creates an index file that contains a list of media files and some metadata. The format of the index file is. m3u8. The client accesses the URL of the index file and then requests the media file in the index to the server sequentially. Server Components

The server requires a media encoder, which can be an existing hardware, and then requires a method of segmenting and saving the encoded media content into a file, which can be a media streaming device provided by the software such as Apple. Media Encoder

The media Encoder receives real-time information from audio and video devices for encoding and encapsulation. The encoding should be one of the encoding collections supported by the client device, such as the H.264 of the video and the HE-AAC of the audio. Currently, the supported release formats are the MPEG-2 TS stream for audio and video, or only the MPEG basic stream of audio.

The encoder publishes the MPEG-2 TS Stream to the media streaming segment on the local network.

Note: do not confuse MPEG-2 TS streams with MPEG-2 video compression. TS flow is a packaged format that can be used in a variety of compression techniques. Only video H.264 and audio AAC MPEG-2 TS streams are currently supported. Only audio media content can be a MPEG-2 TS stream, or it can be a MPEG-2 basic stream, either a AAC format with a Adts header or a MP3 format.

Important: video encoders should not change the settings of the media stream, such as size or codec type, during encoding.

Media streaming section device

The media streaming segment is usually a software that reads the TS stream from the local network and divides it into a series of equal time media files. Even if each segment is a separate file, the video files generated from the continuous media stream can still be seamlessly refactored.

The staging device also creates an index file that contains references to each media file. The index file is updated whenever a new media file is completed by the staging device. The index file is used to confirm the availability and location of the media file. The segmented device can also encrypt each media segment and create a key file.

Media fragmentation is saved as a. ts file (MPEG-2 Media Stream), and the index file is saved as a. m3u8 file, which is an extension of the. m3u format that holds the MP3 playlist.

Note: because the index file format is an extension of the. m3u format, and the system also supports the. mp3 audio file, the client is also compatible with the traditional MP3 playlist.

The following is a very simple one. m3u8 file example, which contains three unencrypted 10 seconds media files:

#EXTM3U

#EXT-x-media-sequence:0

#EXT-x-targetduration:10

#EXTINF: 10,

Http://media.example.com/segment1.ts

#EXTINF: 10,

Http://media.example.com/segment2.ts

#EXTINF: 10,

Http://media.example.com/segment3.ts

#EXT-x-endlist

The index file may contain the URL of the key file and a switchable index file to support different bandwidths. For more details on the index file format, refer to the IETF Internet draft of the HTTP live media streaming specification. File Segmentation Device

If you already have a media file, and the media file uses a supported codec encoding, you can use the file segmentation device to encapsulate it into a MPEG media stream and divide it into an equal length of time (if the file is already encapsulated in the MPEG-2 TS Stream, the file fragment will skip this step). The file segmentation device allows you to use existing video and audio to provide video-on-demand via HTTP live media streaming. The file fragment completes the same task as the media streaming segment, but is input as a file instead of a media stream. Media Staging File

Media segmentation files are usually generated by the media streaming segment based on encoder output, consisting of a series of video encodings that are H.264 and the audio encoding is the AAC MPEG-2 TS stream. ts files. For audio-only broadcasts, the segmented device can output MPEG basic voice streams, which can be either AAC with Adts head or MP3.

Or, a separate creation. It is also possible to m3u8 files and media segmentation files and to comply with the published specifications. For example, for audio-only broadcasts, you can create using a text editor. m38u files, and lists a series of existing. MP3 files. Distribution Components

The distribution system can be a Web server or Web caching system that publishes media files and index files based on the HTTP protocol. No custom server modules are required, and only a minimal configuration of the Web server is required.

The recommended configuration is usually limited to the specified. The m3u8 file is associated with the MIME type of the. ts file.

File name extension	MIME type
. m3u8	Application/x-mpegurl or Vnd.apple.mpegURL.
. ts	video/mp2t

Adjustment. The m3u8 file's live time attribute (time-to-live) may be necessary for the Web caching mechanism of the download stream because these files are overwritten frequently and each request should be downloaded with the latest version. Client

The client starts from getting the index file and identifies a media stream based on the URL. The index file specifies the location of the available media files, the decrypted key, and the media stream that can be toggled. For the selected media stream, the client downloads each available media file sequentially. Each file contains a contiguous segment of the media stream. Once enough data has been downloaded, the client begins to play the ungrouped media stream to the user.

The client is responsible for obtaining the decryption key, authenticating the user, or displaying the user interface for authenticating and decrypting the media file as needed.

This process repeats until you encounter the #ext-x-endlist tag in the index file. If the #ext-x-endlist tag is not encountered, the index file is considered part of the ongoing broadcast, and the client periodically reloads the new index file. The client looks for new media files and encryption keys in the updated index file and adds the URLs to the playlist.