基于RTP協議的移動視頻監控系統的設計

許 寧

(廈門雅迅網絡股份有限公司，福建廈門361008)

0 引言

隨著移動通信技術的迅速發展，特別是3G、4G移動通信網絡技術的成熟和商業化運營，多媒體業務在無線通信領域快速成長，典型應用之一即為無線移動視頻監控。相比有線網絡，在無線移動網絡環境下，通信終端位置不再固定不變，網絡的傳輸環境更加不穩定，視頻監控所要面對的數據量大、實時性要求高與網絡帶寬不足或不穩定之間的矛盾更加突出。如何根據移動通信網絡的有效傳輸帶寬的動態變化，實時調整視頻數據的發送速率，以獲得最佳的視頻監控效果，是一個廣泛研究的課題。

1 技術原理

1.1 H.264編碼

H.264編碼是一種面向宏塊的基于運動補償的視頻編解碼標準，由ITU－T視頻編碼專家組與ISO/IEC動態圖像專家組(MPEG)——聯合組成的聯合視頻組(JVT，Joint Video Team)開發，也即MPEG－4第10部分標準。在同等圖像質量的條件下，H.264的壓縮比是 MPEG－2的2倍以上，是MPEG－4的1.5～2倍，傳輸時需要的帶寬更小，但仍然保持了較高的圖像質量，在不穩定、高誤碼率的無線移動通信網絡環境下有良好的適應能力。

H.264編碼在結構上分為2層:視頻編碼層(VCL，Video Coding Layer)和網絡提取層(NAL，Network Abstraction Layer)。VCL承載的是視頻編碼數據，NAL負責對數據進行打包和傳送。這樣的分層結構有利于信息的封裝，傳輸時也不依賴特定的的信道和介質。H.264的另一大改進，是將幀級結構進一步劃分——圖像幀由一個或多個片(Slice)組成［1］，片封裝在NAL單元中。片具有一定的獨立性，其中I片可單獨解碼，而不需要依賴其他片，這樣就提高了碼流整體的抗丟包、抗誤碼能力。

NAL單元由單元頭(1字節)和載荷數據組成。單元頭指示了載荷數據的類型等信息。載荷數據可以是圖像編碼片，也可以是其他編碼信息，如序列參數集、圖像參數集、附加增強信息、定界符、分割符、結束符等。

視頻幀分為I幀、P幀、B幀。I幀采用幀內編碼技術，帶有全部解碼信息，能生成一幅完整圖片的獨立幀，數據量較大;P幀，采用單向幀間預測編碼，需要參考前面的I幀或P幀進行解碼，數據量較小，且易受到參考幀誤碼或丟失的影響而不能正常解碼;B幀，采用雙向幀間預測編碼，需要其前面和后面的幀作為參考幀。IDR幀是一種特殊的I幀，其后的P幀、B幀，不再以該IDR幀之前的任何幀為參考幀。這意味著，如果碼流有任何錯誤，從一個新的IDR幀開始可以重新完整解碼。B幀不是必須幀;P幀也不是必須幀，但一般不可少;I幀/IDR幀必不可少。

一個典型的H.264碼流結構示例如圖1所示。

圖1 H.264碼流結構示例Fig.1 Example for H.264 coded data structure

在圖1中，從IDR幀開始到下一個IDR幀之前的數據，稱為一個視頻序列。在視頻序列內，一部分數據的丟失，將影響其所在幀和后續幀的解碼，表現為圖像的缺失、殘像、馬賽克等現象。然而，無論前一個視頻序列丟失多少數據，從下一個視頻序列開始，總能重新開始完整的解碼。為了改善視頻監控時由于錯誤解碼導致的不良用戶體驗，當解碼器收到一個不完整的視頻序列時，可以丟棄該視頻序列中因為缺失參考幀信息而無法正確解碼的數據，付出的代價是可能出現不連貫的圖像。

1.2 RTP/RTCP 協議

RTP，全稱是 Real－time Transport Protocol，即實時傳輸協議。它是由IETF的多媒體傳輸工作小組提出的傳輸標準，目前最新的版本為RFC3550。

RFC3550實際描述了兩個關系密切的子協議:RTP和 RTCP。RTCP全稱是 RTP Control Protocol，即RTP控制協議。其中，RTP協議用于實時數據的傳輸，但不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制［2］。RTCP協議則負責傳遞網絡的QoS(Quality of Service，服務質量)信息，并且傳送參與多媒體數據收發者的信息。使用者可根據RTCP協議傳遞的網絡傳輸質量信息，動態調整單位時間傳輸的數據量，實現流量控制和擁塞控制，以適應網絡環境的變化。

RTP/RTCP協議，是建立在傳輸層協議之上的協議，其所依托的傳輸層協議，通常是UDP協議。各協議層次關系如圖2所示。

圖2 RTP/RTCP與其他協議層次關系示意Fig.2 Hierarchical relationship between RTP/RTCP and other protocols

按照規范，RTP使用偶數端口，配對的RTCP協議使用緊隨其后的奇數端口。

鏈路層的載荷數據有最大傳輸單元(MTU，Maximum Transmission Unit)大小限制，超過限制無法傳輸，因此網絡層協議在將數據傳入鏈路層之前，若發現會導致鏈路層載荷數據長度超過MTU限制，則先將數據分成若干數據片(數據片長度滿足MTU限制約束)，再將數據片交鏈路層發送。接收方在收到全部網絡層數據片后按原順序重組，只要有一個數據片未接收完整則無法還原，表現為整個數據包的丟失。因此，為了降低數據的丟失概率，應對每次發送的RTP/RTCP數據長度進行限制，以確保網絡層處理時不進行分片操作。按照以太網的一般限制，RTP/RTCP包大小不能超過1 472字節。實際上，網絡傳輸路徑上的某些節點對MTU的實際限制可能更低，RTP/RTCP數據包大小可能需要進一步降低，可參照RFC1191的描述，使用ping命令(參數為不允許分片)探索和確認網絡傳輸路徑的MTU值。

傳輸時，視頻編碼數據作為RTP協議的負載字段填入。為了確保RTP包不超過上述限制，有2種方法:方法1，當編碼器輸出的NAL單元超長時，可以在應用層將NAL單元分片，打入序列號連續遞增的多個RTP包，RFC3984對此進行了描述和規范;方法2，對編碼器配置輸出NAL單元的長度限制，使得一個較長的NAL單元被編碼器自動拆分為多個較短的NAL單元輸出，這需要編碼器支持。

接收方根據RTP數據包中的序列號信息對數據排序重組，并結合來自發送方的SR包(RTCP數據)判斷丟包情況;RTP和RTCP數據中還包含時間戳信息，接收方可分析時間戳信息判斷數據傳輸的延遲和抖動情況。根據數據的丟包和延時抖動情況，可判斷網絡QoS的變化情況，從而調整數據傳輸速率，適應網絡帶寬變化。發送速率調整算法一般使用加性增加乘性減小［3］(AIMD，Additive Increase and Multiplicative Decrease)。

2 系統的實現

移動視頻監控系統，由視頻采集終端(以下簡稱終端)、監控平臺(以下簡稱平臺)，以及它們之間的通信網絡組成，結構示意圖如圖3所示。

圖3 移動視頻監控系統結構Fig.3 Mobile video monitor system structure

終端采集視頻圖像，經壓縮編碼后得到H.264數據，使用RTP協議封裝和發送，傳輸層使用UDP協議。終端數據的上傳，經過3G/4G移動通信網絡進入Internet，最后到達平臺。平臺解析RTP數據包，提取出H.264數據，解碼并播放;同時，終端定期發送RTCP協議封裝的SR包(發送者報告)到平臺，平臺對收到的RTP數據和SR包進行分析統計，得到丟包率等信息，并生成RTCP協議的RR包(接收者報告)反饋到終端。本例中，終端僅根據RR包中的丟包率信息評估有效帶寬的變化，然后調整編碼輸出碼率達到調整發送速率的效果，以適應動態變化的網絡環境。

2.1 視頻采集終端

視頻編碼芯片選用海思Hi3511。Hi3511同時具有通用CPU的處理功能，內核為ARM926EJ－S，是32位 RISC處理器，工作頻率達264 MHz，有16KB指令 Cache和16KB數據Cache，支持 H.264視頻編解碼，具備320fps@CIF編解碼能力，運行的操作系統是Linux。視頻采集芯片使用Techwell公司的TW2685，作用是將攝像頭輸出的CVBS信號，轉換為BT.656信號輸入Hi3511進行編碼。通信模組使用SIMCom公司的SIM5218，傳輸網絡為WCDMA。

Hi3511支持NAL單元長度限制，在視頻幀較長時編碼器可自動拆分為多個NAL單元輸出。使用時，設定輸出的NAL單元限制長度為650字節。實際輸出的NAL單元長度有時會超過該限制值，經測試最長不會超過1 300字節。

為了接收方更好地分辨收到的RTP數據是否同屬一幀，進一步判斷一幀或者一個視頻序列是否接收完整，實現時，在RTP載荷中增加了附加信息字段，附加信息格式為“幀編號(2字節)+幀內NAL單元總數(1字節)+NAL單元序號(1字節)”，幀編號取值為0～65 535，循環使用。于是，RTP的載荷結構變為“附加信息(4字節)+NAL單元(不定長)”。利用此附加信息，平臺能判斷一幀、一個視頻序列接收的完整度，評估對圖像解碼造成的影響，再做進一步處理。

按如上設計，RTP載荷長度將不超過1 304字節(最長NAL單元1 300字節+附加信息4字節)，加上RTP包頭12字節(本例的RTP包頭只用到12字節固定字段)，則RTP數據包整體長度不超過1 316字節。為判斷RTP包是否會超過鏈路層的MTU限制，在終端上使用命令“ping －f－l1316xxx.xxx.xxx.xxx”(xxx.xxx.xxx.xxx 為平臺 IP 地址)測試有成功回應，說明未超過MTU限制。

為簡便計，無論NAL單元有多長，均使用一個RTP包封裝一個NAL單元。RTP時間戳T的計算公式為:T=T0+Td，其中T0表示上一視頻幀的時間戳，Td表示兩幀間的時間戳增量。第一個RTP包的T0為隨機計算得到的時間戳起始值。Td的計算公式為:Td=90000/F，F為視頻編碼輸出幀率(即每秒輸出多少視頻幀)。多個RTP包若屬于同一個視頻幀，則填入的RTP時間戳相同。

終端每隔5 s向平臺發送SR包(發送者報告)，同時接收每隔5 s從平臺發來的RR包(接收者報告)，并對RR包中的QoS信息進行分析處理。本例中采用的方法是根據丟包率的變化，終端動態調整編碼輸出的碼率大小，達到調整發送速率的效果。設丟包率門限值Lc，作為判斷網絡是否擁塞的標準。當丟包率低于門限值時，可加性增加碼率;當丟包率達到或高于門限值時，應乘性減小碼率。設丟包率為L，當前碼率為Rc，碼率加性增加值為K，期望碼率為Re，最小碼率為Rm，調整后碼率為Rp，公式如下:

本例中，Lc=0.03，Re=200 kb/s，K=2 kb/s，Rm=64 kb/s。需要說明的是，參與上述計算的丟包率L，是對RR包中反饋的原始丟包率經過低通濾波平滑處理后得到的值，目的是降低網絡傳輸質量突然隨機波動的影響。設Ln、Ln－1分別為當前時刻和上一時刻的濾波后丟包率，Ln0為當前時刻原始丟包率，權重常數為a(0≤a≤1)，則計算公式為:Ln=(1－a)Ln－1+aLn0。可以看出，增大a值，會增加新值Ln0對當前時刻濾波結果的影響;而減小a值，將增加上一時刻濾波結果Ln－1對當前時刻濾波結果的影響，經測試調整，本例中a=0.6。

2.2 監控平臺

平臺使用了海思提供的PC端解碼庫，操作系統為Windows。平臺對RTP數據的處理流程如圖4所示。

圖4 平臺處理RTP數據的流程Fig.4 RTP data processing procedures at platform

如圖4所示，軟件使用了雙緩沖設計［4］。接收緩沖，用于保存收到的RTP數據，經排序、檢測、過濾等處理后再送入播放緩沖;播放緩沖負責將數據按照幀間隔時間，順序解碼播放。為了盡可能避免因丟包造成的不正常解碼，從而影響視頻播放效果，在接收緩沖區對數據排序之后，在送入播放緩沖區之前，應對編碼數據做檢測和過濾處理。本例中，根據終端在RTP載荷中增加的附加信息字段，平臺快速判斷視頻數據丟失情況，當一個視頻序列出現一個NAL單元丟失時，該單元所在幀和其后的同一序列內的其他幀，均不參與解碼播放。

需要注意的是，按照RFC3550規范，RTP協議使用偶數端口，相應的RTCP協議使用緊隨其后的奇數端口。但是，即使終端嚴格按此規定配置自己的端口，在平臺“看到”的終端所用的通信端口，卻很可能不滿足此規定。這是因為，通過3G/4G移動通信網絡接入Internet時，運營商的網絡接入設備對終端的IP、端口進行了映射，平臺“看到”的是經過映射后的IP、端口，而非終端原始綁定的IP、端口，映射后就失去原有的綁定關系了。例如，終端原始端口7818(RTP)、7819(RTCP)，在映射后變為10527(RTP)、10360(RTCP)。因此，平臺在具體實現時必須對此做一點“讓步”，不能嚴格按照RFC3550規范推定終端RTP/RTCP通信端口是相鄰的。本例中，平臺從收到的RTP數據和RTCP數據(SR包)中的共同字段——發送者SSRC(同步源標識)，判斷源是否相同，確認RTP、RTCP通信鏈路是否配對。

平臺每隔5 s對收到的RTP數據和RTCP數據(SR包)進行分析統計，得到丟包率、抖動信息等，即QoS信息，然后使用RTCP協議發送RR包到終端。同時，平臺將從RTP數據中提取出的H.264數據解碼為YUV編碼數據，再轉換為RGB數據，最后用DirectShow技術播放。

3 結語

文中搭建監控平臺，將終端安裝在行駛的車輛上測試無線移動網絡環境下的視頻監控效果。實驗表明，相比不能自適應調整的系統，本系統的視頻監控效果更為流暢，馬賽克、殘像、缺失等現象基本消失，用戶體驗效果良好。

［1］劉高平，李國勝，宋執環.基于窄變帶寬的實時視頻傳輸算法［J］.光電子·激光，2012，23(03):548 －550.LIU Gao － ping，LI Guo － sheng，SONG Zhi－ huan.Real－Time Video Transmission Algorithm based on Narrow and Variable Bandwidth［J］.Journal of Optoelectronics·Laser，2012，23(03):548 －550.

［2］謝紅輝.基于網絡的視頻通信系統的設計［J］.通信技術，2009，42(07):131.XIE Hong－hui.Design of Network－based Video Communication System［J］.Communications Technology，2009，42(07):131.

［3］吳作綏.基于RTP的實時H.264網絡視頻監控系統的實現與QoS研究［D］.西安:西安電子科技大學，2009.WU Zuo － sui.The Realization and QoS Researchof RTP－based Real－ Time H.264 Net Video Monitor System［D］.Xi'an:Xidian University，2009.

［4］程堂勇.淺談RTP/RTCP的網絡視頻監控系統［J］.科技信息，2009(17):40.CHENG Tang－yong.Discussion on Network Video Monitor System based on RTP/RTCP［J］.Science＆Technology Information，2009(17):40.