5┃音視訊直播系統之 WebRTC 中的協議UDP、TCP、RTP、RTCP詳解

autofelix發表於2022-05-14

一、UDP/TCP

  • 如果讓你自己開發一套實時互動直播系統,在選擇網路傳輸協議時,你會選擇使用UDP協議還是TCP協議

  • 假如使用 TCP 會怎樣呢?在極端網路情況下,TCP 為了傳輸的可靠性,將會進行反覆重發資訊的操作

  • 在 TCP 協議中,為了避免重傳次數過多,定時器的超時時間會按 2 的指數增長,也就是說,假設第一次設定的超時時間是 1 秒,那麼第二次就是 2 秒,第三次是 4 秒……第七次是 64 秒。如果第七次之後仍然超時,則斷開 TCP 連線,而對於這麼長時間的延遲,實時互動的直播系統是根本無法接受的

  • 所以做線上直播系統時候一定要選擇 UDP 協議

 

二、RTP 協議

  • 在實時互動直播系統傳輸音視訊資料流時,我們並不直接將音視訊資料流交給UDP 傳輸,而是先給音視訊資料加個 RTP 頭,然後再交給 UDP 進行傳輸

  • 因為視訊資料在傳輸時,資料量太大,所以傳輸1幀可能需要幾十個包,而資料傳到接受端的時候,要將這幾十個包進行組裝,才能還原成完整的影像

  • 而RTP 協議就是為了然對接端組裝資料之後,順序不會亂而存在的,你想想,如果組裝的時候,順序亂了,組裝出來的影像還是傳輸過來的影像嗎

  • RTP 協議非常簡單,這裡對RTP進行簡單的介紹

  • sequence number:序號,用於記錄包的順序

  • timestamp:時間戳,同一個幀的不同分片的時間戳是相同的。不同幀的時間戳是不同的

  • PT:Payload Type,資料的負載型別。音訊流的 PT 值與視訊的 PT 值是不同的,通過它就可以知道這個包存放的是什麼型別的資料

  • SSRC:共享媒體流的源,它是全域性唯一的,不同的SSRC標識不同的共享源

  • CC:CSRC的個數

  • CSRC:共享源,一般用在混音或混屏上

  • X:RTP擴充套件頭標記,如果該位置是1,說明此RTP包還有擴充套件頭

  • M:表示MARK位,用來界定視訊幀邊界

  • P:填充位

 

三、RTP案例

  • 如果你在網路上接收了一組下面的音視訊資料

  • 假設 PT=80 是視訊資料,PT=100 是音訊資料

  • 按照上面的規則,是不是就很容易組裝資料了

{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:14,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:14,ts:123456789,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:15,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:15,ts:123456789,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:16,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:16,ts:123456789,ssrc=2345}

 

四、RTCP 協議

  • 在使用 RTP 包傳輸資料時,難免會發生丟包、亂序、抖動等問題

  • 比如:網路線路質量問題引起丟包率高、傳輸的資料超過了頻寬的負載引起的丟包問題等等

  • 而在處理這些問題之前,WebRTC首先要讓各端都知道它們自己的網路質量到底是怎樣的,這就是 RTCP 的作用

  • RTCP 有兩個最重要的報文RR(Reciever Report)SR(Sender Report)

  • 通過這兩個報文的交換,各端就知道自己的網路質量了

  • 該報文協議如下圖,其中欄位的含義:

  • V=2:指報文的版本。

  • P:表示填充位,如果該位置 1,則在 RTCP 報文的最後會有填充位元組

  • RC:全稱 Report Count,指 RTCP 報文中接收報告的報文塊個數

  • PT=200:Payload Type,也就是說 SR 的值為 200

  • Header:部分用於標識該報文的型別,比如是 SR 還是 RR

  • Sender info:部分用於指明作為傳送方,到底發了多少包

  • Report block:部分指明傳送方作為接收方時,它從各個 SSRC 接收包的情況

RTCP 協議規範圖

 

相關文章