Http-live-streaming Protocol Analysis

Http-live-streaming Protocol Analysis:
Unrestricted transmission of multimedia data streams. The protocol supports media data encryption and stream switching (for example, different bitrate).
Media data is transferred immediately after creation, playing near real-time. Media data is typically transmitted using HTTP.
Playlists consist of an ordered list of media URIs and information labels, each of which points to a media file, which is a fragment on a single contiguous stream of media.
In order to play the media stream, the client first obtains the playlist file and then gets and plays each of the media stream files in the playlist. The client repeatedly loads the playlist file to obtain an append fragment, as defined below.
The playlist must be an extended m3u playlist file with a suffix of. M3u8,content-type is "Application/vnd.apple.mpegurl"
#EXTM3U: Extended Markup
#EXTINF: Length of #EXTINF:<duration>,<title> media file (units s) and title (optional)
#EXT-x-media-sequence:<number> identifies the sequence number of the first URI of the playlist, followed by the sequence of the sequence of URLs incremented
#EXT-x-key:method=<method>[,uri= "<URI>"][,IV=&LT;IV&GT;] Media encryption Method (NONE,AES-128) and key acquisition path and key initialization vector, IV =<iv> Field Version2 New
#EXT-x-program-date-time:<yyyy-mm-ddthh:mm:ssz> Identifies the start time of the next media file
#EXT-x-allow-cache:<yes|no>
Whether the client allows caching of downloaded files
#EXT-x-endlist
Identify playlists no longer append media files
#EXT-x-stream-inf:[attribute=value][,attribute=value]*
<URI>
Identifies the next URI as a playlist
Attribute includes:
Bandwidth=<n>: Maximum rate of code
Program-id=<i&gt: Unique identifier of a single presentation in the entire playlist
Codecs= "[format][,format]*": Media sampling type, as specified in RFC 4281
Resolution=<n>x<m>:n: Horizontal pixels, M: vertical pixels

#EXT-x-discontinuity
Identifies changes in the encoding characteristics of the front and back media files, including:
File format
Number and type of tracks
Encoding parameters
Encoding sequence
Timestamp sequence

Each URI in the playlist identifies a media file, which is a fragment of the media presentation. The media file must be a mpeg-2ts stream or MPEG-2 audio basic stream.
The MPEG-2 transport stream can contain only one MPEG-2 program, with Pat and PMT at the beginning of each file, a fragment file with video containing at least one keyframe and enough information to allow the decoder to be fully initialized.
The media file for the playlist must be contiguous, unless the first or last ext-x-discontinuity label media file.
The client must have more than one track of the audio type or video type, and there is no particular preference for the client to select the one that can support the lowest PID number to play.
Clients must ignore private streams that are not recognized in TS.
The encoding parameters sampled in a media file, as well as the encoding parameters of the corresponding media stream in each file, must be consistent. The client should have the ability to handle changes in the encoding parameters, such as adjusting the video content size to accommodate the change in resolution.
1. The server must divide the MPEG-2 stream into a single media file of almost equal length, and the Shard point must support effective decoding of a single media file, such as segmentation by package and keyframe boundaries. The length of a single media file is typically 10s.
2. The server needs to create an accessible URI for each individual media file.
3, the server must create a playlist file, the format according to the requirements of section 3, the URI in the order of play, the playlist of each URI of the media file must be full access by the client.
4. The playlist file must contain Ext-x-targetduration, which indicates the maximum extinf of all media files in the playlist, and its value remains constant throughout the presentation, typically 10s.
5. The server needs to create an accessible URI for the playlist file.
6. The update of the playlist file must be atomic for the client.
7. The playlist should contain the Ext-x-version protocol version number.
8. When the playlist is distributed over HTTP, the server should support the client's "gzip" content-encoding
9. The server cannot change the Ext-x-allow-cache tag value
10. Extinf tags must be in front of each media file Uri
11. The server can place the ext-x-program-date-time tag in front of the media file URI to establish an absolute date time associated with the media file. Date and time values provide the mapping information for the media timeline and Wall-clock time, which can be used for purposes such as seek during playback. If the server provides this mapping, the ext-x-program-date-time should be placed after each ext-x-discontinuity.
12. If the playlist contains the last media file that is displayed, ext-x-endlist should be placed.
13. If the playlist does not have ext-x-endlist, the server must update the playlist file, which contains at least one new media file URI. The update time interval should be within the #ext-x-targetduration time range of [0.5,1.5] times relative to the last update (typically [5,15]s).
14. If the server intends to delete the entire display, so that the playlist is not visible to the client, but the media files in the playlist are still visible to the client, at least keep the playlist interval length.

Article Source Address: http://blog.csdn.net/yangzhiloveyou/article/details/8922341

Http-live-streaming Protocol Analysis