網絡流媒體協議的聯繫與區別(RTP RTCP RTSP RTMP HLS)

時間 2020-03-08

標籤網絡媒體協議聯繫區別 rtp rtcp rtsp rtmp hls 欄目系統網絡简体版

原文原文鏈接

目錄瀏覽器

網絡流媒體協議的聯繫與區別(RTP RTCP RTSP RTMP HLS)

三句話簡結

RTP RTCP RTSP RTMP HLS區別與聯繫

RTP傳輸流媒體數據、RTCP對RTP進行控制，同步、RTSP發起/終止流媒體
RTP和RTCP互爲姐妹關係，RTSP可使用RTP來傳輸數據，但並無綁定關係也可使用TCP/UDP
RTSP、RTMP、HLS均可以作直播和點播，它們是三種不一樣的應用層協議服務器

流媒體各協議層次圖

關於RTP(RTCP)協議位置的理解：
RTP實際上介於應用層和傳輸層之間。同時具備應用層和傳輸層的各類特色。這個特色須要仔細甄別。網絡

從應用開發者的角度看，RTP應該是應用層的一個部分。在應用程序的發送端，開發者必須編寫用RTP封裝分組（數據包）的程序代碼，而後把該RTP分組交給UDP套接字接口。在接收端設備，RTP分組經過UDP套接字接口進入應用層程序後，會利用開發者編寫的程序代碼把RTP分組從應用數據塊提取出來。RTP實際上爲視頻程序的開發者提供了一個開發平臺。tcp

RTP也能夠理解爲運輸層協議，實際上RTP協議偏重於傳輸層，是UDP協議（用戶數據報）上邊的一層協議。由於RTP封裝了多媒體應用（包括視頻流、音頻流）的數據塊，關鍵是提供運輸層的服務（時間戳，序號、同步源標識符等），所以能夠把RTP當作一層UDP上的運輸層子層協議，特別要注意是子層協議。加密

綜合來看，RTP協議其實是一個介於傳輸層和應用層之間的協議，做用是在UDP協議之上完成一次對媒體流的封裝。url

基於RTP的流式媒體

流式傳輸是實現流媒體的關鍵技術。使用流式傳輸能夠邊下載邊觀看流媒體節目。因爲Internet是基於分組傳輸的，因此接收端收到的數據包每每有延遲和亂序(流式傳輸構建在UDP上)插件

要實現流式傳輸，就要從下降延遲和恢復數據包時序入手。ssr

「在發送端，爲下降延遲，每每對傳輸數據進行預處理(下降質量和高效壓縮(常見壓縮格式如aac/h264...))」3d

「在接收端爲了恢復時序，常採用接收緩衝，而爲了實現媒體的流暢播放，通常會使用播放緩衝」代理

RTP

RTP(Real-time Transport Protocol)協議建立在UDP協議上常配合RTSP和RTCP一塊兒使用。用於實時傳輸網絡中的多媒體數據，提供端到端的實時傳輸服務，但並不保證服務質量，服務質量由RTCP來提供。

RTP是流媒體協議族中最基礎的一個協議了，它是IETF提出的一個標準，對應RFC文檔RFC3550，RFC3550不只定義了RTP還定義了配套相關協議RTCP。

RTP協議主要職責就是負責流媒體數據包和媒體流的實時傳輸，每一個RTP數據報文由頭(header)和裝載(Payload)兩部分組成，其中頭的前12個字節的含義是固定的，裝載的數據能夠是音頻或視頻數據。RTP數據報的報頭格式以下所示:

「能夠將RTP比做一輛貨車，貨車裏面能夠隨意裝東西，可是容積有限制，若是太大你就須要分包，一輛一輛裝車發送過，另外可能也不必定按序到達對端，甚至可能失蹤」

RTP載荷類型
由於有些類型因爲誕生的較晚，沒有具體的PT值，只能使用動態（dynamic）PT值，即96-127，這就是爲何你們廣泛指定H264的PT值爲96。

rtp_payload_types[] = {
  {0, "PCMU",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_MULAW, 8000, 1},
  {3, "GSM",         AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},
  {4, "G723",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_G723_1, 8000, 1},
  {5, "DVI4",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},
  {6, "DVI4",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 16000, 1},
  {7, "LPC",         AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},
  {8, "PCMA",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_ALAW, 8000, 1},
  {9, "G722",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_ADPCM_G722, 8000, 1},
  {10, "L16",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_S16BE, 44100, 2},
  {11, "L16",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_S16BE, 44100, 1},
  {12, "QCELP",      AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_QCELP, 8000, 1},
  {13, "CN",         AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},
  {14, "MPA",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_MP2, -1, -1},
  {14, "MPA",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_MP3, -1, -1},
  {15, "G728",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},
  {16, "DVI4",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 11025, 1},
  {17, "DVI4",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 22050, 1},
  {18, "G729",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},
  {25, "CelB",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_NONE, 90000, -1},
  {26, "JPEG",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_MJPEG, 90000, -1},
  {28, "nv",         AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_NONE, 90000, -1},
  {31, "H261",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_H261, 90000, -1},
  {32, "MPV",        AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_MPEG1VIDEO, 90000, -1},
  {32, "MPV",        AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_MPEG2VIDEO, 90000, -1},
  {33, "MP2T",       AVMEDIA_TYPE_DATA,    AV_CODEC_ID_MPEG2TS, 90000, -1},
  {34, "H263",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_H263, 90000, -1},
  {-1, "",           AVMEDIA_TYPE_UNKNOWN, AV_CODEC_ID_NONE, -1, -1}
};

RTCP

RTCP(Real-time Transport Control Protocol或RTP Control Protocol）是實時傳輸協議（RTP）的一個姐妹協議。

RTCP常與RTP聯合工做，RTP實施實際數據的傳輸，RTCP則負責將控制包送至電話中的每一個人。其主要功能就是爲RTP提供的服務質量作出反饋,同時同步音視頻數據，它自己沒不傳遞任何數據。它們能以有效的反饋和最小的開銷使傳輸效率最佳化，於是特別適合傳送網上的實時數據。

在RTP會話期間，各參與者週期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，所以，服務器能夠利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。

RTCP根據所攜帶的控制信息不一樣RTCP信息包可分爲RR (接收者報告包)、SR (源報告包)、SE
DS (源描述包)、BYE (離開申明)和APP (特殊應包)5類

RTSP

實時流協議（RTSP，Real-time Streaming Protocol）是一種用於控制聲音或圖像的流媒體議，而且容許控制多條流，但RTSP鏈接並無被綁定傳輸層的鏈接（如RTP），服務器甚至能夠選擇TCP或者UDP來傳輸流內容。

它的語法相似於HTTP 1.1，但不強調時間的同步，所以比較能夠容忍網絡延遲，是一種基於文本的多媒體播放控制協議。RTSP定義流格式，流數據可經由RTP傳輸；因此RTSP的實時效果很是好，適合視頻聊天，視頻監控等方向。

RTSP的請求主要包括，如「描述(describe),設置(setup),播放(play),暫停(pause),回放(teardown),選項(options)」等，在RTSP對話期間，Setup能夠指定RTP/RTCP使用的端口，「play，pause，teardown」能夠開始和暫停RTP的發送。

RTSP請求例

SETUP 請求
SETUP請求指定如何傳輸單個媒體流。這必須在發送PLAY請求以前完成。請求包含媒體流URL和傳輸說明符。該說明符一般包括用於接收RTP數據（音頻或視頻）的本地端口，另外一個用於RTCP數據（元信息））。服務器回覆一般會確認所選參數，並填寫缺乏的部分，例如服務器選擇的端口。必須在發送聚合播放請求以前，使用SETUP配置每一個媒體流。

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001

S->C: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
Session: 12345678

Play 播放請求
Play 播放請求將致使播放一個或全部媒體流。能夠經過發送多個播放請求來堆疊播放請求。URL能夠是聚合URL（播放全部媒體流）或單個媒體流URL（僅播放該流）。能夠指定範圍。若是沒有指定範圍，流將從頭開始播放，並播放到最後，或者若是流暫停，則在暫停點恢復播放。

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Range: npt=5-20
Session: 12345678

S->C: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

PAUSE 暫停請求
PAUSE 暫停請求暫時中止一個或全部媒體流，所以稍後能夠經過播放請求恢復。請求包含聚合或媒體流URL。PAUSE請求中的範圍參數指定什麼時候暫停。當省略範圍參數時，暫停會當即無限期地發生。

C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 5
Session: 12345678

S->C: RTSP/1.0 200 OK
CSeq: 5
Session: 12345678

RTMP

RTMP(Real Time Messaging Protocol)實時消息傳送協議是Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開放應用層協議.

RTMP傳輸層是TCP協議，不過這種可靠的保障也會形成一些問題，也就是說前面的數據包沒有交付到目的地，後面的數據也沒法進行傳輸。幸運的是，目前的網絡帶寬基本上能夠知足RTMP協議傳輸普通質量視頻的要求，並且通常延遲在延遲在1-3秒內。

RTMP傳輸的數據的基本單元爲Message，可是實際上傳輸的最小單元是Chunk（消息塊），由於RTMP協議爲了提高傳輸速度，在傳輸數據的時候，會把Message拆分開來，造成更小的塊，這些塊就是Chunk。

RTMP擴展

RTMP是一個協議族，包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種：

・工做在TCP之上的明文協議，使用端口1935；
・RTMPE在RTMP的基礎上增長了加密功能；
・RTMPT封裝在HTTP請求之中，可穿越防火牆；
・RTMPS相似RTMPT，但使用的是HTTPS鏈接；

RTMP協議(Real Time Messaging Protocol)是被Flash用於對象,視頻,音頻的傳輸.這個協議創建在TCP協議或者輪詢HTTP協議之上.

RTMP協議就像一個用來裝數據包的容器,這些數據既能夠是AMF格式的數據,也能夠是FLV中的視/音頻數據.一個單一的鏈接能夠經過不一樣的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸的.

HLS

HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用在iOS系統，爲iOS設備（如iPhone、iPad）提供音視頻直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不一樣在於，它的分段很是小。

相對於常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不一樣在於，「直播客戶端獲取到的，並非一個完整的數據流。HLS協議在服務器端將直播數據流存儲爲連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載並播放這些小文件，由於服務器端老是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。」
因而可知，基本上能夠認爲，HLS是以點播的技術方式來實現直播。因爲數據經過HTTP協議傳輸，因此徹底不用考慮防火牆或者代理的問題，並且分段文件的時長很短，客戶端能夠很快的選擇和切換碼率，以適應不一樣帶寬條件下的播放。不過HLS的這種技術特色，決定了它的延遲通常老是會高於普通的流媒體直播協議。　

HLS提供一個m3u8地址，Apple的Safari瀏覽器直接就能打開m3u8地址，譬如
香港衛視:http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8

總結

RTP RTCP RTSP 區別與聯繫

RTP傳輸流媒體數據、RTCP對RTP進行控制，同步、RTSP發起/終止流媒體
RTP和RTCP互爲姐妹關係，RTSP可使用RTP來傳輸數據，但並無綁定關係也可使用TCP/UDP
RTSP、RTMP、HLS均可以作直播和點播，它們是三種不一樣的應用層協議

RTSP、RTMP、HLS 區別與聯繫

RTSP、RTMP、HLS均可以作直播和點播，它們是三種不一樣的應用層協議

・HLS 延遲大，適合視頻點播
・RTSP實時性最好，可是實現複雜，適合視頻聊天和視頻監控
・RTMP強在瀏覽器支持好，加載flash插件後就能直接播放，很是火，相反在瀏覽器裏播放rtsp就很困難了

關於直播

直播應用中，RTMP和HLS基本上能夠覆蓋全部客戶端觀看。

・RTSP優點主要在於傳輸層可使用udp/rtp，實時性好，延遲可控制到1s內，
・RTMP主要優點在於延時相對較低(1-3s)，並且RTMP支持的很完善，能作到flash播放RTMP流長時間不斷流，之前不少SIP的視頻會議已被RTMP所取代。
・HLS的優點就是直接使用http協議請求流數據，能夠在不一樣速率的版本間自由切換，實現無縫播放，缺點是延時比較大(10s以上)。

三種協議各有各的優點，主要仍是看場景選擇，固然大點公司，能夠作些私有協議來提供更好更符合場景的服務。