# 網路流媒體協議的聯絡與區別(RTP RTCP RTSP RTMP HLS) [toc] --- # 三句話簡結 ## 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實際上為視訊程式的開發者提供了一個開發平臺。 RTP也可以理解為運輸層協議，實際上RTP協議偏重於傳輸層，是UDP協議（使用者資料報）上邊的一層協議。因為RTP封裝了多媒體應用（包括視訊流、音訊流）的資料塊，關鍵是提供運輸層的服務（時間戳，序號、同步源識別符號等），因此可以把RTP看成一層UDP上的運輸層子層協議，特別要注意是子層協議。 綜合來看，RTP協議實際上是一個介於傳輸層和應用層之間的協議，作用是在UDP協議之上完成一次對媒體流的封裝。 # 基於RTP的流式媒體 流式傳輸是實現流媒體的關鍵技術。使用流式傳輸可以邊下載邊觀看流媒體節目。由於Internet是基於分組傳輸的，所以接收端收到的資料包往往有延遲和亂序(流式傳輸構建在UDP上) 要實現流式傳輸，就要從降低延遲和恢復資料包時序入手。 **`「在傳送端，為降低延遲，往往對傳輸資料進行預處理(降低質量和高效壓縮(常見壓縮格式如aac/h264...))」`** **`「在接收端為了恢復時序，常採用接收緩衝，而為了實現媒體的流暢播放，一般會使用播放緩衝」`** ## 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。 ```cpp 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](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以上)。 三種協議各有各的優勢，主要還是看場景選擇，當然大點公司，可以做些私有協議來提供更好更符合場景的