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

共同點：

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

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（路由選擇表維護協(xié)議）。

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

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

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

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é)議

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

2：RTCP控制協(xié)議

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

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

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

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

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

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

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

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

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

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

RTP載荷封裝設計本文的網(wǎng)絡傳輸是基于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ù)，進行解碼播放。

直播應用中，RTMP和HLS基本上可以覆蓋所有客戶端觀看，

HLS主要是延時比較大，RTMP主要優(yōu)勢在于延時低。

一、應用場景

低延時應用場景包括：

 .  互動式直播：譬如美女主播，游戲直播等等

    各種主播，流媒體分發(fā)給用戶觀看。用戶可以文字聊天和主播互動。

 .  視頻會議：我們要是有出差在外地，就用視頻會議開內(nèi)部會議。

    其實會議1秒延時無所謂，因為人家講完話后，其他人需要思考，

    思考的延時也會在1秒左右。當然如果用視頻會議吵架就不行。

 .  其他：監(jiān)控，直播也有些地方需要對延遲有要求，

    互聯(lián)網(wǎng)上RTMP協(xié)議的延遲基本上能夠滿足要求。

二、RTMP和延時

1. RTMP的特點如下：

1) Adobe支持得很好：

  RTMP實際上是現(xiàn)在編碼器輸出的工業(yè)標準協(xié)議，基本上所有的編碼器（攝像頭之類）都支持RTMP輸出。

  原因在于PC市場巨大，PC主要是Windows，Windows的瀏覽器基本上都支持flash，

  Flash又支持RTMP支持得非常好。

2) 適合長時間播放：

  因為RTMP支持的很完善，所以能做到flash播放RTMP流長時間不斷流，

  當時測試是100萬秒，即10天多可以連續(xù)播放。

  對于商用流媒體應用，客戶端的穩(wěn)定性當然也是必須的，否則最終用戶看不了還怎么玩？

  我就知道有個教育客戶，最初使用播放器播放http流，需要播放不同的文件，結(jié)果就總出問題，

  如果換成服務器端將不同的文件轉(zhuǎn)換成RTMP流，客戶端就可以一直播放；

  該客戶走RTMP方案后，經(jīng)過CDN分發(fā)，沒聽說客戶端出問題了。

3）延遲較低：

  比起YY的那種UDP私有協(xié)議，RTMP算延遲大的（延遲在1-3秒），

  比起HTTP流的延時（一般在10秒以上）RTMP算低延時。

  一般的直播應用，只要不是電話類對話的那種要求，RTMP延遲是可以接受的。

  在一般的視頻會議應用中，RTMP延時也能接受，原因是別人在說話的時候我們一般在聽，

  實際上1秒延時沒有關系，我們也要思考（話說有些人的CPU處理速度還沒有這么快）。

4) 有累積延遲：

  技術一定要知道弱點，RTMP有個弱點就是累積誤差，原因是RTMP基于TCP不會丟包。

  所以當網(wǎng)絡狀態(tài)差時，服務器會將包緩存起來，導致累積的延遲；

  待網(wǎng)絡狀況好了，就一起發(fā)給客戶端。

  這個的對策就是，當客戶端的緩沖區(qū)很大，就斷開重連。

2. HLS低延時

主要有人老是問這個問題，如何降低HLS延遲。

HLS解決延時，就像是爬到楓樹上去捉魚，奇怪的是還有人喊，看那，有魚。

你說是怎么回事?

我只能說你在參與謙哥的魔術表演，錯覺罷了。

如果你真的確信有，請用實際測量的圖片來展示出來，參考下面延遲的測量。

3. RTMP延遲的測量

如何測量延時，是個很難的問題，

不過有個行之有效的方法，就是用手機的秒表，可以比較精確的對比延時。

經(jīng)過測量發(fā)現(xiàn)，在網(wǎng)絡狀況良好時：

RTMP延時可以做到0.8秒左右。

 . 多級邊緣節(jié)點不會影響延遲（和SRS同源的某CDN的邊緣服務器可以做到）

 . Nginx-Rtmp延遲有點大，估計是緩存的處理，多進程通信導致？

 . GOP是個硬指標，不過SRS可以關閉GOP的cache來避免這個影響.

 . 服務器性能太低，也會導致延遲變大，服務器來不及發(fā)送數(shù)據(jù)。

 . 客戶端的緩沖區(qū)長度也影響延遲。

   譬如flash客戶端的NetStream.bufferTime設置為10秒，那么延遲至少10秒以上。

4. GOP-Cache

什么是GOP？就是視頻流中兩個I幀的時間距離。

GOP有什么影響？

Flash（解碼器）只有拿到GOP才能開始解碼播放。

也就是說，服務器一般先給一個I幀給Flash。

可惜問題來了，假設GOP是10秒，也就是每隔10秒才有關鍵幀，

如果用戶在第5秒時開始播放，會怎么樣？

第一種方案：等待下一個I幀，

也就是說，再等5秒才開始給客戶端數(shù)據(jù)。

這樣延遲就很低了，總是實時的流。

問題是：等待的這5秒，會黑屏，現(xiàn)象就是播放器卡在那里，什么也沒有，

有些用戶可能以為死掉了，就會刷新頁面。

總之，某些客戶會認為等待關鍵幀是個不可饒恕的錯誤，延時有什么關系？

我就希望能快速啟動和播放視頻，最好打開就能放！

第二種方案：馬上開始放，

放什么呢？

你肯定知道了，放前一個I幀。

也就是說，服務器需要總是cache一個gop，

這樣客戶端上來就從前一個I幀開始播放，就可以快速啟動了。

問題是：延遲自然就大了。

有沒有好的方案？

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

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

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

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


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

凱茉銳4K模組攝像機-CM-8420-SHE  20倍光學變焦，16倍數(shù)字變焦 829萬逐行掃描1/1.8”CMOS 最大分辨率可達3840X2160，可以人臉偵測、

區(qū)域入侵偵測、越界偵測、進入?yún)^(qū)域偵測、離開區(qū)域偵測、徘徊偵測、人員聚集偵測、物品遺留偵測、物品拿取偵測、音頻異常偵測、移動偵測