當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

网络流媒体协议的联系与区别(RTP RTCP RTSP RTMP HLS)

發布時間：2023/12/29 编程问答 28 豆豆

生活随笔收集整理的這篇文章主要介紹了网络流媒体协议的联系与区别(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實際上為視頻程序的開發者提供了一個開發平臺。

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。

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類

文章最后掃碼進qun，免費領取音視頻學習資料包，資料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）

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 區別與聯系

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以上)。

三種協議各有各的優勢，主要還是看場景選擇，當然大點公司，可以做些私有協議來提供更好更符合場景的服務。

參考：
RFC3550
維基百科

總結

以上是生活随笔為你收集整理的网络流媒体协议的联系与区别(RTP RTCP RTSP RTMP HLS)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。