本篇文檔轉(zhuǎn)載：http://www.cnblogs.com/my_life/articles/5593892.html，感謝博主熱心的奉獻(xiàn)

以下內(nèi)容為轉(zhuǎn)載內(nèi)容：

http://inaunix.NET/uid-26000296-id-4932817.html

http://inaunix.Net/uid-26000296-id-4932822.html

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

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

1. RTMP的特點如下：

1) Adobe支持得很好：
   RTMP實際上是現(xiàn)在編碼器輸出的工業(yè)標(biāo)準(zhǔn)協(xié)議，基本上所有的編碼器（攝像頭之類）都支持RTMP輸出。
   原因在于PC市場巨大，PC主要是Windows，Windows的瀏覽器基本上都支持flash，
   Flash又支持RTMP支持得非常好。
2) 適合長時間播放：
   因為RTMP支持的很完善，所以能做到flash播放RTMP流長時間不斷流，
   當(dāng)時測試是100萬秒，即10天多可以連續(xù)播放。
   對于商用流媒體應(yīng)用，客戶端的穩(wěn)定性當(dāng)然也是必須的，否則最終用戶看不了還怎么玩？
   我就知道有個教育客戶，最初使用播放器播放http流，需要播放不同的文件，結(jié)果就總出問題，
   如果換成服務(wù)器端將不同的文件轉(zhuǎn)換成RTMP流，客戶端就可以一直播放；
   該客戶走RTMP方案后，經(jīng)過CDN分發(fā)，沒聽說客戶端出問題了。
3）延遲較低：
   比起YY的那種UDP私有協(xié)議，RTMP算延遲大的（延遲在1-3秒），
   比起HTTP流的延時（一般在10秒以上）RTMP算低延時。
   一般的直播應(yīng)用，只要不是電話類對話的那種要求，RTMP延遲是可以接受的。
   在一般的視頻會議應(yīng)用中，RTMP延時也能接受，原因是別人在說話的時候我們一般在聽，
   實際上1秒延時沒有關(guān)系，我們也要思考（話說有些人的CPU處理速度還沒有這么快）。
4) 有累積延遲：
   技術(shù)一定要知道弱點，RTMP有個弱點就是累積誤差，原因是RTMP基于TCP不會丟包。
   所以當(dāng)網(wǎng)絡(luò)狀態(tài)差時，服務(wù)器會將包緩存起來，導(dǎo)致累積的延遲；
   待網(wǎng)絡(luò)狀況好了，就一起發(fā)給客戶端。
   這個的對策就是，當(dāng)客戶端的緩沖區(qū)很大，就斷開重連。

經(jīng)過測量發(fā)現(xiàn)，在網(wǎng)絡(luò)狀況良好時：
  . RTMP延時可以做到0.8秒左右。
  . 多級邊緣節(jié)點不會影響延遲（和SRS同源的某CDN的邊緣服務(wù)器可以做到）
  . Nginx-Rtmp延遲有點大，估計是緩存的處理，多進(jìn)程通信導(dǎo)致？
  . GOP是個硬指標(biāo)，不過SRS可以關(guān)閉GOP的cache來避免這個影響.
  . 服務(wù)器性能太低，也會導(dǎo)致延遲變大，服務(wù)器來不及發(fā)送數(shù)據(jù)。
  . 客戶端的緩沖區(qū)長度也影響延遲。
    譬如flash客戶端的NetStream.bufferTime設(shè)置為10秒，那么延遲至少10秒以上。

4. GOP-Cache

什么是GOP？就是視頻流中兩個I幀的時間距離。
GOP有什么影響？
Flash（解碼器）只有拿到GOP才能開始解碼播放。
也就是說，服務(wù)器一般先給一個I幀給Flash。
可惜問題來了，假設(shè)GOP是10秒，也就是每隔10秒才有關(guān)鍵幀，
如果用戶在第5秒時開始播放，會怎么樣？
第一種方案：等待下一個I幀，
也就是說，再等5秒才開始給客戶端數(shù)據(jù)。
這樣延遲就很低了，總是實時的流。
問題是：等待的這5秒，會黑屏，現(xiàn)象就是播放器卡在那里，什么也沒有，
有些用戶可能以為死掉了，就會刷新頁面。
總之，某些客戶會認(rèn)為等待關(guān)鍵幀是個不可饒恕的錯誤，延時有什么關(guān)系？
我就希望能快速啟動和播放視頻，最好打開就能放！


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


有沒有好的方案？
有！至少有兩種：
編碼器調(diào)低GOP，譬如0.5秒一個GOP，這樣延遲也很低，也不用等待。
壞處是編碼器壓縮率會降低，圖像質(zhì)量沒有那么好。

5. 累積延遲

除了GOP-Cache，還有一個有關(guān)系，就是累積延遲。
服務(wù)器可以配置直播隊列的長度，服務(wù)器會將數(shù)據(jù)放在直播隊列中，
如果超過這個長度就清空到最后一個I幀：


當(dāng)然這個不能配置太小，
譬如GOP是1秒，queue_length是1秒，這樣會導(dǎo)致有1秒數(shù)據(jù)就清空，會導(dǎo)致跳躍。


有更好的方法？有的。
延遲基本上就等于客戶端的緩沖區(qū)長度，因為延遲大多由于網(wǎng)絡(luò)帶寬低，
服務(wù)器緩存后一起發(fā)給客戶端，現(xiàn)象就是客戶端的緩沖區(qū)變大了，
譬如NetStream.BufferLength=5秒，那么說明緩沖區(qū)中至少有5秒數(shù)據(jù)。


處理累積延遲的最好方法，是客戶端檢測到緩沖區(qū)有很多數(shù)據(jù)了，如果可以的話，就重連服務(wù)器。
當(dāng)然如果網(wǎng)絡(luò)一直不好，那就沒有辦法了。

一、分發(fā)方式比較

互聯(lián)網(wǎng)上的兩種主要的分發(fā)方式：HLS和RTMP，
什么時候用誰，完全決定于應(yīng)用場景。
還有其他的分發(fā)方式，這些分發(fā)方式不屬于互聯(lián)網(wǎng)常見和通用的方式，不予以比較：
  . UDP：
    譬如YY的實時應(yīng)用，視頻會議等等，或者RTSP之類。
    這類應(yīng)用的特點就是實時性要求特別高，以毫秒計算。
    TCP家族協(xié)議根本就滿足不了要求，所以HTTP/TCP都不靠譜。
    這類應(yīng)用沒有通用的方案，必須自己實現(xiàn)分發(fā)（服務(wù)端）和播放（客戶端）。
  . P2P：
    譬如RTMFP或者各家自己的協(xié)議。
    這類應(yīng)用的特點是節(jié)省帶寬。
    目前PC/flash上的RTMFP比較成熟，Android上的P2P屬于起步群雄紛爭標(biāo)準(zhǔn)不一，
    iOS上P2P應(yīng)該沒有聽說過。
  . RTSP：
    這種不是互聯(lián)網(wǎng)上的主要應(yīng)用，在其他領(lǐng)域譬如安防等有廣泛應(yīng)用。


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


對比以下互聯(lián)網(wǎng)上用的流媒體分發(fā)方式：
  . HLS：apple的HLS，支持點播和直播。
  . HTTP：即HTTP stream，各家自己定義的http流，應(yīng)用于國內(nèi)點播視頻網(wǎng)站。
  . RTMP：直播應(yīng)用，對實時性有一定要求，以PC為主。

二、RTMP

1. RTMP本質(zhì)上是流協(xié)議，主要的優(yōu)勢是：
  . 實時性高：
    RTMP的實時性在3秒之內(nèi)，經(jīng)過多層CDN節(jié)點分發(fā)后，實時性也在3秒左右。
    在一些實時性有要求的應(yīng)用中以RTMP為主。
  . 支持加密：
    RTMPE和RTMPS為加密協(xié)議。
    雖然HLS也有加密，但在PC平臺上flash對RTMPE/RTMPS支持應(yīng)該比較不錯。
  . 穩(wěn)定性高：
    在PC平臺上flash播放的最穩(wěn)定方式是RTMP，
    如果做CDN或者大中型集群分發(fā)，選擇穩(wěn)定性高的協(xié)議一定是必要的。
    HTTP也很穩(wěn)定，但HTTP是在協(xié)議上穩(wěn)定；
    穩(wěn)定性不只是服務(wù)端的事情，在集群分發(fā)，服務(wù)器管理，主備切換，客戶端的支持上，
    RTMP在PC分發(fā)這種方式上還是很有優(yōu)勢。
  . 編碼器接入：
    編碼器輸出到互聯(lián)網(wǎng)（還可以輸出為udp組播之類**應(yīng)用），主要是RTMP。
    譬如專業(yè)編碼器，或者flash網(wǎng)頁編碼器，或者FMLE，或者ffmpeg，或者安防攝像頭，都支持RTMP輸出。
    若需要接入多種設(shè)備，譬如提供云服務(wù)；
    或者希望網(wǎng)頁直接采集攝像頭；或者能在不同編碼器之間切換，
    那么RTMP作為服務(wù)器的輸入?yún)f(xié)議會是最好的選擇。
  . 系統(tǒng)容錯：
    容錯有很多種級別，RTMP的集群實現(xiàn)時可以指定N上層，在錯誤時切換不會影響到下層或者客戶端，
    另外RTMP的流沒有標(biāo)識，切到其他的服務(wù)器的流也可以繼續(xù)播放。
    HLS的流熱備切換沒有這么容易。
    若對于直播的容錯要求高，譬如降低出問題的概率，選擇RTMP會是很好的選擇。
  . 可監(jiān)控：
    在監(jiān)控系統(tǒng)或者運(yùn)維系統(tǒng)的角度看，流協(xié)議應(yīng)該比較合適監(jiān)控。
    HTTP的流監(jiān)控感覺沒有那么完善。這個不算絕對優(yōu)勢，但比較有利。


2. RTMP的劣勢是：
  . 協(xié)議復(fù)雜：
    RTMP協(xié)議比起HTTP復(fù)雜很多，導(dǎo)致性能低下。
    測試發(fā)現(xiàn)兩臺服務(wù)器直連100Gbps網(wǎng)絡(luò)中，HTTP能跑到60Gbps，但是RTMP只能跑到10Gbps，
    CPU占用率RTMP要高很多。
    復(fù)雜協(xié)議導(dǎo)致在研發(fā)，擴(kuò)展，維護(hù)軟件系統(tǒng)時都沒有HTTP那么方便，所以HTTP服務(wù)器現(xiàn)在大行其道，
    apache/nginx/tomcat，N多HTTP服務(wù)器；
    而RTMP協(xié)議雖然早就公開，但是真正在大規(guī)模中分發(fā)表現(xiàn)良好的沒有，
    adobe自己的FMS在CDN中都經(jīng)常出問題。
  . Cache麻煩：
    流協(xié)議做緩存不方便。譬如點播，若做RTMP流協(xié)議，邊緣緩存RTMP會很麻煩。
    如果是HTTP，緩存其實也很麻煩，但是HTTP服務(wù)器的緩存已經(jīng)做了很久，所以只需要使用就好。
    這是為何點播都走HTTP的原因。

三、HTTP

HTTP說的是HTTP流，譬如各大視頻網(wǎng)站的點播流。
HTTP本質(zhì)上還是文件分發(fā)，主要的優(yōu)勢是：
  . 性能很高：
    HTTP的性能沒得說，協(xié)議簡單，各種HTTP高性能服務(wù)器也完善。
    如果分發(fā)的量特別大，譬如點播視頻網(wǎng)站，沒有直播的實時性要求，HTTP協(xié)議是最好選擇。
  . 沒有碎片：
    HTTP比HLS沒有碎片，HTTP分發(fā)大文件會比小文件分發(fā)方便很多。
    特別是存儲，小文件的性能超低，是個硬傷。
  . 穿墻：
    互聯(lián)網(wǎng)不可能不開放HTTP協(xié)議，否則就不叫互聯(lián)網(wǎng)。所
    以任何端口封掉，也不會導(dǎo)致HTTP流看不了。（不過RTMP也能穿墻，用RTMPT協(xié)議）。


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

四、HLS

HLS是adobe的開放標(biāo)準(zhǔn)，在Android3?以上也原生支持.
HLS的主要優(yōu)勢是：
  . 性能高：和HTTP一樣。
  . 穿墻：和HTTP一樣。
  . 原生支持很好：IOS上支持完美。Android上支持差些。PC/flash上現(xiàn)在也有各種as插件支持HLS。


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

五、應(yīng)用方式

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

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

RTSP、 RTMP、HTTP的共同點、區(qū)別

共同點：

1：RTSP RTMP HTTP都是在應(yīng)用應(yīng)用層。

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

區(qū)別：

1：HTTP: 即超文本傳送協(xié)議(ftp即文件傳輸協(xié)議)。

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

HTTP全稱Routing Table Maintenance Protocol（路由選擇表維護(hù)協(xié)議）。

2：HTTP將所有的數(shù)據(jù)作為文件做處理。http協(xié)議不是流媒體協(xié)議。

RTMP和RTSP協(xié)議是流媒體協(xié)議。

3：RTMP協(xié)議是Adobe的私有協(xié)議,未完全公開，RTSP協(xié)議和HTTP協(xié)議是共有協(xié)議，并有專門機(jī)構(gòu)做維護(hù)。

4：RTMP協(xié)議一般傳輸?shù)氖莊lv，f4v格式流，RTSP協(xié)議一般傳輸?shù)氖莟s,mp4格式的流。HTTP沒有特定的流。

5：RTSP傳輸一般需要2-3個通道，命令和數(shù)據(jù)通道分離，HTTP和RTMP一般在TCP一個通道上傳輸命令和數(shù)據(jù)。

RTSP、RTCP、RTP區(qū)別

1：RTSP實時流協(xié)議

作為一個應(yīng)用層協(xié)議，RTSP提供了一個可供擴(kuò)展的框架，它的意義在于使得實時流媒體數(shù)據(jù)的受控和點播變得可能?？偟恼f來，RTSP是一個流媒體表示 協(xié)議，主要用來控制具有實時特性的數(shù)據(jù)發(fā)送，但它本身并不傳輸數(shù)據(jù)，而是必須依賴于下層傳輸協(xié)議所提供的某些服務(wù)。RTSP可以對流媒體提供諸如播放、暫 停、快進(jìn)等操作，它負(fù)責(zé)定義具體的控制消息、操作方法、狀態(tài)碼等，此外還描述了與RTP間的交互操作（RFC2326）。

2：RTCP控制協(xié)議

RTCP控制協(xié)議需要與RTP數(shù)據(jù)協(xié)議一起配合使用，當(dāng)應(yīng)用程序啟動一個RTP會話時將同時占用兩個端口，分別供RTP和RTCP使用。RTP本身并 不能為按序傳輸數(shù)據(jù)包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負(fù)責(zé)完成。通常RTCP會采用與RTP相同的分發(fā)機(jī)制，向會話中的 所有成員周期性地發(fā)送控制信息，應(yīng)用程序通過接收這些數(shù)據(jù)，從中獲取會話參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進(jìn) 行控制或者對網(wǎng)絡(luò)狀況進(jìn)行診斷。

RTCP協(xié)議的功能是通過不同的RTCP數(shù)據(jù)報來實現(xiàn)的，主要有如下幾種類型：

SR：發(fā)送端報告，所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報的應(yīng)用程序或者終端，發(fā)送端同時也可以是接收端。(SERVER定時間發(fā)送給CLIENT)。

RR：接收端報告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報的應(yīng)用程序或者終端。(SERVER接收CLIENT端發(fā)送過來的響應(yīng))。

SDES：源描述，主要功能是作為會話成員有關(guān)標(biāo)識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達(dá)會話控制信息的功能。

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

APP：由應(yīng)用程序自己定義，解決了RTCP的擴(kuò)展性問題，并且為協(xié)議的實現(xiàn)者提供了很大的靈活性。

3：RTP數(shù)據(jù)協(xié)議

RTP數(shù)據(jù)協(xié)議負(fù)責(zé)對流媒體數(shù)據(jù)進(jìn)行封包并實現(xiàn)媒體流的實時傳輸，每一個RTP數(shù)據(jù)報都由頭部（Header）和負(fù)載（Payload）兩個部分組成，其中頭部前12個字節(jié)的含義是固定的，而負(fù)載則可以是音頻或者視頻數(shù)據(jù)。

RTP用到的地方就是 PLAY ，服務(wù)器往客戶端傳輸數(shù)據(jù)用UDP協(xié)議，RTP是在傳輸數(shù)據(jù)的前面加了個12字節(jié)的頭(描述信息)。

RTP載荷封裝設(shè)計本文的網(wǎng)絡(luò)傳輸是基于IP協(xié)議，所以最大傳輸單元(MTU)最大為1500字節(jié)，在使用IP／UDP／RTP的協(xié)議層次結(jié)構(gòu)的時候，這 其中包括至少20字節(jié)的IP頭，8字節(jié)的UDP頭，以及12字節(jié)的RTP頭。這樣，頭信息至少要占用40個字節(jié)，那么RTP載荷的最大尺寸為1460字 節(jié)。以H264 為例，如果一幀數(shù)據(jù)大于1460，則需要分片打包，然后到接收端再拆包，組合成一幀數(shù)據(jù)，進(jìn)行解碼播放。