全景視頻拼接分散式系統(tǒng)的研究與設(shè)計

晏細蘭

（廣州番禺職業(yè)技術(shù)學(xué)院信息工程學(xué)院，廣東 廣州511483）

圖1 應(yīng)用程序設(shè)計

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

1 分散式全景視頻系統(tǒng)節(jié)點配置

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

2 系統(tǒng)整體應(yīng)用接口實現(xiàn)

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

3 系統(tǒng)任務(wù)測試與分配

3.1 節(jié)點性能測試

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

圖2 節(jié)點1 運行負載

圖3 節(jié)點2 運行負載

根據(jù)式（1）各個節(jié)點的容量為：

表1 節(jié)點容量

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

表2 乘上權(quán)值后的節(jié)點容量

3.2 系統(tǒng)實時運行負荷

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

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

4 結(jié)論

本文利用分散式系統(tǒng)的基本設(shè)計方法，設(shè)計了一個能實時生成并分散式保存視頻全景數(shù)據(jù)的系統(tǒng)，實驗結(jié)果表明本系統(tǒng)設(shè)計的任務(wù)分配方案具有一定的可用性，能夠?qū)崟r的生成全景視頻。