遠程全景實時監控系統設計與實現

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

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

0 引 言

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

1 相關關鍵技術

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

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

(1)基于現有的編解碼器進行改造，退變為純函數式編碼器，不再控制比特率而只提供編解碼的接口；在編解碼器中引入“狀態(state)”的概念，每一個狀態值與每一次編碼一幀時所用的參數相關，在收發雙方的內存中維護了狀態隊列，用類似于TCP滑動窗口的模式來管理隊列中的狀態并實現收發雙方狀態的同步。

(2)通過指數加權移動平均法(exponentially weighted moving average，EWMA)計算平均包到達時延，并據此計算當前網絡容量，實現幀的編碼長度和瞬時網絡容量的最佳適配。

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

1.2 視頻拼接技術

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

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

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

2 系統架構

設計并實現的系統主要功能模塊有：

(1)多路視頻的采集；

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

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

系統的整體架構如圖2所示。

圖2 系統架構

3 系統實現

3.1 發送端

3.1.1 視頻采集

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

3.1.2 視頻編碼

采用FOULADI團隊[2]基于libvpx庫進行改造實現的純函數式編解碼器，視頻格式采用VP8[13]。其中編碼過程的各個環節，包括：變換、預測、自適應量化、環路濾波和和熵編碼均按照VP8的官方文檔[14]實現。唯一的區別是將編碼器內部的“狀態”暴露出來供外部使用，其編解碼接口如下：

encode (state, image, quality) → frame

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

其中state表示編碼器的內部狀態，在實現中是前一幀解碼時使用的參考幀和熵編碼概率表的哈希值。由于采用預測編碼的編碼器需要進行幀的重構，編碼器實際上包含了解碼器的完整實現[15]。因此收發雙方可以實現狀態轉換的同步。quality參數用來設置同一幀的不同編碼質量版本，在發送前選擇與瞬時網絡容量最適配的一個版本。

3.2 傳輸協議

監控視頻數據的收發采用UDP協議，壓縮后的每一幀被分成MTU大小(在實驗中設為1 400字節)的分片，在UDP數據報的數據部分頭部增加字段，設計應用層協議。設計的協議字段如表1所示。

表1 視頻分片數據包協議字段

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

表2 ACK包協議字段

3.3 接收端

3.3.1 包處理流程

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

圖3 接收方包處理流程

3.3.2 多線程接收解碼

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

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

#pragma omp parallel num_threads(n)

{#pragma omp sections

{#pragma omp section/*接收，解碼，入隊*/

{receive_and_decode(port1, queue1);}

#pragma omp section/*接收，解碼，入隊*/

{receive_and_decode(port2，queue2):}

……/*根據攝像頭個數*/

#pragma omp section

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

#pragma omp section

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

……

#pragma omp section

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

}

}

3.4 多路視頻同步

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

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

(2)根據攝像頭個數設置標志位pic_n_ok，標識來自攝像頭n的數據是否已經準備好；

(3)接收來自各個攝像頭的幀，在各自的同步線程等待數據沒有準備好的信號，然后將接收隊列頭部的幀放入待拼接區域，并設置對應的標志位為TRUE；

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

3.5 實時視頻拼接

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

圖4 圖像拼接流程

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

4 系統測試

4.1 實驗環境

系統在Ubuntu下用C++開發，兩臺主機接入同一個局域網。監控發送端開啟多個攝像頭，采集視頻并編碼后經局域網傳輸到監控端后實時拼接顯示。實驗環境如表3所示。

表3 監控接收端實驗環境

4.2 性能指標

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

表4 傳輸性能

通過實驗可以發現，系統能夠獲得較小的端到端時延和較高的視頻質量。并且根據FOULADI團隊的實驗[2]，緊耦合式的視頻架構對比WebRTC有較大的性能優勢。

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

表5 拼接性能

4.3 實驗效果

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

圖5 2路視頻拼接效果

圖6 3路視頻拼接效果

5 結束語

針對傳統視頻通信系統和視頻監控中存在的問題，基于新型緊耦合式的視頻通信架構，通過設計多路視頻間的傳輸協議和同步算法，并在接收端基于OpenCV的圖像拼接算法定制多路視頻實時拼接流程，實現了一種多攝像頭遠程全景實時監控系統。實驗證明，通過設置適當的更新間隔幀數，該系統能夠在近實時的情況下獲得較好的視頻監控質量和較寬的監控視野。同樣的框架也能應用于遠程災情防控指揮、戰場態勢感知等應用場景，具有一定的實際應用價值。