全景視頻拼接分散式系統的研究與設計

晏細蘭

（廣州番禺職業技術學院信息工程學院，廣東 廣州511483）

圖1 應用程序設計

隨著視頻監控的市場規模逐步擴大，人們不需要再花費大量的人力和精力去現場進行監視或者指導，而是通過網絡把不同地方的監控數據集中到一個監控中心進行觀察和記錄[1]。正是因為監控設備與監控者在空間上的分離，在監控區域出現問題時監控者無法馬上到達監控區域進行更全面的記錄，因此監控者不希望由于監控設備性能的不足而無法獲取更加詳細的監控內容。在需要監控一個大場景時，現有方法可以采用擁有較大視角的鏡頭如魚眼鏡頭和廣角鏡頭等獲得大視角的監控，但這些鏡頭會使得視頻內容出現嚴重畸變。此外，由于攝像機技術限制，攝像機分辨率有限，用單個攝像機觀察大視場必然會犧牲細節內容，而細節往往才是我們感興趣的。目前為了滿足大場景高分辨率監控的需求，一般采用多個攝像機分別監控視場中的各個位置，但是由于攝像機監控區域的不一致，導致整體監控內容具有不連續性，一個移動目標會在不同攝像機中反復跳轉，因為對監控者來說，要在不同攝像機中找到一個連續運動的目標往往非常困難，所以希望找到一種方法能保持目標的連續性。本文以解決大規模視頻全景攝像機陣列中計算量需求巨大的問題為主要研究內容[2-3]，設計了一個能實時生成并分散式保存視頻全景數據的系統。

1 分散式全景視頻系統節點配置

本系統的性能指標為實現24 路720p 視頻陣列的全景拼接，視場重疊區域小于25%，總分辨率達到1 千6 百萬，全景視頻播放幀率達到10fps，用戶能通過多分辨的方式瀏覽和存儲全景視頻。計算機節點位三個配置，配置1 和配置2CPU 均為Core-i7 3.4GHz 四核八線程，配置2 為Pentium4 3.0GHZ 雙核，所需內存依次為16GB，4GB 和2GB，操作系統均為Windows10系統。

2 系統整體應用接口實現

本分散式系統需要對計算節點實現應用接口，一個計算節點可以并行處理多路視頻數據，也可以和其他節點串行以流水線方式完成某路視頻數據，具體根據管理服務器來自動分配。各個節點把圖像按照多分辨瀏覽參數提取局部圖像后傳輸到服務器的融合模塊，由于多分辨瀏覽中視窗大小一致，該帶寬需求主要取決于視窗大小，本系統中視窗大小設定為1280x720，再考慮各視場存在20%左右的重疊區域，所包含的融合數據大小應該是視場大小的1.96 倍，即每幀41.2Mbit。同樣該數據量延時也是不可接受的，所以也需要做壓縮，每幀延時為7～15ms。服務器與節點的控制信息是小數據指令，可以忽略其傳輸消耗，而投影參數傳遞為一次性傳遞，沒有事實要求，所以也不考慮其帶寬消耗。系統設計如圖1 所示。

3 系統任務測試與分配

3.1 節點性能測試

設總體任務量Q 固定，節點i 由0 開始，直到t 達到收斂，收斂時間為t'，則節點i 的性能容量為：

圖2 節點1 運行負載

圖3 節點2 運行負載

根據式（1）各個節點的容量為：

表1 節點容量

由于該容量為系統空載下測試的結果，由于節點1 處理計算節點同時還作為系統管理節點，而節點2 有別的用戶使用需求，只能提供部分資源，所以這里設定各個節點的權值為0.5、0.5、1。即有：

表2 乘上權值后的節點容量

3.2 系統實時運行負荷

在打開2 路全景時，幀率保持10fps，此時各個節點的瞬時運行負載如圖2、3。

節點2 和節點3 與理論結果是比較接近的，而節點1 在同時作為管理節點的情況下，運行負載仍然要比理論值低，說明單純用某個任務去比較各個節點的性能不夠全面，原因是不同節點可能對同一任務的處理效率不一樣。此外，同一個節點中各個CPU 的負載也不近相同，出現了個別CPU 滿負載運行，其他CPU 半負載的情況，這主要是一個線程只能利用一個邏輯核心線程的資源，而分配的任務線程數量與節點邏輯核心線程數量不為公約數而導致的，所以在任務分配時也要考慮著方面的約束條件。但總體來看，本系統設計的任務分配方案還是具有一定的可用性。

4 結論

本文利用分散式系統的基本設計方法，設計了一個能實時生成并分散式保存視頻全景數據的系統，實驗結果表明本系統設計的任務分配方案具有一定的可用性，能夠實時的生成全景視頻。