遠(yuǎn)程全景實(shí)時(shí)監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

楊 濤，羅健欣，金鳳林，張小峰

(陸軍工程大學(xué) 指揮控制工程學(xué)院，江蘇 南京 210007)

0 引 言

隨著網(wǎng)絡(luò)的普及和帶寬的飛速增長，實(shí)時(shí)視頻通信由于其獨(dú)特的優(yōu)勢，逐漸在網(wǎng)絡(luò)流量中占據(jù)重要的一部分。實(shí)時(shí)監(jiān)控作為實(shí)時(shí)視頻通信的一種重要形式，已經(jīng)深入到生產(chǎn)生活的方方面面，尤其是在一些涉及安全問題的場合[1]，更是發(fā)揮著不可替代的作用。實(shí)時(shí)視頻通信一般包括視頻的采集、壓縮編碼、網(wǎng)絡(luò)傳輸和可視化等技術(shù)環(huán)節(jié)。在傳統(tǒng)的視頻通信架構(gòu)中，視頻編解碼模塊和傳輸協(xié)議模塊各自工作在相對獨(dú)立的控制回路，兩者之間的協(xié)作不夠緊密，由此導(dǎo)致編碼器的輸出比特率與當(dāng)前的網(wǎng)絡(luò)容量不適配，有可能引起擁塞或者性能的損失[2]。傳統(tǒng)的視頻監(jiān)控通常采用B/S模式，由服務(wù)器將被監(jiān)控端攝像頭采集的視頻流推送到監(jiān)控端的瀏覽器。這類監(jiān)控系統(tǒng)通常使用單個(gè)或者多個(gè)攝像頭對被監(jiān)控場景進(jìn)行視頻采集，在監(jiān)控端獨(dú)立顯示各個(gè)監(jiān)控畫面。通過這種方式獲取的實(shí)時(shí)監(jiān)控由于各攝像頭相互獨(dú)立，畫面通常不夠直觀，甚至?xí)嬖谝欢ǖ拿^(qū)。針對以上兩個(gè)問題，設(shè)計(jì)了一種采用緊耦合式視頻通信架構(gòu)的遠(yuǎn)程全景實(shí)時(shí)監(jiān)控系統(tǒng)。一方面使得視頻編解碼模塊和傳輸協(xié)議之間的協(xié)作更為緊密，優(yōu)化了每一幀的編碼長度，提升了視頻通信的時(shí)延性能和視頻質(zhì)量[2]；另一方面全景監(jiān)控使得監(jiān)控角度更大，畫面更加直觀，可以在一定程度上解決視頻監(jiān)控盲區(qū)問題。

1 相關(guān)關(guān)鍵技術(shù)

1.1 緊耦合式視頻編解碼和傳輸

在現(xiàn)有的常規(guī)視頻通信系統(tǒng)中，如Skype、WebRTC[3]、和Facetime等，視頻編解碼模塊和傳輸協(xié)議通常工作在各自的控制回路之中。傳輸協(xié)議通過處理網(wǎng)絡(luò)中的確認(rèn)、擁塞等信號，對當(dāng)前的網(wǎng)絡(luò)平均速率進(jìn)行估計(jì)并將此通告給編碼模塊。以WebRTC為例，通告網(wǎng)絡(luò)速率估計(jì)值的時(shí)間間隔大約為1秒。編碼模塊根據(jù)此估計(jì)值設(shè)置編碼輸出比特率，生成壓縮的比特流，其平均比特率接近估計(jì)的網(wǎng)絡(luò)速率，這樣的速率控制相對來說是比較粗糙的。而在緊耦合式的新型視頻架構(gòu)中，編解碼器和傳輸協(xié)議被整合進(jìn)一個(gè)控制回路，相互之間協(xié)作更為緊密，如圖1所示。在這樣的架構(gòu)中，編碼器并行編碼同一幀的不同質(zhì)量版本。傳輸協(xié)議通過估算當(dāng)前網(wǎng)絡(luò)容量，計(jì)算當(dāng)前所能發(fā)送的最大幀長度，從而選擇編碼輸出大小最接近但不超過當(dāng)前網(wǎng)絡(luò)容量的質(zhì)量版本進(jìn)行發(fā)送，實(shí)現(xiàn)粒度更細(xì)的逐幀控制，從而更有效地避免擁塞或者網(wǎng)絡(luò)性能浪費(fèi)。能夠?qū)⒕幗獯a模塊和傳輸協(xié)議緊耦合到一起，主要依賴于兩點(diǎn)：

(1)基于現(xiàn)有的編解碼器進(jìn)行改造，退變?yōu)榧兒瘮?shù)式編碼器，不再控制比特率而只提供編解碼的接口；在編解碼器中引入“狀態(tài)(state)”的概念，每一個(gè)狀態(tài)值與每一次編碼一幀時(shí)所用的參數(shù)相關(guān)，在收發(fā)雙方的內(nèi)存中維護(hù)了狀態(tài)隊(duì)列，用類似于TCP滑動(dòng)窗口的模式來管理隊(duì)列中的狀態(tài)并實(shí)現(xiàn)收發(fā)雙方狀態(tài)的同步。

(2)通過指數(shù)加權(quán)移動(dòng)平均法(exponentially weighted moving average，EWMA)計(jì)算平均包到達(dá)時(shí)延，并據(jù)此計(jì)算當(dāng)前網(wǎng)絡(luò)容量，實(shí)現(xiàn)幀的編碼長度和瞬時(shí)網(wǎng)絡(luò)容量的最佳適配。

圖1 緊耦合式視頻編解碼和傳輸

1.2 視頻拼接技術(shù)

視頻拼接一直以來都是一項(xiàng)非常具有挑戰(zhàn)性的課題，尤其是對運(yùn)動(dòng)攝像頭拍攝的視頻進(jìn)行實(shí)時(shí)拼接，由于特征點(diǎn)的檢測匹配和相機(jī)運(yùn)動(dòng)路徑的估計(jì)都需要大量的計(jì)算,目前仍然沒有拼接效果和實(shí)時(shí)性俱佳的解決方案。Yoon等[4]將幀劃分成均勻的網(wǎng)格，通過計(jì)算相鄰幀間對應(yīng)網(wǎng)格點(diǎn)的像素差值大小來代替?zhèn)鹘y(tǒng)特征點(diǎn)的提取，而后通過光流法匹配估計(jì)相機(jī)運(yùn)動(dòng),大幅度簡化了相機(jī)運(yùn)動(dòng)估計(jì)，最后將所有的幀都重投影到第一幀的坐標(biāo)系中。1 280*720分辨率的視頻測試幀率達(dá)到了13 fps。但顯然這種粗糙的運(yùn)動(dòng)估計(jì)和配準(zhǔn)方式犧牲了較多的拼接質(zhì)量。

對于運(yùn)動(dòng)攝像頭拍攝好的視頻進(jìn)行離線拼接，目前已經(jīng)有了一些比較好的解決方案。其中Lin等人[5]提出的先穩(wěn)定后拼接的方案，需要利用三維重建算法計(jì)算出相機(jī)的原始運(yùn)動(dòng)路徑；Guo等人[6]提出通過優(yōu)化相機(jī)的運(yùn)動(dòng)路徑,同時(shí)完成視頻穩(wěn)定和拼接的任務(wù),不需要三維重建，是目前較為完整的2D方案，拼接效果也比較好。

對于攝像頭固定的實(shí)時(shí)監(jiān)控的場景，王文學(xué)[7]采用了改進(jìn)特征點(diǎn)的提取和匹配來加速拼接，其中陶荷夢[8]使用了CUDA框架進(jìn)行了GPU加速，但均未真正達(dá)到實(shí)時(shí)要求。LIU等[9]在首次計(jì)算好模板幀的拼接矩陣后，所有后續(xù)幀均按照同樣的模板拼接，雖然實(shí)時(shí)性較好，但后續(xù)拼接效果顯然不夠理想。相比之下劉有科等[10]用固定間隔插幀和GPU加速，達(dá)到了13 fps的幀率，也不失為一種比較有效的近似實(shí)時(shí)的方式。He[11]受DHW[12]算法的啟發(fā)，將特征點(diǎn)分成不同的層次并預(yù)先對準(zhǔn)，在此基礎(chǔ)上構(gòu)成背景并尋找拼接縫，而后通過檢測拼接縫附近的變化來更新拼接縫。該方法的優(yōu)點(diǎn)在于對視差比較魯棒，但不管有無前景變化，該算法在拼接每一幀時(shí)都要計(jì)算接縫處每個(gè)像素的梯度變化，使得單幀拼接時(shí)間增加較為明顯，幀率在12 fps左右。

2 系統(tǒng)架構(gòu)

設(shè)計(jì)并實(shí)現(xiàn)的系統(tǒng)主要功能模塊有：

(1)多路視頻的采集；

(2)緊耦合式的多路視頻編解碼和傳輸；

(3)多路視頻的同步和實(shí)時(shí)拼接。

系統(tǒng)的整體架構(gòu)如圖2所示。

圖2 系統(tǒng)架構(gòu)

3 系統(tǒng)實(shí)現(xiàn)

3.1 發(fā)送端

3.1.1 視頻采集

系統(tǒng)采用V4L2(Video For Linux 2)框架進(jìn)行視頻采集。V4L2框架是Linux內(nèi)核提供給應(yīng)用程序訪問視頻設(shè)備的統(tǒng)一接口，在嵌入式系統(tǒng)中應(yīng)用非常廣泛。在Linux中，攝像頭被看作文件，位于/dev目錄下，用唯一的文件描述符來標(biāo)識。

3.1.2 視頻編碼

采用FOULADI團(tuán)隊(duì)[2]基于libvpx庫進(jìn)行改造實(shí)現(xiàn)的純函數(shù)式編解碼器，視頻格式采用VP8[13]。其中編碼過程的各個(gè)環(huán)節(jié)，包括：變換、預(yù)測、自適應(yīng)量化、環(huán)路濾波和和熵編碼均按照VP8的官方文檔[14]實(shí)現(xiàn)。唯一的區(qū)別是將編碼器內(nèi)部的“狀態(tài)”暴露出來供外部使用，其編解碼接口如下：

encode (state, image, quality) → frame

decode (state, frame) → (state’, image)

其中state表示編碼器的內(nèi)部狀態(tài)，在實(shí)現(xiàn)中是前一幀解碼時(shí)使用的參考幀和熵編碼概率表的哈希值。由于采用預(yù)測編碼的編碼器需要進(jìn)行幀的重構(gòu)，編碼器實(shí)際上包含了解碼器的完整實(shí)現(xiàn)[15]。因此收發(fā)雙方可以實(shí)現(xiàn)狀態(tài)轉(zhuǎn)換的同步。quality參數(shù)用來設(shè)置同一幀的不同編碼質(zhì)量版本，在發(fā)送前選擇與瞬時(shí)網(wǎng)絡(luò)容量最適配的一個(gè)版本。

3.2 傳輸協(xié)議

監(jiān)控視頻數(shù)據(jù)的收發(fā)采用UDP協(xié)議，壓縮后的每一幀被分成MTU大小(在實(shí)驗(yàn)中設(shè)為1 400字節(jié))的分片，在UDP數(shù)據(jù)報(bào)的數(shù)據(jù)部分頭部增加字段，設(shè)計(jì)應(yīng)用層協(xié)議。設(shè)計(jì)的協(xié)議字段如表1所示。

表1 視頻分片數(shù)據(jù)包協(xié)議字段

接收端收到每一個(gè)分片后都要通過ACK包和發(fā)送方進(jìn)行確認(rèn)，并向發(fā)送方通告一些信息。ACK包的字段如表2所示。

表2 ACK包協(xié)議字段

3.3 接收端

3.3.1 包處理流程

對于收到的來自于發(fā)送方的每一個(gè)視頻分片數(shù)據(jù)包，根據(jù)包頭中的幀號、分片號等信息，處理流程如圖3所示。

圖3 接收方包處理流程

3.3.2 多線程接收解碼

系統(tǒng)為多發(fā)單收模型，需要在接收端同時(shí)接收來自不同攝像頭的數(shù)據(jù)。系統(tǒng)在接收端采用OMP并行框架，開啟多個(gè)線程在不同的端口上接收來自不同攝像頭的數(shù)據(jù)，解碼后存放到各自對應(yīng)的接收緩存隊(duì)列中。與接收線程并行的還有多路視頻的同步線程和視頻拼接線程，整體框架如算法1所示。

算法1：接收端整體框架。

#pragma omp parallel num_threads(n)

{#pragma omp sections

{#pragma omp section/*接收，解碼，入隊(duì)*/

{receive_and_decode(port1, queue1);}

#pragma omp section/*接收，解碼，入隊(duì)*/

{receive_and_decode(port2，queue2):}

……/*根據(jù)攝像頭個(gè)數(shù)*/

#pragma omp section

{prepare1():}/*出隊(duì)至拼接區(qū)、同步*/

#pragma omp section

{prepare2():}/*出隊(duì)至拼接區(qū)、同步*/

……

#pragma omp section

{stitch():}/*拼接*/

}

}

3.4 多路視頻同步

由于要對來自不同攝像頭的不同視頻進(jìn)行拼接，必須保證待拼接的若干張幀相互之間的采集時(shí)間差很小，通常不能超過幾十毫秒，否則可能匹配失敗或者出現(xiàn)明顯的拼接錯(cuò)位甚至出現(xiàn)鬼影。因此，在采集的時(shí)候?yàn)槊恳粠蛏蠒r(shí)間戳。此外，每個(gè)攝像頭在同一時(shí)刻獲取的系統(tǒng)時(shí)間可能本身就存在差值，這個(gè)差值一般可以認(rèn)為是固定的，為此在每個(gè)攝像頭開啟之后，主動(dòng)與接收端進(jìn)行校時(shí)。最后由于各個(gè)攝像頭開啟的時(shí)間不一定相同，設(shè)置只有在所有的待拼接幀都已經(jīng)到達(dá)接收端，并且相互之間的時(shí)間差不超過50 ms時(shí)才能進(jìn)行拼接。由于要對共享數(shù)據(jù)進(jìn)行操作，需配合使用鎖(unique lock)、互斥量(mutex)和條件變量(condition variable)來實(shí)現(xiàn)并發(fā)控制。算法步驟如下：

(1)各攝像頭打開后與接收端校時(shí)，接收端計(jì)算并保存時(shí)間差time_diff_1,time_diff_2…；

(2)根據(jù)攝像頭個(gè)數(shù)設(shè)置標(biāo)志位pic_n_ok，標(biāo)識來自攝像頭n的數(shù)據(jù)是否已經(jīng)準(zhǔn)備好；

(3)接收來自各個(gè)攝像頭的幀，在各自的同步線程等待數(shù)據(jù)沒有準(zhǔn)備好的信號，然后將接收隊(duì)列頭部的幀放入待拼接區(qū)域，并設(shè)置對應(yīng)的標(biāo)志位為TRUE；

(4)拼接線程等待所有的標(biāo)志位均為TRUE后，判斷各幀之間的采集時(shí)間差，若不滿足要求則將時(shí)間過早的幀的標(biāo)志位設(shè)置為FALSE,以便取其下一幀。若滿足條件則將所有的標(biāo)志位設(shè)置為FALSE，通知其他線程準(zhǔn)備下一輪拼接的幀，而后開始拼接。

3.5 實(shí)時(shí)視頻拼接

一般來說，監(jiān)控視頻因?yàn)閿z像機(jī)的位置是固定的，其拼接可以看作是對每一幀的圖像拼接。經(jīng)過3.4中的同步過程后，各待拼接幀的采集時(shí)間已經(jīng)非常接近，當(dāng)某兩幀滿足存在一定的重疊特征時(shí)就可以進(jìn)行拼接。考慮到實(shí)時(shí)性的要求，沒有采用一些拼接效果較好，但計(jì)算復(fù)雜度相對較高，拼接速度較慢的圖像拼接算法如APAP[16]等。系統(tǒng)基于OpenCV提供的圖像處理和拼接的接口，定制了如圖4所示的圖像拼接流程。

圖4 圖像拼接流程

為了提升拼接速度，在特征點(diǎn)檢測、特征點(diǎn)匹配、圖像投影變換階段均使用經(jīng)過GPU加速的OpenCV庫函數(shù)。在圖像融合階段，基于CUDA框架對整個(gè)拼接區(qū)域按像素并行加速填充?？紤]到視頻監(jiān)控的特殊性質(zhì)，有很大一部分情況下監(jiān)控場景并不會(huì)發(fā)生劇烈的變化，尤其是在拼接縫處沒有發(fā)生變化的情況，并不需要重新計(jì)算拼接參數(shù)。因此采用簡單的固定間隔更新拼接參數(shù)的方法，設(shè)置合適的更新間隔，使得系統(tǒng)既能保證較高的幀率，也能在拼接縫處發(fā)生變化時(shí)，在短時(shí)間內(nèi)修復(fù)，保持了良好的視覺效果。

4 系統(tǒng)測試

4.1 實(shí)驗(yàn)環(huán)境

系統(tǒng)在Ubuntu下用C++開發(fā)，兩臺主機(jī)接入同一個(gè)局域網(wǎng)。監(jiān)控發(fā)送端開啟多個(gè)攝像頭，采集視頻并編碼后經(jīng)局域網(wǎng)傳輸?shù)奖O(jiān)控端后實(shí)時(shí)拼接顯示。實(shí)驗(yàn)環(huán)境如表3所示。

表3 監(jiān)控接收端實(shí)驗(yàn)環(huán)境

4.2 性能指標(biāo)

為了驗(yàn)證系統(tǒng)采用的緊耦合式視頻通信框架的有效性，在局域網(wǎng)環(huán)境下使用該系統(tǒng)點(diǎn)對點(diǎn)進(jìn)行視頻監(jiān)控，并測量幀率；通過收發(fā)雙方分別在采集幀和放入顯示隊(duì)列之前記錄時(shí)間點(diǎn)，計(jì)算對應(yīng)同一幀從采集到顯示的時(shí)延，取100幀的平均值；通過計(jì)算收發(fā)雙方對應(yīng)同一幀的SSIM[17]值來衡量視頻質(zhì)量，值越接近1質(zhì)量越高，同樣取100幀的平均值，結(jié)果如表4所示。

表4 傳輸性能

通過實(shí)驗(yàn)可以發(fā)現(xiàn)，系統(tǒng)能夠獲得較小的端到端時(shí)延和較高的視頻質(zhì)量。并且根據(jù)FOULADI團(tuán)隊(duì)的實(shí)驗(yàn)[2]，緊耦合式的視頻架構(gòu)對比WebRTC有較大的性能優(yōu)勢。

在視頻拼接部分，該系統(tǒng)采用固定間隔更新拼接參數(shù)的方法，更新參數(shù)的幀稱為關(guān)鍵幀。關(guān)鍵幀的拼接時(shí)間相對比較長，但是在計(jì)算好的參數(shù)和拼接縫上直接融合，在GPU加速下速度非?？臁Ｈ粼O(shè)置較大的間隔幀數(shù)，實(shí)時(shí)性能較好，但拼接質(zhì)量較差；若設(shè)置較小的間隔幀數(shù)，則拼接質(zhì)量較好，但視頻不夠流暢。又由于受到視頻傳輸端接收幀率的限制，綜合考慮實(shí)時(shí)性能和拼接質(zhì)量，通過設(shè)置合適的間隔幀數(shù)，使得平均幀率略高于接收幀率。由于實(shí)驗(yàn)用攝像頭的限制，分別測試了拼接2路640*480的視頻和3路640*480的視頻，拼接了500幀。分別計(jì)算平均拼接時(shí)間和總體平均拼接時(shí)間，如表5所示。

表5 拼接性能

4.3 實(shí)驗(yàn)效果

在室內(nèi)環(huán)境下分別對2路和3路分辨率為640×48的視頻進(jìn)行了拼接，效果分別如圖5和圖6所示。

圖5 2路視頻拼接效果

圖6 3路視頻拼接效果

5 結(jié)束語

針對傳統(tǒng)視頻通信系統(tǒng)和視頻監(jiān)控中存在的問題，基于新型緊耦合式的視頻通信架構(gòu)，通過設(shè)計(jì)多路視頻間的傳輸協(xié)議和同步算法，并在接收端基于OpenCV的圖像拼接算法定制多路視頻實(shí)時(shí)拼接流程，實(shí)現(xiàn)了一種多攝像頭遠(yuǎn)程全景實(shí)時(shí)監(jiān)控系統(tǒng)。實(shí)驗(yàn)證明，通過設(shè)置適當(dāng)?shù)母麻g隔幀數(shù)，該系統(tǒng)能夠在近實(shí)時(shí)的情況下獲得較好的視頻監(jiān)控質(zhì)量和較寬的監(jiān)控視野。同樣的框架也能應(yīng)用于遠(yuǎn)程災(zāi)情防控指揮、戰(zhàn)場態(tài)勢感知等應(yīng)用場景，具有一定的實(shí)際應(yīng)用價(jià)值。