HTTP Live Streaming Live (iOS live) technical analysis and implementation

Http://www.cnblogs.com/haibindev/archive/2013/01/30/2880764.html

Inadvertently found that the big six months did not write a blog, consciously ashamed. In fact, after 2012 half a year, the things in the family happened the same, there is no time. Fast New Year, finally sneak in, the recent technical achievements, summed up into the article, share with you.

Some days ago, it was also a project need, spent some time studying HTTP live streaming(HLS) technology, and implemented a HLS encoder HLSLiveEncoder, Of course, C + + is written. Its function is to capture the camera and microphone, real-time video coding and AAC audio encoding, and according to HLS protocol specification, the generation of segmented standard TS files and m3u8 index files. Through my HLSliveEncoder and third-party HTTP server (for example: Nginx), the successful implementation of the HTTP live streaming live, and on the iphone test pass. I'm going to write some of the gains here.

Key points of HLS technology

　　HTTP Live streaming(HLS) is Apple Inc. (Apple Inc) The implementation of the HTTP-based streaming media transmission protocol, can achieve streaming media live and on-demand, mainly in the iOS system, for iOS devices (such as the iphone, IPad) to provide audio and video live and on-demand programs. HLS On-demand, basically is the common segment HTTP on-demand, the difference is that its segmentation is very small. To achieve HLS on-demand, the focus is on the media file segmentation, there are many open source tools can be used, here I will no longer discuss, only talk about HLS live technology.

Compared to the common streaming live broadcast protocol, such as RTMP protocol, RTSP protocol, MMS protocol, the biggest difference of HLS live is that the live client obtains, not a complete data stream. The HLS protocol stores the live stream as a continuous, short-length media file (mpeg-ts format) on the server side, while the client constantly downloads and plays these small files because the server side always generates new small files with the latest live data. So that the client as long as the sequential playback of the files obtained from the server, the implementation of the live broadcast. It can be seen, basically, that HLS is on-demand technical way to achieve live. Because the data through the HTTP protocol transmission, so completely do not consider the firewall or proxy problems, and the length of the fragmented file is very short, the client can quickly select and switch the bitrate to adapt to different bandwidth conditions of playback. However, this technical feature of HLS determines that its delay will always be higher than the normal streaming live protocol.

Based on the above understanding to implement the HTTP live streaming live, you need to study and implement the following technical key points

1. Capture data from video sources and audio sources
2. H264 encoding and AAC encoding of raw data
3. Video and audio data encapsulated as Mpeg-ts package
4. HLS segmentation Generation Strategy and m3u8 index file
5. HTTP Transport Protocol

The 1th and 2nd, which I have already mentioned in previous articles, and finally, we can use the existing HTTP server, so the implementation of 3rd and 4th is the key.

Program Framework and implementation

Through the above analysis, the realization of HLS Liveencoder Live encoder, its logic and flow is basically clear: the audio and video encoding thread, respectively, through the DirectShow(or other) technology to achieve audio and video capture, libx264 and LIBFAAC are then called separately for video and audio encoding. After two encoding threads encode the audio and video data in real time, it is stored in a mpeg-ts format fragment file according to the custom Shard policy, and when the storage of a segmented file is completed, the m3u8 index file is updated. As shown in the following:

Hlsliveencoder When you receive video and audio data, you need to first determine whether the current shard should end and create a new shard to continue the continuous generation of TS shards. It is important to note that the new shard should start from the keyframe to prevent the player from decoding the failure. The core code is as follows:

The interface of the tsmuxer is also relatively simple.

HLS segmentation Generation Strategy and m3u8 1. Segmentation Policy

• HLS segmentation strategy, basically recommended is 10 seconds a shard, of course, the specific time also according to the partition after the actual length of the Shard to be labeled
• In general, for reasons such as caching, the most recent three Shard addresses are kept in the index file and updated in the form of "sliding windows".

2. Introduction to the m3u8 file

m3u8, is the index file for HTTP live streaming live. M3u8 can basically be thought of as the. m3u format file, except that the m3u8 file uses UTF-8 character encoding.

#EXTM3U                     m3u file header, must be placed on the first line #ext-x-media-sequence the       first TS Shard's serial number #ext-x-targetduration the       maximum duration per shard ts # Ext-x-allow-cache          whether to allow Cache#ext-x-endlist              m3u8 file Terminator #extinf                     extra info, shard TS information such as duration, bandwidth, etc.

A simple m3u8 index file

Run effect

Start hlsliveencoderin Nginx working directory and play with VLC player

The effect of playing through the iphone

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

haibindev.cnblogs.com, please contact QQ for cooperation. (reproduced please specify the author and source)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

HTTP Live Streaming Live (iOS live) technical analysis and implementation