□胡耀民 晏細蘭
(一)系統物理拓撲結構。由于全景視頻系統是一個實時系統,并且通信量大,無法承受過高的通信代價[1],這時必須為分散式視頻全景系統提供一個高速通信的環境。本系統搭建高速局域網如圖1所示。

圖1 24路視頻全景系統物理拓撲
為了方便攝像機的統一管理,攝像機均連接到固定在攝像機陣列上的一個千兆交互機,而各個計算節點統一連接另一個千兆交換機,最后將兩個交換機通過交換機專用高速接口連接在一起[2~3]。由于計算節點與攝像機通信時交互次數只要兩次,使得實測網絡延時<1ms。
(二)分散式全景視頻系統需求與配置。本系統所需設備:24路網絡攝像頭陣列,能輸出幀率達到25fps的標清視頻;千兆交互機2臺。計算機節點如表1所示。在本次系統設計中選用3臺性能差異較大的計算機作為計算節點以驗證分散式系統在異構環境下仍然能夠發揮作用。此外配置1同時擔任系統控制節點。
本分散式系統需要對管理系統和計算節點分布實現應用

表1 節點配置
程序的接口,管理服務器主要完成參數學習、多分辨瀏覽控制、全景數據融合和節點任務管理;計算節點應用接口負責視頻數據采集、局部全景視頻投影與存儲和多分辨瀏覽數據提取。如圖2所示。

圖2 系統整體方案設計
數據傳輸根據節點的串行方式可以分為節點間網絡傳輸和節點內部數據傳輸。網絡傳輸方面本系統使用TCP/IP網絡傳輸協議,該協議提供無邊界數據傳輸,帶有糾錯功能,能實現無丟失的數據交換,傳輸能力主要由網絡的傳輸帶寬和節點的網絡數據交換能力決定。本系統使用的是千兆交互機和千兆網卡,交換機能實現線路的自動開關,使得端與端之間的數據交換互不影響,也就是說各個計算節點都能實現1,000Kb/s的數據交換能力。節點內部數據傳輸通過數據總線決定,其數據交換能力非常大,相對于網絡傳輸其數據交換代價可以忽略不計。根據串行任務中交換數據的不同,對網絡數據傳輸需求主要模塊作出如下分析。
(一)攝像機至采集模塊。攝像機輸出數據采用H.264的MPG4編碼方式,該方式通過設定關鍵幀與幀間差分的方式去除視頻中的冗余信息,實現高壓縮比的視頻壓縮。由于本系統中全景目標幀率為10fps,所以把攝像機的物理采集幀率與關鍵幀隔設定為10fps,這時視頻碼率設定為2Mb/s時視頻圖像能保持較好質量。24路視頻數據均在一個交換機出口輸出,輸出帶寬需求為24×2Mb/s=48Mb/s,遠低于交換機的帶寬容量。
(二)采集模塊至投影模塊。如果該兩個模塊被分配到了不同的節點,必須通過網絡傳輸。采集模塊通過解碼后,把每幀圖片提取出來,對于720p圖像,其原始大小為1,280×720×3×8bit≈21Mbit,對于視頻為10fps的處理速度其帶寬需求為210Mb/s,雖然網絡帶寬能滿足需求,但是也會造成每幀在網絡傳輸上花費21ms,由于串行流水線操作中數據傳輸是必要開支,對本系統中流水線單步執行時間限制在100ms以內的需求來說網絡傳輸花費時間太多。為了減少網絡傳輸數據,必須對圖像進行壓縮,本系統利用JPEG圖像壓縮,在壓縮比在15∶1時,一幀圖像大小約在1.4Mbit,網絡傳輸時間為1.4ms,另外壓縮圖像也會增加另外的編解碼計算成本,實際測試中,不同計算能力的計算機對720p圖像進行JPGE編碼和解碼時間為2~6ms內,所以采用圖像壓縮后傳輸圖像顯得更加效率。
(三)投影模塊至壓縮模塊。由于本系統中攝像機除了角度參數外其他參數基本相同,所以圖像在投影變換后畸變一般很小,大小與原始圖像相仿,其網絡要求與(2)是一樣的。
以上分析是根據理論值計算的,實際測試中根據圖像內容和網絡瞬時狀態存在10%~20%左右的浮動??梢钥闯?,數據傳輸是流水線操作上的產品傳遞時間,該時間由各個傳輸過程中最慢的一塊決定,即裁剪模塊至融合模塊,也就是說提供給各個模塊的最大計算時間為75ms,大于該時間會出現流水線不同步,任務堆積在某一個模塊。
(一)任務功耗需求計算。以配置3為任務測試環境,測試各個任務1,024次,其中t3以其最大值(視窗分辨率和圖像分辨率一致并包含整個圖像)計算結果如表2所示。

表2 任務需求
從表2可以看出,其通信消耗非常大,說明優秀的分配結果基本上會是把任務直接本地串行以減少傳輸消耗,只有在考慮任務均衡時才會引入少量傳輸消耗。

表3 節點測試
綜上所述,可以看出本系統對24路全景視頻的處理還是有一定的負荷余量,通過調節幀率或擴大陣列規模,系統效率還可以提高。分散式系統對實時和異構系統都有很好的適用性。通過繼續擴大節點規模,各個節點的負荷率將會減少,當規模達到一定程度時,基本可以達到在不影響各個節點用戶本身的使用需求下,仍然保證系統的流暢運行。