一種數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)脑O(shè)計(jì)與實(shí)現(xiàn)

夏紅燕

摘要：隨著視頻壓縮技術(shù)的日益成熟，數(shù)字視頻監(jiān)控產(chǎn)品逐漸成為了市場(chǎng)的主流。人們已經(jīng)不滿足視頻信息能夠在網(wǎng)絡(luò)上傳輸，而是對(duì)傳輸?shù)馁|(zhì)量以及遠(yuǎn)程回放的效果提出了更高的要求。文章圍繞視頻網(wǎng)絡(luò)傳輸過(guò)程中的實(shí)時(shí)性和傳輸質(zhì)量?jī)纱笾黝}，提出將基于IP組播的RTP視頻傳輸與RSVP協(xié)議相結(jié)合的方案，使現(xiàn)有網(wǎng)絡(luò)可以提供更為穩(wěn)定流暢的傳輸效果。

關(guān)鍵詞：數(shù)字視頻；實(shí)時(shí)傳輸協(xié)議；用戶數(shù)據(jù)報(bào)協(xié)議；組播技術(shù)

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)：1009-3044（2017）27-0057-03

Abstract： In the past decade， video compression technology has been becoming more and more mature. The product of digital video surveillance is becoming the mainstream of the surveillance system. People are no longer satisfied with transportation of video， but place higher demand on quality and performance. This paper set focus on real-time requiring and quality of service in transmission， on the basis of adoption of RTP video transmission Based on IP Multicast ， discusses how RSVP in conjunction with typical digital video transportation scheme can provide a more stable and fluent performance on current QoS-supported network.

Key words： Digital Video； RTP； UDP； IP Multicast

隨著社會(huì)對(duì)安全防范技術(shù)和措施的日益重視，對(duì)數(shù)字視頻監(jiān)控領(lǐng)域的投資力度也日益加大，各種監(jiān)控報(bào)警、識(shí)別定位的技術(shù)被廣泛研究，隨之而來(lái)的視頻傳輸技術(shù)就顯得十分重要[1，2]。尤其是視頻壓縮技術(shù)的日益成熟，數(shù)字視頻傳輸技術(shù)逐漸成為了市場(chǎng)的主流，人們已經(jīng)不滿足視頻信息能夠在網(wǎng)絡(luò)上傳輸，而是對(duì)傳輸?shù)馁|(zhì)量以及遠(yuǎn)程回放的效果提出了更高的要求。

1 數(shù)據(jù)傳輸設(shè)計(jì)

視頻監(jiān)控系統(tǒng)的應(yīng)用環(huán)境決定了其對(duì)海量數(shù)據(jù)存儲(chǔ)和系統(tǒng)穩(wěn)定性的要求，因此，設(shè)計(jì)一個(gè)數(shù)字視頻監(jiān)控系統(tǒng)必須考慮以下性能要求：圖像清晰度，錄像存儲(chǔ)容量，網(wǎng)絡(luò)健壯性，系統(tǒng)穩(wěn)定性。

文章設(shè)計(jì)的數(shù)字視頻監(jiān)控網(wǎng)絡(luò)傳輸系統(tǒng)由9個(gè)模塊組成，數(shù)字視頻監(jiān)控網(wǎng)絡(luò)傳輸?shù)脑韴D如圖1所示。音視頻采集和壓縮處理由視頻采集卡硬件完成，采集卡通過(guò)附帶的SDK函數(shù)接口和網(wǎng)絡(luò)傳輸模塊之間通信，當(dāng)視頻采集卡完成視頻捕捉和壓縮處理后，RTP （Real-Time Transport Protocol）協(xié)議封裝模塊對(duì)數(shù)據(jù)塊進(jìn)行封裝和排序[3]，然后交給UDP網(wǎng)絡(luò)傳輸模塊在IP網(wǎng)絡(luò)上傳輸；接收端負(fù)責(zé)把網(wǎng)絡(luò)傳輸過(guò)來(lái)的音視頻資料包重組和譯碼回放。

當(dāng)采集卡捕獲的數(shù)據(jù)包通過(guò)RTP協(xié)議封裝在網(wǎng)絡(luò)上傳輸?shù)倪^(guò)程中，接收端在譯碼的過(guò)程中同時(shí)會(huì)對(duì)傳過(guò)來(lái)的RTP包進(jìn)行RTCP （Real-Time Transport Control）分析，分析所有的接收包，統(tǒng)計(jì)包丟失，時(shí)延抖動(dòng)，網(wǎng)絡(luò)負(fù)載等狀況，如果網(wǎng)絡(luò)的繁忙和其他情況的堵塞，包丟失嚴(yán)重，譯碼端馬上給編碼發(fā)送端一個(gè)反饋，發(fā)送端接收到這信息會(huì)做相應(yīng)的處理，以做到網(wǎng)絡(luò)流量的自適應(yīng)，這就是利用RTCP協(xié)議由接收方向發(fā)送方反饋信息的功能來(lái)進(jìn)行傳輸?shù)目刂疲员ＷC網(wǎng)絡(luò)傳輸?shù)姆?wù)質(zhì)量。

2 數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)目傮w實(shí)現(xiàn)

系統(tǒng)的主要任務(wù)是實(shí)現(xiàn)取流、封裝到發(fā)送的過(guò)程。如圖2所示是本文中采用的網(wǎng)絡(luò)視頻傳輸?shù)幕灸Ｐ汀?/p>

視頻的編碼是通過(guò)視頻壓縮卡——硬件編碼的方法來(lái)實(shí)現(xiàn)的，硬件廠商為我們提供了一個(gè)SDK軟件包。該SDK軟件包為我們提供了相應(yīng)的輸出函數(shù)用于從視頻壓縮卡中獲取視音頻數(shù)據(jù)流，并且資料包的大小也可預(yù)先設(shè)置，碼流也可以動(dòng)態(tài)的調(diào)整，這些函數(shù)接口直接為后面的RTCP控制提供了條件，視頻資料包和碼流的大小會(huì)影響到視頻在網(wǎng)絡(luò)中傳輸?shù)膶?shí)時(shí)性和視頻在接收端回放時(shí)抖動(dòng)的程度，因此該視頻資料包大小和碼流設(shè)置應(yīng)該是傳輸時(shí)的實(shí)時(shí)性和回放時(shí)的抖動(dòng)情況的折衷。

由于UDP協(xié)議是不能保證傳輸時(shí)視頻資料包的有序和無(wú)重復(fù)，因此，我們必須將取得的視頻流采用RTP協(xié)議封裝以后再在網(wǎng)絡(luò)中傳輸，以保證視頻數(shù)據(jù)報(bào)文的有序和無(wú)重復(fù)。再將采用RTP協(xié)議封裝好的視頻流移至發(fā)送緩沖區(qū)進(jìn)行傳輸。

以上從“壓縮編碼”一直到“視頻傳輸”的整個(gè)過(guò)程都是可逆的，因此，在視頻接收端進(jìn)行逆向操作，可以在客戶端實(shí)現(xiàn)視頻圖像的重建。

由于篇幅的原因，下面重點(diǎn)就基于UDP的RTP協(xié)議對(duì)音視頻流的封裝、網(wǎng)絡(luò)傳輸中的控制以及IP組播實(shí)現(xiàn)展開詳細(xì)介紹。

2.1 基于UDP的RTP協(xié)議對(duì)音視頻流的封裝

在使用RTP協(xié)議對(duì)視音頻復(fù)合流進(jìn)行封裝時(shí)，通行的做法是—在Windows操作系統(tǒng)中裝載RTP協(xié)議的動(dòng)態(tài)鏈接庫(kù)，然后將發(fā)送端的視頻編碼器輸出的數(shù)據(jù)流進(jìn)行相應(yīng)的成幀算法，形成適合于RTP協(xié)議格式的視頻流封裝，遞交給RTP協(xié)議分組處理模塊，加上此協(xié)議的分組報(bào)文頭，并根據(jù)當(dāng)前的采樣時(shí)鐘打上時(shí)間戳，標(biāo)記順序號(hào)，并給定幀頻、分辨率、相應(yīng)的壓縮格式等參數(shù)，經(jīng)多目地址傳輸來(lái)完成。

RTP協(xié)議報(bào)文頭的封裝在應(yīng)用程序的具體實(shí)現(xiàn)是通過(guò)一些編程小技巧來(lái)完成的，它的實(shí)現(xiàn)步驟為：endprint

1） 在定義取流緩沖區(qū)、封裝緩沖區(qū)和發(fā)送緩沖區(qū)時(shí)，封裝緩沖區(qū)和發(fā)送緩沖區(qū)的size應(yīng)比取流緩沖區(qū)大4個(gè)byte；

2） 定義并初始化一個(gè)全局整型變量作為RTP協(xié)議順序號(hào)，每取一次視頻流，全局整型變量加1；

3） 從視頻壓縮卡中取視頻流，存放在取流緩沖區(qū)；

4） 根據(jù)偏移量將RTP協(xié)議順序號(hào)和取流緩沖區(qū)的視頻數(shù)據(jù)包順序存放，形成用RTP協(xié)議封裝的視頻流，存放在封裝緩沖區(qū)等待發(fā)送；

5） 視頻服務(wù)器啟動(dòng)發(fā)送線程即可將用RTP協(xié)議封裝的視音頻系統(tǒng)流發(fā)送至網(wǎng)絡(luò)上。

系統(tǒng)設(shè)計(jì)從硬件采集卡取流后是獲得視頻的幀數(shù)，如何把這些幀數(shù)打包且適合在網(wǎng)絡(luò)上傳輸是一個(gè)很重要的問題，也是我們進(jìn)行RTCP控制的一個(gè)很重要的參數(shù)。由此設(shè)計(jì)出一個(gè)可調(diào)節(jié)的發(fā)送緩沖區(qū)大小的網(wǎng)絡(luò)函數(shù)SetBufferNum（Num）； 通過(guò)對(duì)局域網(wǎng)（LAN）網(wǎng)絡(luò)環(huán)境的分析和反復(fù)地實(shí)驗(yàn)比較，我們發(fā)現(xiàn)視頻數(shù)據(jù)包的大小在32Kbyte左右時(shí)，有著較好的實(shí)時(shí)特性，且在接收端的播放也較為流暢，無(wú)明顯抖動(dòng)。因此視頻數(shù)據(jù)包的大小取32Kbyte時(shí)，是視頻傳輸?shù)膶?shí)時(shí)特性和視頻播放的抖動(dòng)情況的較優(yōu)的折衷。

在線程ThreadRoutine中，系統(tǒng)不斷地檢測(cè)視頻壓縮卡送出的數(shù)據(jù)。壓縮卡不斷地以2048字節(jié)一個(gè)包發(fā)往PCI總線。視音頻壓縮、取流線程在得到PCI總線的數(shù)據(jù)后便往RTP協(xié)議封裝線程發(fā)送預(yù)先定義好的消息。RTP協(xié)議封裝線程收到消息后，對(duì)數(shù)據(jù)進(jìn)行封裝。數(shù)據(jù)封裝好了以后，RTP協(xié)議封裝線程便往主線程發(fā)送消息。主線程收到消息后便可對(duì)相應(yīng)數(shù)據(jù)進(jìn)行處理，并將封裝好了的數(shù)據(jù)送往SOCKET口進(jìn)行網(wǎng)絡(luò)廣播。

2.2 網(wǎng)絡(luò)傳輸中的控制

設(shè)計(jì)的網(wǎng)絡(luò)傳輸控制關(guān)系如圖3。當(dāng)RTP數(shù)據(jù)包從視頻主機(jī)端傳送到客戶端后，在去除RTP頭的同時(shí)我們可以根據(jù)RTP的順序號(hào)來(lái)測(cè)檢出RTP包的丟失率，根據(jù)RTP包的丟失率，RTCP產(chǎn)生器會(huì)產(chǎn)生相應(yīng)的反饋控制信息，這些控制信息可以反饋到視頻主機(jī)端而控制編碼器，使其作出相應(yīng)的碼率調(diào)整，以適應(yīng)網(wǎng)絡(luò)的負(fù)載變化[4]。

在客戶端，當(dāng)RTP分析器產(chǎn)生的包丟失率送入RTCP產(chǎn)生器后，它會(huì)產(chǎn)生相應(yīng)的報(bào)文發(fā)送到視頻主機(jī)端而控制編碼器動(dòng)態(tài)的改變碼流適應(yīng)網(wǎng)絡(luò)的負(fù)載[5]?，F(xiàn)在RTCP產(chǎn)生器有兩個(gè)問題：

1） 怎樣用包丟率來(lái)代表網(wǎng)絡(luò)的擁塞？

2） 怎樣消除統(tǒng)計(jì)的誤差，避免網(wǎng)絡(luò)QoS的波動(dòng)。

其中[λnew]是新的平滑丟失率，[η]是新的由RTCP包直接得到的丟失率。增加[α]就增加了新值的影響，相反，減少[α]就減緩了新值的影響。這樣既考慮了過(guò)去的經(jīng)驗(yàn)，也反映了最新的狀態(tài)變化。根據(jù)實(shí)際經(jīng)驗(yàn)和其他協(xié)議的建議，[α]值一般取0.3。

2.3 利用UDP Sockets實(shí)現(xiàn)IP組播

IP組播特別適合于高帶寬的應(yīng)用，例如在網(wǎng)絡(luò)上發(fā)送視頻和音頻，在Windows操作系統(tǒng)中，IP組播的實(shí)現(xiàn)是以UDP Socket為基礎(chǔ)的。

由于IP多點(diǎn)傳送主要用于同組中成員的交流，因此，系統(tǒng)中該功能的開發(fā)流程如下：

1） 創(chuàng)建一個(gè)按規(guī)定編址的數(shù)據(jù)報(bào)文Datagram- Packet；

2） 建立一個(gè)用于發(fā)送和接收的Multicast- Socket；

3） 加入一個(gè)多點(diǎn)傳送組；

4） 將數(shù)據(jù)報(bào)文放入MulticastSocket中發(fā)送；

5） 等待從MulticastSocket接收數(shù)據(jù)報(bào)；

6） 解碼數(shù)據(jù)報(bào)文提取、重建視音頻信息；

7） 根據(jù)得到的信息作出回應(yīng)；

8） 重復(fù)5-7步；

9） 離開該多點(diǎn)傳送組，關(guān)閉MulticastSocket。

由于客戶機(jī)和服務(wù)器程序的網(wǎng)絡(luò)通信模塊都是用套接字開發(fā)的，因此屏蔽了網(wǎng)絡(luò)層復(fù)雜的結(jié)構(gòu)和協(xié)議，使應(yīng)用軟件能在各種網(wǎng)上運(yùn)行，而不必關(guān)心是何種網(wǎng)絡(luò)以及服務(wù)器或客戶機(jī)在網(wǎng)上的具體位置和數(shù)據(jù)傳送的具體細(xì)節(jié)。

3 結(jié)束語(yǔ)

文章以部隊(duì)安全技術(shù)防范系統(tǒng)項(xiàng)目的整體研發(fā)為背景，對(duì)數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)膶?shí)現(xiàn)進(jìn)行了較為深入的探索，圍繞視頻網(wǎng)絡(luò)傳輸過(guò)程中的實(shí)時(shí)性和傳輸質(zhì)量?jī)纱笾黝}，通過(guò)對(duì)各種傳輸層協(xié)議以及服務(wù)質(zhì)量保障方案的研究比較，提出將基于IP組播的RTP視頻傳輸與RSVP協(xié)議相結(jié)合的方案，使現(xiàn)有網(wǎng)絡(luò)可以提供更為穩(wěn)定流暢的傳輸效果，并采用可視化編程技術(shù)做了具體的實(shí)現(xiàn)，實(shí)現(xiàn)基于UDP的RTP協(xié)議對(duì)音視頻流的封裝、網(wǎng)絡(luò)傳輸控制、IP組播等。數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)膶?shí)現(xiàn)，取得了較好的實(shí)際效果，系統(tǒng)裝備部隊(duì)后運(yùn)行效果良好，對(duì)于加速部隊(duì)后勤的信息化作出了貢獻(xiàn)。

參考文獻(xiàn)：

[1] Kun Liang，Yong Ma，Yue Xie，etal.A new adaptive contrast enhancement algorithm for infrared images Based on double plateaus histogram equalization[J].Infrared Physics& Technology， 2012， 55（4）：309-315.

[2] 王維哲.從H.264向H.265的數(shù)字視頻壓縮技術(shù)升級(jí)分析[J].電腦知識(shí)與技術(shù)，2015，11（15）：130-131.

[3] 魏閃閃，謝巍，賀志強(qiáng).新興數(shù)字視頻穩(wěn)像中相機(jī)運(yùn)動(dòng)估計(jì)技術(shù)綜述[J].計(jì)算機(jī)應(yīng)用研究，2017，34（2）：321-327.

[4] 梁夢(mèng)凡，熊利祥，馬德寶.一種基于SOC的紅外視頻網(wǎng)絡(luò)傳輸系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)與數(shù)字工程，2017，45（1）：88-91.

[5] 李少博，王曉東，周宇.基于RTP/RTCP主動(dòng)丟包的立體視頻傳輸研究[J].計(jì)算機(jī)工程，2015，41（4）：241-245.endprint