http://blog.chinaunix.net/uid-26000296-id-4932817.html

http://blog.chinaunix.net/uid-26000296-id-4932822.html

http://blog.csdn.net/zhangxinrun/article/details/50739237

直播應用中，RTMP和HLS基本上可以覆蓋所有客戶端觀看，
HLS主要是延時比較大，RTMP主要優勢在於延時低。

1. RTMP的特點如下：

1) Adobe支援得很好：
   RTMP實際上是現在編碼器輸出的工業標準協議，基本上所有的編碼器（攝像頭之類）都支援RTMP輸出。
   原因在於PC市場巨大，PC主要是Windows，Windows的瀏覽器基本上都支援flash，
   Flash又支援RTMP支援得非常好。
2) 適合長時間播放：

   因為RTMP支援的很完善，所以能做到flash播放RTMP流長時間不斷流，
   當時測試是100萬秒，即10天多可以連續播放。
   對於商用流媒體應用，客戶端的穩定性當然也是必須的，否則終端使用者看不了還怎麼玩？
   我就知道有個教育客戶，最初使用播放器播放http流，需要播放不同的檔案，結果就總出問題，
   如果換成伺服器端將不同的檔案轉換成RTMP流，客戶端就可以一直播放；
   該客戶走RTMP方案後，經過CDN分發，沒聽說客戶端出問題了。
3）延遲較低：
   比起YY的那種UDP私有協議，RTMP算延遲大的（延遲在1-3秒），
   比起HTTP流的延時（一般在10秒以上）RTMP算低延時。
   一般的直播應用，只要不是電話類對話的那種要求，RTMP延遲是可以接受的。
   在一般的視訊會議應用中，RTMP延時也能接受，原因是別人在說話的時候我們一般在聽，
   實際上1秒延時沒有關係，我們也要思考（話說有些人的CPU處理速度還沒有這麼快）。
4) 有累積延遲：
   技術一定要知道弱點，RTMP有個弱點就是累積誤差，原因是RTMP基於TCP不會丟包。
   所以當網路狀態差時，伺服器會將包快取起來，導致累積的延遲；
   待網路狀況好了，就一起發給客戶端。
   這個的對策就是，當客戶端的緩衝區很大，就斷開重連。

經過測量發現，在網路狀況良好時：
  . RTMP延時可以做到0.8秒左右。
  . 多級邊緣節點不會影響延遲（和SRS同源的某CDN的邊緣伺服器可以做到）
  . Nginx-Rtmp延遲有點大，估計是快取的處理，多程序通訊導致？
  . GOP是個硬指標，不過SRS可以關閉GOP的cache來避免這個影響.
  . 伺服器效能太低，也會導致延遲變大，伺服器來不及傳送資料。
  . 客戶端的緩衝區長度也影響延遲。
    譬如flash客戶端的NetStream.bufferTime設定為10秒，那麼延遲至少10秒以上。

4. GOP-Cache

什麼是GOP？就是視訊流中兩個I幀的時間距離。
GOP有什麼影響？
Flash（解碼器）只有拿到GOP才能開始解碼播放。
也就是說，伺服器一般先給一個I幀給Flash。
可惜問題來了，假設GOP是10秒，也就是每隔10秒才有關鍵幀，
如果使用者在第5秒時開始播放，會怎麼樣？
第一種方案：等待下一個I幀，
也就是說，再等5秒才開始給客戶端資料。
這樣延遲就很低了，總是實時的流。
問題是：等待的這5秒，會黑屏，現象就是播放器卡在那裡，什麼也沒有，
有些使用者可能以為死掉了，就會重新整理頁面。
總之，某些客戶會認為等待關鍵幀是個不可饒恕的錯誤，延時有什麼關係？
我就希望能快速啟動和播放視訊，最好開啟就能放！


第二種方案：馬上開始放，
放什麼呢？
你肯定知道了，放前一個I幀。
也就是說，伺服器需要總是cache一個gop，
這樣客戶端上來就從前一個I幀開始播放，就可以快速啟動了。
問題是：延遲自然就大了。


有沒有好的方案？
有！至少有兩種：
編碼器調低GOP，譬如0.5秒一個GOP，這樣延遲也很低，也不用等待。
壞處是編碼器壓縮率會降低，影象質量沒有那麼好。

5. 累積延遲

除了GOP-Cache，還有一個有關係，就是累積延遲。
伺服器可以配置直播佇列的長度，伺服器會將資料放在直播佇列中，
如果超過這個長度就清空到最後一個I幀：


當然這個不能配置太小，
譬如GOP是1秒，queue_length是1秒，這樣會導致有1秒資料就清空，會導致跳躍。


有更好的方法？有的。
延遲基本上就等於客戶端的緩衝區長度，因為延遲大多由於網路頻寬低，
伺服器快取後一起發給客戶端，現象就是客戶端的緩衝區變大了，
譬如NetStream.BufferLength=5秒，那麼說明緩衝區中至少有5秒資料。


處理累積延遲的最好方法，是客戶端檢測到緩衝區有很多資料了，如果可以的話，就重連伺服器。
當然如果網路一直不好，那就沒有辦法了。

一、分發方式比較

網際網路上的兩種主要的分發方式：HLS和RTMP，
什麼時候用誰，完全決定於應用場景。
還有其他的分發方式，這些分發方式不屬於網際網路常見和通用的方式，不予以比較：
  . UDP：
    譬如YY的實時應用，視訊會議等等，或者RTSP之類。
    這類應用的特點就是實時性要求特別高，以毫秒計算。
    TCP家族協議根本就滿足不了要求，所以HTTP/TCP都不靠譜。
    這類應用沒有通用的方案，必須自己實現分發（服務端）和播放（客戶端）。
  . P2P：
    譬如RTMFP或者各家自己的協議。
    這類應用的特點是節省頻寬。
    目前PC/flash上的RTMFP比較成熟，Android上的P2P屬於起步群雄紛爭標準不一，
    IOS上P2P應該沒有聽說過。
  . RTSP：
    這種不是網際網路上的主要應用，在其他領域譬如安防等有廣泛應用。


另外，HTTP的也分為幾種：
  . HTTP progressive：
    早期流媒體伺服器分發http檔案時，以普通的http檔案分發，這種叫做漸進式下載，
    意思就是如果檔案很大譬如1小時時長1GB大小，想從中間開始播放是不行的。
    但這種方式已經是作古了，很多http伺服器支援http檔案的seek，就是從中間開始播放。
  . HTTP stream：
    支援seek的HTTP流，譬如各家視訊網站的點播分發方式。
    或者稍微複雜點的，譬如把一個大檔案切幾段之後分發。
    目前在pc/flash上點播國內的主流分發是這種方式。
  . HLS：
    這種是現在適配方式最廣（除了flash, 需要額外的as庫支援），
    在PC上有vlc，Android/IOS原生播放器就支援播放HLS，HTML5裡面的url可以寫HLS地址。
    總之，在移動端是以HLS為主。
  . HDS：adobe自己的HLS，一坨屎。
  . DASH：各家提出的HLS，目前還沒有廣泛應用。


對比以下網際網路上用的流媒體分發方式：
  . HLS：apple的HLS，支援點播和直播。
  . HTTP：即HTTP stream，各家自己定義的http流，應用於國內點播視訊網站。
  . RTMP：直播應用，對實時性有一定要求，以PC為主。

二、RTMP

1. RTMP本質上是流協議，主要的優勢是：
  . 實時性高：
    RTMP的實時性在3秒之內，經過多層CDN節點分發後，實時性也在3秒左右。
    在一些實時性有要求的應用中以RTMP為主。
  . 支援加密：
    RTMPE和RTMPS為加密協議。
    雖然HLS也有加密，但在PC平臺上flash對RTMPE/RTMPS支援應該比較不錯。
  . 穩定性高：
    在PC平臺上flash播放的最穩定方式是RTMP，
    如果做CDN或者大中型叢集分發，選擇穩定性高的協議一定是必要的。
    HTTP也很穩定，但HTTP是在協議上穩定；
    穩定性不只是服務端的事情，在叢集分發，伺服器管理，主備切換，客戶端的支援上，
    RTMP在PC分發這種方式上還是很有優勢。
  . 編碼器接入：
    編碼器輸出到網際網路（還可以輸出為udp組播之類**應用），主要是RTMP。
    譬如專業編碼器，或者flash網頁編碼器，或者FMLE，或者ffmpeg，或者安防攝像頭，都支援RTMP輸出。
    若需要接入多種裝置，譬如提供雲服務；
    或者希望網頁直接採集攝像頭；或者能在不同編碼器之間切換，
    那麼RTMP作為伺服器的輸入協議會是最好的選擇。
  . 系統容錯：
    容錯有很多種級別，RTMP的叢集實現時可以指定N上層，在錯誤時切換不會影響到下層或者客戶端，
    另外RTMP的流沒有標識，切到其他的伺服器的流也可以繼續播放。
    HLS的流熱備切換沒有這麼容易。
    若對於直播的容錯要求高，譬如降低出問題的概率，選擇RTMP會是很好的選擇。
  . 可監控：
    在監控系統或者運維繫統的角度看，流協議應該比較合適監控。
    HTTP的流監控感覺沒有那麼完善。這個不算絕對優勢，但比較有利。


2. RTMP的劣勢是：
  . 協議複雜：
    RTMP協議比起HTTP複雜很多，導致效能低下。
    測試發現兩臺伺服器直連100Gbps網路中，HTTP能跑到60Gbps，但是RTMP只能跑到10Gbps，
    CPU佔用率RTMP要高很多。
    複雜協議導致在研發，擴充套件，維護軟體系統時都沒有HTTP那麼方便，所以HTTP伺服器現在大行其道，
    apache/nginx/tomcat，N多HTTP伺服器；
    而RTMP協議雖然早就公開，但是真正在大規模中分發表現良好的沒有，
    adobe自己的FMS在CDN中都經常出問題。
  . Cache麻煩：
    流協議做快取不方便。譬如點播，若做RTMP流協議，邊緣快取RTMP會很麻煩。
    如果是HTTP，快取其實也很麻煩，但是HTTP伺服器的快取已經做了很久，所以只需要使用就好。
    這是為何點播都走HTTP的原因。

三、HTTP

HTTP說的是HTTP流，譬如各大視訊網站的點播流。
HTTP本質上還是檔案分發，主要的優勢是：
  . 效能很高：
    HTTP的效能沒得說，協議簡單，各種HTTP高效能伺服器也完善。
    如果分發的量特別大，譬如點播視訊網站，沒有直播的實時性要求，HTTP協議是最好選擇。
  . 沒有碎片：
    HTTP比HLS沒有碎片，HTTP分發大檔案會比小檔案分發方便很多。
    特別是儲存，小檔案的效能超低，是個硬傷。
  . 穿牆：
    網際網路不可能不開放HTTP協議，否則就不叫網際網路。所
    以任何埠封掉，也不會導致HTTP流看不了。（不過RTMP也能穿牆，用RTMPT協議）。


HTTP的劣勢是：
  . 實時性差：
    基本上沒有實時性這個說法。
  . 原生支援不好：
    就PC上flash對於HTTP流支援還可以，Android/IOS上似乎只能mp4，總之移動端對於HTTP的支援不是很完善。

四、HLS

HLS是adobe的開放標準，在Android3?以上也原生支援.
HLS的主要優勢是：
  . 效能高：和HTTP一樣。
  . 穿牆：和HTTP一樣。
  . 原生支援很好：IOS上支援完美。Android上支援差些。PC/flash上現在也有各種as外掛支援HLS。


HLS的主要劣勢是：
  . 實時性差：基本上HLS的延遲在10秒以上。
  . 檔案碎片：若分發HLS，碼流低，切片較小時，小檔案分發不是很友好。
    特別是一些對儲存比較敏感的情況，譬如源站的儲存，嵌入式的SD卡。

五、應用方式

推薦的方式是：
  . 編碼器輸出RTMP協議。
  . 流媒體系統接入使用RTMP協議。
  . 流媒體系統內部直播分發使用RTMP。
  . PC+直播+實時性要求高：使用flash播放RTMP。
  . PC+直播+沒有實時性要求：使用RTMP或者HLS均可。
  . PC+點播：使用HTTP或者HLS。
  . Apple IOS/OSX：都使用HLS（實時性要求高得自己解析RTMP，或者使用外部庫，
    譬如https://www.vitamio.org）
  . Andorid：和IOS一樣，不過可以確定的是可以自己開發支援RTMP。

===============================================================================

RTSP、 RTMP、HTTP的共同點、區別

共同點：

1：RTSP RTMP HTTP都是在應用應用層。

2： 理論上RTSP RTMPHTTP都可以做直播和點播，但一般做直播用RTSP RTMP，做點播用HTTP。做視訊會議的時候原來用SIP協議，現在基本上被RTMP協議取代了。

區別：

1：HTTP: 即超文字傳送協議(ftp即檔案傳輸協議)。

HTTP:（Real Time Streaming Protocol），實時流傳輸協議。

HTTP全稱Routing Table Maintenance Protocol（路由選擇表維護協議）。

2：HTTP將所有的資料作為檔案做處理。http協議不是流媒體協議。

RTMP和RTSP協議是流媒體協議。

3：RTMP協議是Adobe的私有協議,未完全公開，RTSP協議和HTTP協議是共有協議，並有專門機構做維護。

4：RTMP協議一般傳輸的是flv，f4v格式流，RTSP協議一般傳輸的是ts,mp4格式的流。HTTP沒有特定的流。

5：RTSP傳輸一般需要2-3個通道，命令和資料通道分離，HTTP和RTMP一般在TCP一個通道上傳輸命令和資料。

RTSP、RTCP、RTP區別

1：RTSP實時流協議

作為一個應用層協議，RTSP提供了一個可供擴充套件的框架，它的意義在於使得實時流媒體資料的受控和點播變得可能。總的說來，RTSP是一個流媒體表示 協議，主要用來控制具有實時特性的資料傳送，但它本身並不傳輸資料，而是必須依賴於下層傳輸協議所提供的某些服務。RTSP可以對流媒體提供諸如播放、暫 停、快進等操作，它負責定義具體的控制訊息、操作方法、狀態碼等，此外還描述了與RTP間的互動操作（RFC2326）。

2：RTCP控制協議

RTCP控制協議需要與RTP資料協議一起配合使用，當應用程式啟動一個RTP會話時將同時佔用兩個埠，分別供RTP和RTCP使用。RTP本身並 不能為按序傳輸資料包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會採用與RTP相同的分發機制，向會話中的 所有成員週期性地傳送控制資訊，應用程式通過接收這些資料，從中獲取會話參與者的相關資料，以及網路狀況、分組丟失概率等反饋資訊，從而能夠對服務質量進 行控制或者對網路狀況進行診斷。

RTCP協議的功能是通過不同的RTCP資料報來實現的，主要有如下幾種型別：

SR：傳送端報告，所謂傳送端是指發出RTP資料報的應用程式或者終端，傳送端同時也可以是接收端。(SERVER定時間傳送給CLIENT)。

RR：接收端報告，所謂接收端是指僅接收但不傳送RTP資料報的應用程式或者終端。(SERVER接收CLIENT端傳送過來的響應)。

SDES：源描述，主要功能是作為會話成員有關標識資訊的載體，如使用者名稱、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制資訊的功能。

BYE：通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。

APP：由應用程式自己定義，解決了RTCP的擴充套件性問題，並且為協議的實現者提供了很大的靈活性。

3：RTP資料協議

RTP資料協議負責對流媒體資料進行封包並實現媒體流的實時傳輸，每一個RTP資料報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個位元組的含義是固定的，而負載則可以是音訊或者視訊資料。

RTP用到的地方就是 PLAY ，伺服器往客戶端傳輸資料用UDP協議，RTP是在傳輸資料的前面加了個12位元組的頭(描述資訊)。

RTP載荷封裝設計本文的網路傳輸是基於IP協議，所以最大傳輸單元(MTU)最大為1500位元組，在使用IP／UDP／RTP的協議層次結構的時候，這 其中包括至少20位元組的IP頭，8位元組的UDP頭，以及12位元組的RTP頭。這樣，頭資訊至少要佔用40個位元組，那麼RTP載荷的最大尺寸為1460字 節。以H264 為例，如果一幀資料大於1460，則需要分片打包，然後到接收端再拆包，組合成一幀資料，進行解碼播放。