Android IOS WebRTC 音視頻開發總結（八十六）-- WebRTC中RTP/RTCP協議實現分析

標籤：one   音視頻開發   uil   callback   擁塞控制   info   cat   線程   port   

 

本文主要介紹WebRTC中的RTP/RTCP協議，weizhenwei ，文章最早發表在編風網，ID：befoio

 

支援原創，轉載必須註明出處，歡迎關注我的公眾號blacker（ID：blackerteam 或 webrtcorgcn）。

 

一 前言

 

RTP/RTCP協議是流媒體通訊的基石。RTP協議定義流媒體資料在互連網上傳輸的資料包格式，而RTCP協議則負責可靠傳輸、流量控制和擁塞控制等服務品質保證。在WebRTC項目中，RTP/RTCP模組作為傳輸模組的一部分，負責對發送端採集到的媒體資料進行進行封包，然後交給上層網路模組發送；在接收端RTP/RTCP模組收到上層模組的資料包後，進行解包操作，最後把負載發送到解碼模組。因此，RTP/RTCP 模組在WebRTC通訊中發揮非常重要的作用。

 

本文在深入研究WebRTC原始碼的基礎上，以Video資料的發送和接收為例，力求用簡潔語言描述RTP/RTCP模組的實現細節，為進一步深入掌握WebRTC打下良好基礎。

 

二 RTP/RTCP協議概述

 

RTP協議是Internet上針對流媒體傳輸的基礎協議，該協議詳細說明在互連網上傳輸音視頻的標準資料包格式。RTP協議本身只保證即時資料的傳輸，RTCP協議則負責流媒體的傳輸品質保證，提供流量控制和擁塞控制等服務。在RTP會話期間，各參與者周期性彼此發送RTCP報文。報文中包含各參與者資料發送和接收等統計資訊，參與者可以據此動態控制流程媒體傳輸品質。

 

RFC3550 [1]定義RTP/RTCP協議的基本內容，包括報文格式、傳輸規則等。除此之外，IETF還定義一系列擴充協議，包括RTP協議基於檔次的擴充，和RTCP協議基於報文類型的擴充，等等。詳細內容可參考文獻[2]。

 

三 WebRTC線程關係和資料流

 

WebRTC對外提供兩個線程：Signal和Worker，前者負責信令資料的處理和傳輸，後者負責媒體資料的處理和傳輸。在WebRTC內部，有一系列線程各司其職，相互協作完成資料流管線。下面以Video資料的處理流程為例，說明WebRTC內部的線程合作關係。

 

圖1 WebRTC線程關係和資料管線

 

1所示，Capture線程從網路攝影機採集未經處理資料，得到VideoFrame；Capture線程是系統相關的，在Linux系統上可能是調用V4L2介面的線程，而在Mac系統上可能是調用AVFoundation架構的介面。接下來未經處理資料VideoFrame從Capture線程到達Worker線程，Worker線程起搬運工的作用，沒有對資料做特別處理，而是轉寄到Encoder線程。Encoder線程調用具體的編碼器(如VP8, H264)對未經處理資料VideoFrame進行編碼，編碼後的輸出進一步進行RTP封包形成RTP資料包。然後RTP資料包發送到Pacer線程進行平滑發送，Pacer線程會把RTP資料包推送到Network線程。最終Network線程調用傳輸層系統函數把資料發送到網路。

 

在接收端，Network線程從網路接收位元組流，接著Worker線程還原序列化為RTP資料包，並在VCM模組進行組幀操作。Decoder線程對組幀完成的資料幀進行解碼操作，解碼後的未經處理資料VideoFrame會推送到IncomingVideoStream線程，該線程把VideoStream投放到render進行渲染顯示。至此，一幀視頻資料完成從採集到顯示的完整過程。

 

在上述過程中，RTP資料包產生在發送端編碼完成後，其編碼輸出被封裝為RTP報文，然後經序列化發送到網路。在接收端由網路線程收到網路資料包後，經過還原序列化還原成RTP報文，然後經過解包得到媒體資料負載，供解碼器進行解碼。RTP報文在發送和接收過程中，會執行一系列統計操作，統計結果作為資料來源供構造RTCP報文之用。RTP報文構造、發送/接收統計和RTCP報文構造、解析反饋，是接下來分析的重點。

 

四 RTP報文發送和接收

 

RTP報文的構造和發送發生在編碼器編碼之後、網路層發送資料包之前，而接收和解包發生在網路層接收資料之後、解碼器編碼之前。本節詳細分析這兩部分的內容。

 

4.1 RTP報文構造和發送

 

圖2描述發送端編碼之後RTP報文的構造和發送過程，涉及三個線程：Encoder、Pacer和Network，分別負責編碼和構造RTP報文，平滑發送和傳輸層發送。下面詳細描述這三個線程的協同工作過程。

 

圖2 RTP報文構造和發送

 

Encode線程調用編碼器(比如VP8)對採集到的Raw VideoFrame進行編碼，編碼完成以後，其輸出EncodedImage通過回調到達VideoSendStream::Encoded()函數，進而通過PayloadRouter路由到ModuleRtpRtcpImpl::SendOutgoingData()。接下來，該函數向下調用RtpSender::SendOutgoingData()，進而調用RtpSenderVideo::SendVideo()。該函數對EncodedImage進行打包，然後填充RTP頭部構造RTP報文；如果配置了FEC，則進一步封裝為FEC報文。最後返回RtpSender::SendToNetwork()進行下一步發送。

 

RtpSender::SendToNetwork()函數把報文儲存到RTPPacketHistory結構中進行緩衝。接下來如果開啟PacedSending，則構造Packe發送到PacedSender進行排隊，否則直接發送到網路層。

 

Pacer線程周期性從隊列中擷取Packet，然後調用PacedSender::SendPacket()進行發送，接下來經過ModuleRtpRtcpImpl到達RtpSender::TimeToSendPacket()。該函數首先從RtpPacketHistory緩衝中拿到Packet的負載，然後調用PrepareAndSendPacket()函數：更新RtpHeader的相關域，統計延遲和資料包，調用SendPacketToNetwork()把報文發送到傳輸模組。

 

Network線程則調用傳輸層通訊端執行資料發送操作。至此，發送端的RTP構造和發送流程完成。需要注意的是，在RtpSender中進行Rtp發送後，會統計RTP報文相關資訊。這些資訊作為RTCP構造SR/RR報文的資料來源，因此非常重要。

 

4.2 RTP報文接收和解析

 

在接收端，RTP報文的接收和解包操作主要在Worker線程中執行，RTP報文從Network線程拿到後，進入Worker線程，經過解包操作，進入VCM模組，由Decode線程進行解碼，最終由Render線程進行渲染。3描述RTP報文在Worker線程中的處理流程。

圖3 RTP報文接收和解析

 

RTP資料包經網路層到達Call對象，根據其SSRC找到對應的VideoReceiveStream，通過調用其DeliverRtp()函數到RtpStreamReceiver::DeliverRtp()。該函數首先解析資料包得到RTP頭部資訊，接下來執行三個操作：1.碼率估計；2.繼續發送資料包；3.接收統計。碼率估計模組使用GCC演算法估計碼率，構造REMB報文，交給RtpRtcp模組發送回傳送端。而接收統計則統計RTP接收資訊，這些資訊作為RTCP RR報文的資料來源。下面重點分析接下來的資料包發送流程。

 

RtpStreamReceiver::ReceivePacket()首先判斷資料包是否是FEC報文，如果是則調用FecReceiver進行解包，否則直接調用RtpReceiver::IncomingRtpPacket()。該函數分析RTP報文得到通用的RTP頭部描述結構，然後調用RtpReceiverVideo::ParseRtpPacket()進一步得到Video相關資訊和負載，接著經過回調返回RtpStreamReceiver對象。該對象把Rtp描述資訊和負載發送到VCM模組，繼續接下來的JitterBuffer緩衝和解碼渲染操作。

 

RTP報文解包過程是封包的逆過程，重要的輸出資訊是RTP頭部描述和媒體負載，這些資訊是下一步JitterBuffer緩衝和解碼的基礎。另外對RTP報文進行統計得到的資訊則是RTCP RR報文的資料來源。

 

五 RTCP報文發送和接收

 

RTCP協議是RTP協議的控制下可以，負責流媒體的服務品質保證。比較常用的RTCP報文由發送端報告SR和接收端報告RR，分別包含資料發送統計資訊和資料接收資訊。這些資訊對於流媒體品質保證非常重要，比如碼率控制、負載反饋，等等。其他RTCP報文還有諸如SDES、BYE、SDES等，RFC3550對此有詳細定義。

 

本節重點分析WebRTC內部RTCP報文的構造、發送、接收、解析、反饋等流程。需要再次強調的是，RTCP報文的資料來源來自RTP報文發送和接收時的統計資訊。在WebRTC內部，RTCP報文的發送採取周期性發送和及時發送相結合的策略：ModuleProcess線程周期性發送RTCP報文；而RtpSender則在每次發送RTP報文之前都判斷是否需要發送RTCP報文；另外在接收端碼率估計模組構造出REMB報文後，通過設定逾時讓ModuleProcess模組立即發送RTCP報文。

 

5.1 RTCP報文構造和發送

 

在發送端，RTCP以周期性發送為基準，輔以RTP報文發送時的及時發送和REMB報文的立即發送。發送過程主要包括Feedback資訊擷取、RTCP報文構造、序列化和發送。圖4描述了RTCP報文的構造和發送過程。

圖4 RTCP報文構造和發送

 

ModuleProcess線程周期性調用ModuleRtpRtcpImpl::Process()函數，該函數通過RTCPSender::TimeToSendRtcpReport()函數確定當前是否需要立即發送RTCP報文。若是，則首先從RTPSender::GetDataCounters()擷取RTP發送統計資訊，然後調用RTCPSender::SendRTCP()，接著是SendCompoundRTCP()發送RTCP組合報文。關於RTCP組合報文的定義，請參考文獻[1]。

 

在SendCompoundRTCP()函數中，首先通過PrepareReport()確定將要發送何種類型的RTCP報文。然後針對每一種報文，調用其建構函式(如構造SR報文為BuildSR()函數)，構造好的報文儲存在PacketContainer容器中。最後調用SendPackets()進行發送。

接下來每種RTCP報文都會調用各自的序列化函數，把報文序列化為網路位元組流。最後通過回調到達PacketContainer::OnPacketReady()，最終把位元組流發送到傳輸層模組：即通過TransportAdapter到達BaseChannel，Network線程調用傳輸層通訊端API發送資料到網路。

 

RTCP報文的構造和發送過程總體不是很複雜，最核心的操作就是擷取資料來源、構造報文、序列化和發送。相對來說構造報文和序列化比較繁瑣，基於RFC定義的細節進行。

 

5.2 RTCP報文接收和解析

 

接收端的RTCP報文接收和解析過程5所示。

圖5 RTCP報文接收和解析

 

在接收端，RTCP報文的接收流程和RTP一樣，經過網路接收之後到達Call對象，進而通過SSRC找到VideoReceiveStream，繼而到達RtpStreamReceiver。接下來RTCP報文的解析和反饋操作都在ModuleRtpRtcpImpl::IncomingRtcpPacket()函數中完成。該函數首先調用RTCPReceiver::IncomingRtcpPacket()解析RTCP報文，得到RTCPPacketInformation對象，然後調用 TriggerCallbacksFromRTCPPacket()，觸發註冊在此處的各路觀察者執行回調操作。

 

RTCPReceiver::IncomingRtcpPacket()使用RTCPParser解析組合報文，針對每一種報文類型，調用對應的處理函數(如處理SDES的HandleSDES函數)，還原序列化後拿到報文的描述結構。最後所有報文綜合在一起形成RTCPPacketInformation對象。該對象接下來作為參數調用TriggerCallbacksFromRTCPPacket()函數觸發回調操作，如處理NACK的回調，處理SLI的回調，處理REMB的回調，等等。這些回調在各自模組控制流程媒體資料的編碼、發送、碼率等服務品質保證，這也是RTCP報文最終起作用的地方。

 

至此，我們分析了RTCP報文發送和接收的整個流程。

 

六 總結

 

本文在深入分析WebRTC原始碼的基礎上，結合流程圖描述出RTP/RTCP模組的實現流程，在關鍵問題上(如RTCP報文的資料來源)進行深入細緻的研究。為進一步深入掌握WebRTC的實現原理和細節打下良好基礎。

 

 

參考文獻

 

[1] RFC3550 - RTP: A Transport Protocol for Real-Time Applications
https://www.ietf.org/rfc/rfc3550.txt

[2] 超越RFC3550 － RTP/RTCP協議族分析 : http://www.jianshu.com/p/e5e21aeb219f

 

Android IOS WebRTC 音視頻開發總結（八十六）-- WebRTC中RTP/RTCP協議實現分析