馮 浩，管 鮑

(1.武漢郵電科學研究院，湖北 武漢 430074;2.武漢虹信通信技術有限責任公司，湖北 武漢 430074)

衡量無線視頻質量的重要指標是流暢性和實時性。無線網絡傳輸?shù)纳闲袔捰邢?，傳輸?shù)囊曨l圖像往往容易出現(xiàn)馬賽克和延遲等現(xiàn)象。傳統(tǒng)的無線視頻通信系統(tǒng)主要是單卡的模式，通過一張卡傳輸。這樣利用的網絡帶寬資源大概在300 kbit/s左右，如果網絡狀況好可以達到400 kbit/s左右，這樣得到的視頻圖像也容易出現(xiàn)馬賽克等現(xiàn)象，不能很好地解決無線網絡帶寬不足的問題。本文針在雙模無線視頻通信的基礎上，通過高性能的ARM9芯片控制MC8630無線模塊，這樣將無線網絡資源提高到600 kbit/s，如果網絡狀況好可以達到800 kbit/s左右，很大程度上能避免無線視頻傳輸過程中出現(xiàn)的馬賽克和視頻畫面延時，基本保證了視頻的流暢性和實時性。

1 協(xié)議介紹

SIP是一個應用層的控制協(xié)議，可以用來建立、修改、和終止多媒體會話的協(xié)議。在多媒體通信中完成信令的交互，SIP協(xié)議棧主要由eXosip模塊、osip2模塊、osipparser2模塊組成。其中osipparser2主要完成SIP和SDP消息的文本解析器和文本生成器。osip2模塊主要實現(xiàn)事務狀態(tài)機的維護和運行，eXosip模塊實現(xiàn)底層socket傳送/接收以及上層的數(shù)據處理。SIP協(xié)議完成會話還需要和SDP協(xié)議配合使用，SDP協(xié)議是會話描述協(xié)議，主要描述會話名稱和意圖，構成會話的媒體等信息［1］。

實時傳輸協(xié)議(Realtime Transport Protocol，RTP)，是針對Internet上多媒體數(shù)據流的一個傳輸協(xié)議，由IETF作為RFC1889發(fā)布，現(xiàn)在最新版為RFC3550。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RTP本身只保證實時數(shù)據的傳輸，并不能為按順序傳送數(shù)據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。RTCP協(xié)議負責管理傳輸質量，在當前應用進程之間交換控制信息，提供流量控制和擁塞控制服務。

2 系統(tǒng)結構

本方案主芯片采用TMS320DM368處理器，主頻432 MHz，芯片內部集成有DSP處理器，TI開放其DSP接口，可以支持H.264/MPEG－4的高清編解碼。CY7C65640A的驅動可以直接參考LinuxUSB的驅動，選擇CY7C65640A芯片擴展DM365的USB接口，連接兩個MC8630。本系統(tǒng)采用中興通訊的MC8630芯片，如圖1所示。該芯片是1個CMDA20001x/EVDO Rev.A的3G無線模塊，上行通信速度理論值為1.8 Mbit/s。由于其資料廣泛可以參考該芯片Linux的驅動程序，從而可大大減小軟件開發(fā)周期，滿足應用需求。本文重點闡述軟件設計部分［2］。

圖1 系統(tǒng)結構示意圖

3 軟件設計

軟件設計包括嵌入式軟件設計和客戶端軟件設計。其中嵌入式軟件設計包括對MC8630芯片驅動設計和信令交互數(shù)據發(fā)送軟件設計部分。客戶端軟件設計部分包含解包部分和解碼部分。組幀協(xié)議如圖2所示。嵌入式軟件設計按照此協(xié)議采集視頻數(shù)據并按照H.264組幀，通過USB接口將視頻數(shù)據發(fā)送給客戶端。客戶端接收雙模發(fā)送過來的數(shù)據，并將該數(shù)據通過FFmpeg解碼庫顯示播放出來。

圖2 組幀協(xié)議示意圖

其中B代表byte，幀開頭以B1C1B2C2來區(qū)分。Playload定義8為音頻，77為視頻。碼流類型為:0x01代表H.264壓縮，0x02代表MPEG－4壓縮，0x81代表G.711壓縮，0x82代表G.729壓縮，0x83代表MP3壓縮。

雙卡定義的視頻發(fā)送策略如圖3所示。雙網卡分別傳送I幀和P幀數(shù)據［3］。

圖3 視頻發(fā)包示意圖

4 嵌入式軟件設計

4.1 嵌入式軟件驅動設計

MC8630作為塊設備，該芯片提供Linux內核源碼驅動程序，通過移植工作，將該驅動加載到內核當中。經過AT指令配置之后即可使用，當模塊狀態(tài)為可用時，通過Linux塊設備操作流程向發(fā)送端發(fā)送數(shù)據。

CY7C65640的驅動設計可以參考通用USB驅動程序設計，大部分配置任務都在驅動程序中完成。驅動程序加載到內核當中，系統(tǒng)上電即可使用［4］。

4.2 應用程序設計

DM368芯片是ARM+DSP雙核結構，利用DSP強大的運算功能，實現(xiàn)對視頻信號的編碼，編碼之后的視頻從DSP傳送到ARM中，經過組幀協(xié)議之后等待客戶端的鏈接，一旦接收到視頻請求就將視頻發(fā)送出去。無線視頻服務器還需接收客戶端發(fā)送過來的云臺控制，OSD參數(shù)查詢和視頻分辨力、碼率修改等信令。這些信令控制著終端運行的參數(shù)。信令的交互采用的是SIP協(xié)議，消息體格式采用的是SDP方式或XML方式，通過SDP協(xié)議傳遞RTP視頻流信息;通過XML消息體傳遞云臺控制等信息。

當視頻服務器接收到客戶端發(fā)送視頻請求SIP信令時，解析SDP消息體，從m參數(shù)中獲取RTP端口，Playload值等信息，然后調用RTP協(xié)議根據指定端口將數(shù)據發(fā)送到客戶端。同時，當視頻服務器接收到客戶端發(fā)送的云臺控制等信令時，解析XML消息體，完成對相應結構體的賦值，從而控制著終端運行的參數(shù)。

由服務器處理流程得知，應用程序設計包含視頻緩沖區(qū)設計部分和信令交互部分。視頻緩沖區(qū)完成采集的數(shù)據緩存和視頻數(shù)據的發(fā)送。信令交互部分完成SIP信令交互和RTP信令交互。

4.2.1 視頻緩沖區(qū)設計

DM368芯片上運行的是Linux實時操作系統(tǒng)，利用Linux線程間通信的同步與互斥機制和Linux信號量機制來實現(xiàn)視頻緩沖隊列。視頻緩沖隊列定義結構體如下:

隊列相關函數(shù)說明包含在sendqueue.c文件當中，QueueInit()函數(shù)主要完成緩沖隊列的初始化，客戶端關掉視頻時調用QueueEmpty()函數(shù)清空接收隊列，客戶端申請視頻時調用QueueOutput()函數(shù)取出隊列數(shù)據進行發(fā)送，接受客戶端RTCP統(tǒng)計的丟包率如果丟包率大時調用drop_packet()函數(shù)丟包，丟棄P幀和緊隨P幀之后的I幀，以降低發(fā)送碼流。

4.2.2 信令交互部分設計

主程序在完成初始化之后，主動向客戶端發(fā)送1個SIP注冊消息，并開通心跳包線程，每隔2 min發(fā)送1次心跳包，心跳包只包含時間信息，客戶端接收到心跳包會返回1個心跳包回應，當心跳包線程超過2 min未收到心跳包，則重新注冊。與此同時在主程序中開啟SIP線程接收客戶端發(fā)送過來的SIP信令，定義eXosip_event_t*stEvent接收事件，如果該事件類型為EXOSIP_CALL_INVITE，表示客戶端視頻請求消息，此時調用osipparser2庫函數(shù)解析SDP的內容，獲取RTP發(fā)送端口，向客戶端的該端口發(fā)送RTP數(shù)據流。由于RTP庫支持1500的包長度，此處傳輸?shù)拈L度為1362。同時開啟RTP監(jiān)聽線程，監(jiān)聽客戶端發(fā)送過來的RTCP包，根據收到的包信息，動態(tài)調整發(fā)送的碼流大小，當碼流過大時候，此時采取丟包策略調用drop_packet()函數(shù)，丟掉P幀和緊隨其后的I幀數(shù)據。

嵌入式軟件設計部分主要處理客戶端發(fā)送過來的SIP消息、包括云臺控制消息、視頻請求消息，消息的處理如下:

初始化RTP會話，建立RTP連接，開始發(fā)送數(shù)據。發(fā)送SIP回應消息。

5 客戶端軟件設計部分

客戶端軟件設計部分包括解碼部分和信令交互部分。

5.1 信令交互部分

信令交互部分采用的SIP信令控制協(xié)議由點擊客戶端界面按鈕來觸發(fā)，此處用到的SIP格式有MESSAGE消息和INVITE請求。MESSAGE消息用來處理控制消息和視頻服務器參數(shù)獲取、設置消息。INVITE請求用于RTP請求等。消息的組包流程為:1)初始化消息頭、設置消息頭域的值;2)判斷是否帶有消息體，帶有消息體判斷是SDP消息體還是其他消息體，否則進行步驟4);3)初始化SDP消息體，非SDP消息體的時候初始化XML消息體;4)完成SIP字符串的生成，完成SIP協(xié)議的發(fā)送。其中Content－Type的值是XML的時候設置為application/global_eye_v10+xml。是SDP的時候設置為application/sdp。

舉例RTP請求SIP協(xié)議發(fā)送的例子［5］。

在客戶端也要開啟SIP監(jiān)聽消息進程，監(jiān)聽線程主要監(jiān)聽CALL消息的回應消息、注冊消息和SIP回應消息?？蛻舳双@取相應的參數(shù)之后，完成界面的更新操作。

5.2 FFmpeg解碼部分

客戶端采用VC++6.0開發(fā)，客戶端發(fā)送CALL消息申請視頻之后，收到SIP的EXOSIP_CALL_ANSWERED回應消息，然后發(fā)送ACK，服務器在接收到ACK之后，開始調用RTP協(xié)議發(fā)送視頻流。客戶端監(jiān)聽RTP端口接收數(shù)據流設置。定義rtp_event*e接收事件，當e－＞type=RX_RTP時，將雙模接收到的數(shù)據送入inputdata()函數(shù)進行組包解碼顯示。由于接收的數(shù)據是雙模發(fā)送過來的，則需要對接收的數(shù)據進行組包、排序處理。根據RTP包的特性，同一幀的數(shù)據時間戳TS相等，RTP小包序列號(seq)是連續(xù)的。

1)主任務入口函數(shù)

當前鏈表指向下一個節(jié)點;

6 結束語

本文基于TI公司的DM368芯片，采用雙卡傳輸，采用多鏈路捆綁技術實現(xiàn)視頻數(shù)據的安全可靠傳輸，顯著提高了無線網絡傳輸帶寬［4］。文中信令協(xié)議采用SIP協(xié)議，視頻流的傳輸采用RTP/RTCP協(xié)議，該程序框架具有很好的兼容性，只需要簡單的改動就能夠組建大的視頻監(jiān)控網絡，具有很強的可擴展性，目前該系統(tǒng)已投入使用。

［1］胡棟，劉峰，朱秀昌.實時多模式無線視頻傳輸原型系統(tǒng)的實現(xiàn)［J］.通信學報，2006，27(10):110－116.

［2］孫天澤，袁文菊，張海峰.嵌入式設計及 Linux驅動開發(fā)指南:基于ARM9處理器［M］.北京:電子工業(yè)出版社，2005.

［3］尤盈盈.基于嵌入式系統(tǒng)的無線多媒體傳輸系統(tǒng)終端的研究［D］.杭州:浙江工業(yè)大學，2005:30－34.

［4］吳長樹.一種基于公共移動通信的視頻包多鏈路接收和播放方法:中國，200910241583.6［P］.2010－05－12.

［5］翁睿.基于GPRS網絡的自適應碼率視頻傳輸［D］.上海:復旦大學，2008.