基于RTP協(xié)議的移動視頻監(jiān)控系統(tǒng)的設(shè)計

許 寧

(廈門雅迅網(wǎng)絡(luò)股份有限公司，福建廈門361008)

0 引言

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

1 技術(shù)原理

1.1 H.264編碼

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

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

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

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

一個典型的H.264碼流結(jié)構(gòu)示例如圖1所示。

圖1 H.264碼流結(jié)構(gòu)示例Fig.1 Example for H.264 coded data structure

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

1.2 RTP/RTCP 協(xié)議

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

RFC3550實際描述了兩個關(guān)系密切的子協(xié)議:RTP和 RTCP。RTCP全稱是 RTP Control Protocol，即RTP控制協(xié)議。其中，RTP協(xié)議用于實時數(shù)據(jù)的傳輸，但不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制［2］。RTCP協(xié)議則負責傳遞網(wǎng)絡(luò)的QoS(Quality of Service，服務(wù)質(zhì)量)信息，并且傳送參與多媒體數(shù)據(jù)收發(fā)者的信息。使用者可根據(jù)RTCP協(xié)議傳遞的網(wǎng)絡(luò)傳輸質(zhì)量信息，動態(tài)調(diào)整單位時間傳輸?shù)臄?shù)據(jù)量，實現(xiàn)流量控制和擁塞控制，以適應(yīng)網(wǎng)絡(luò)環(huán)境的變化。

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

圖2 RTP/RTCP與其他協(xié)議層次關(guān)系示意Fig.2 Hierarchical relationship between RTP/RTCP and other protocols

按照規(guī)范，RTP使用偶數(shù)端口，配對的RTCP協(xié)議使用緊隨其后的奇數(shù)端口。

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

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

接收方根據(jù)RTP數(shù)據(jù)包中的序列號信息對數(shù)據(jù)排序重組，并結(jié)合來自發(fā)送方的SR包(RTCP數(shù)據(jù))判斷丟包情況;RTP和RTCP數(shù)據(jù)中還包含時間戳信息，接收方可分析時間戳信息判斷數(shù)據(jù)傳輸?shù)难舆t和抖動情況。根據(jù)數(shù)據(jù)的丟包和延時抖動情況，可判斷網(wǎng)絡(luò)QoS的變化情況，從而調(diào)整數(shù)據(jù)傳輸速率，適應(yīng)網(wǎng)絡(luò)帶寬變化。發(fā)送速率調(diào)整算法一般使用加性增加乘性減?。?］(AIMD，Additive Increase and Multiplicative Decrease)。

2 系統(tǒng)的實現(xiàn)

移動視頻監(jiān)控系統(tǒng)，由視頻采集終端(以下簡稱終端)、監(jiān)控平臺(以下簡稱平臺)，以及它們之間的通信網(wǎng)絡(luò)組成，結(jié)構(gòu)示意圖如圖3所示。

圖3 移動視頻監(jiān)控系統(tǒng)結(jié)構(gòu)Fig.3 Mobile video monitor system structure

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

2.1 視頻采集終端

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

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

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

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

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

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

本例中，Lc=0.03，Re=200 kb/s，K=2 kb/s，Rm=64 kb/s。需要說明的是，參與上述計算的丟包率L，是對RR包中反饋的原始丟包率經(jīng)過低通濾波平滑處理后得到的值，目的是降低網(wǎng)絡(luò)傳輸質(zhì)量突然隨機波動的影響。設(shè)Ln、Ln－1分別為當前時刻和上一時刻的濾波后丟包率，Ln0為當前時刻原始丟包率，權(quán)重常數(shù)為a(0≤a≤1)，則計算公式為:Ln=(1－a)Ln－1+aLn0?？梢钥闯?，增大a值，會增加新值Ln0對當前時刻濾波結(jié)果的影響;而減小a值，將增加上一時刻濾波結(jié)果Ln－1對當前時刻濾波結(jié)果的影響，經(jīng)測試調(diào)整，本例中a=0.6。

2.2 監(jiān)控平臺

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

圖4 平臺處理RTP數(shù)據(jù)的流程Fig.4 RTP data processing procedures at platform

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

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

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

3 結(jié)語

文中搭建監(jiān)控平臺，將終端安裝在行駛的車輛上測試無線移動網(wǎng)絡(luò)環(huán)境下的視頻監(jiān)控效果。實驗表明，相比不能自適應(yīng)調(diào)整的系統(tǒng)，本系統(tǒng)的視頻監(jiān)控效果更為流暢，馬賽克、殘像、缺失等現(xiàn)象基本消失，用戶體驗效果良好。

［1］劉高平，李國勝，宋執(zhí)環(huán).基于窄變帶寬的實時視頻傳輸算法［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］謝紅輝.基于網(wǎng)絡(luò)的視頻通信系統(tǒng)的設(shè)計［J］.通信技術(shù)，2009，42(07):131.XIE Hong－h(huán)ui.Design of Network－based Video Communication System［J］.Communications Technology，2009，42(07):131.

［3］吳作綏.基于RTP的實時H.264網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的實現(xiàn)與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的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)［J］.科技信息，2009(17):40.CHENG Tang－yong.Discussion on Network Video Monitor System based on RTP/RTCP［J］.Science＆Technology Information，2009(17):40.