幾種直播流媒體協議

題外話：

HTTP漸進下載流媒體播放:  基於TCP。

yy、樂視、愛奇藝、優酷土豆、搜狐視頻、花椒直播，主要仍是經過rtmp&hls來實現的，

但他們也意識到rtmp的天生缺陷，因此不論是技術預研也好，仍是測試版也好，都已經或多或少在弄WebRTC了。

   

流媒體概述：

所謂流媒體是指採用流式傳輸的方式在 Internet 播放的媒體格式。 
流媒體又叫流式媒體，它是指商家用一個視頻傳送服務器把節目當成數據包發出，傳送到網絡上。
用戶經過解壓設備對這些數據進行解壓後，節目就會像發送前那樣顯示出來。
流媒體以流的方式在網絡中傳輸音頻、視頻和多媒體文件的形式。
流媒體文件格式是支持採用流式傳輸及播放的媒體格式。
流式傳輸方式是將視頻和音頻等多媒體文件通過特殊的壓縮方式分紅一個個壓縮包，
由服務器向用戶計算機連續、實時傳送。在採用流式傳輸方式的系統中，用戶沒必要像非流式播放那樣等到整個文件
所有下載完畢後才能看到當中的內容，而是隻須要通過幾秒鐘或幾十秒的啓動延時便可在用戶計算機上利用
相應的播放器對壓縮的視頻或音頻等流式媒體文件進行播放，剩餘的部分將繼續進行下載，直至播放完畢。

   

RTP :(Real-time Transport Protocol)

是用於Internet上針對多媒體數據流的一種傳輸層協議.RTP 協議和 RTP 控制協議 RTCP 一塊兒使用，
並且它是創建在 UDP 協議上的.
RTP 不像http和ftp可完整的下載整個影視文件，它是以固定的數據率在網絡上發送數據，客戶端也是按照這種速度觀看影視文件，當
影視畫面播放事後，就不能夠再重複播放，除非從新向服務器端要求數據。

   

RTCP:Real-time Transport Control Protocol 或 RTP Control Protocol或簡寫 RTCP)

實時傳輸控制協議,是實時傳輸協議(RTP)的一個姐妹協議.

注:--:RTP 協議和 RTP控制協議(RTCP) 一塊兒使用，並且它是創建在UDP協議上的（通常用於視頻會議）

RTSP:(Real Time Streaming Protocol)

實時流媒體會話協議,SDP(會話描述協議)，RTP(實時傳輸協議)。

是用來控制聲音或影像的多媒體串流協議,RTSP 提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成爲可能。
媒體數據使用rtp,rtcp協議。
通常使用udp 做爲傳輸層。適合IPTV場景。
數據源包括現場數據與存儲在剪輯中的數據。該協議目的在於控制多個數據發送鏈接，爲選擇發送通道，如UDP、多播UDP與TCP提供途
徑，併爲選擇基於RTP上發送機制提供方法
傳輸時所用的網絡通信協定並不在其定義的範圍內，服務器端能夠自行選擇使用TCP或UDP來傳送串流內容，比較能容忍網絡延遲.


--->:RTSP 與 RTP 最大的區別在於：RTSP 是一種雙向實時數據傳輸協議，它容許客戶端向服務器端發送請求，如回放、快進、倒退等操做。當
然，RTSP 可基於 RTP 來傳送數據，還能夠選擇 TCP、UDP、組播 UDP 等通道來發送數據，具備很好的擴展性。它時一種相似與http協議
的網絡應用層協議.

WebRTC:

web端實現流媒體的協議。google剛推出WebRTC的時候巨頭們要麼冷眼旁觀，要麼抵觸情緒很大。使用RTP協議傳輸。

   

RTMP(Real Time Messaging Protocol)

Macromedia 開發的一套視頻直播協議，如今屬於 Adobe。和 HLS 同樣均可以應用於視頻直播，基於TCP不會丟失。
// 區別是 RTMP 基於 flash 沒法在 iOS 的瀏覽器裏播放，可是實時性比 HLS 要好。
實時消息傳送協議是 Adobe Systems 公司爲 Flash 播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議.
 // iOS 代碼裏面通常經常使用的是使用 RTMP 推流，可使用第三方庫 librtmp-iOS 進行推流，librtmp 封裝了一些核心的 API 供使用者調用
RTMP 協議也要客戶端和服務器經過"握手"來創建 RTMP Connection，而後在Connection上傳輸控制信息。RTMP 協議傳輸時會對數據格式化，而實際傳輸的時候爲了更好地實現多路複用、分包和信息的公平性，發送端會把Message劃分爲帶有 Message ID的Chunk，每一個Chunk多是一個單獨的Message，
也多是Message的一部分，在接受端會根據Chunk中包含的data的長度，message id和message的長度把chunk還原成完整的Message，從而實現信息的收發。

HLS:HTTP Live Streaming(HLS)

是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議，

可實現流媒體的直播和點播 ,主要應用在iOS系
統，爲iOS設備(如iPhone、iPad)提供音視頻直播和點播方案。
HLS 點播，基本上就是常見的分段HTTP點播，不一樣在於，它的分段很是小。
相對於常見的流媒體直播協議，例如RTMP協議、RTSP 協議、MMS 協議等，HLS 直播最大的不一樣在於，直播客戶端獲取到的，並非一個完
整的數據流。
HLS 協議在服務器端將直播數據流存儲爲連續的、很短時長的媒體文件(MPEG-TS格式)，而客戶端則不斷的下載並播放這些小文件，
由於服務器端老是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。
因而可知，基本上能夠認爲，HLS 是以>>點播的技術方式來實現直播<<。因爲數據經過 HTTP 協議傳輸，因此徹底不用考慮防火牆或者代理的問
題,並且分段文件的時長很短，客戶端能夠很快的選擇和切換碼率，以適應不一樣帶寬條件下的播放。不過HLS的這種技術特色，決定了它的
延遲通常老是會高於普通的流媒體直播協議。
// iOS和 Android 都自然支持這種協議，配置簡單，直接使用 video 標籤便可

***VLS ：是一種流服務器，專門用來解決流的各類問題，它也具備一些 VLC 的特徵。 videolan 做爲服務器能夠輸出http，rtp，rtsp的流。


原則上，RTSP，RTMP，HTTP 均可以作直播和點播，但通常作直播用 RTSP和RTMP，作點播用 HTTP。咱們選用的是RTMP協議。

 

各類協議延時及其緣由

rtmp和httpflv：這兩種協議大體數據一致，因此延時緣由都是差很少的。按理說tcp流式傳輸直播因該都是延時極低的，爲何rtmp和httpflv還有延時呢？緣由在h264上，rtmp和httpflv都是傳輸的flv tag，視頻tag的數據日常就是h264數據，h264解碼有個IBP，I是關鍵幀，是一幀完整的圖像，必需要先有個I才能解碼後面的BP，BP幀能夠隨便少，可是I幀不能少，因此I幀必須是在flv tag傳輸中第二個傳輸的（第一個是h264spspps），可是I幀在h264流裏不是常有的，是隔一段纔有個I幀，這個一段的間隔，俗稱GOP，當編碼時候GOP設置很短，當客戶端鏈接上來，服務器會以最快速度找到流中最近I幀，從I幀開始發送直播數據，然而當GOP很長，I幀間隔很長，或者等待下一個I幀開始向新鏈接發送數據，或者在緩存裏找最近的上一個I幀開始發送，這裏就是rtmp和hls協議延時的關鍵了，在各大cdn平臺，叫"rtmp秒開技術"，原理就是將推流數據二次解編碼，設置很小的gop。總的來講，gop設置1s，在不考慮網絡傳輸鏈路延時狀況，數據延時最大就爲1s，運氣好恰好就是I幀就是0延時！

   

 

 

轉自：http://blog.csdn.net/u011216417/article/details/72835402