韓 杰，陳耀武

（浙江大學(xué)數(shù)字技術(shù)及儀器研究所，杭州310027）

1 概述

隨著安防監(jiān)控行業(yè)的高速發(fā)展，智能監(jiān)控和云計算技術(shù)的結(jié)合成為重要的研究方向［1－2］。智能視頻監(jiān)控通過對視頻畫面中的海量數(shù)據(jù)進行高速分析，能快速提供感興趣的信息或?qū)崟r異常告警［3］。由于通用計算機強大的處理能力和低廉的價格，可以利用集群為多臺監(jiān)控終端提供耗時的視頻分析服務(wù)。目前很多視頻分析系統(tǒng)基于離線視頻處理［4－5］，應(yīng)用Hadoop分割視頻并通過集群完成大規(guī)模運算，但是數(shù)據(jù)收集、備份以及磁盤操作使得其很難實現(xiàn)秒級的延時。

Storm［6］是Twitter開源的一個流計算框架，和其他流計算產(chǎn)品相比更加成熟。Storm能快速可靠地處理源源不斷的消息，具有良好的容錯機制，并且提供任務(wù)分配、集群管理、性能監(jiān)控等功能。

本文設(shè)計一個基于Storm云平臺的實時視頻分析系統(tǒng)，并進行以下工作：（1）根據(jù)H．264視頻特點設(shè)計一個實時環(huán)境下的流分割方案；（2）提出視頻處理機制，利用工作竊取機制加速算法執(zhí)行；（3）通過改進Storm調(diào)度算法提高系統(tǒng)的實時性能。

2 整體設(shè)計

系統(tǒng)的整體設(shè)計框圖如圖1所示。首先緩存主要考慮到設(shè)備碼率的波動，添加緩存可以保證集群均勻地訂閱視頻流，改善集群性能和穩(wěn)定性，對整體時延的增加也不明顯；另外對設(shè)備和Storm集群進行隔離，并且方便應(yīng)用層對系統(tǒng)進行控制。

圖1 基于Storm的實時視頻分析系統(tǒng)總體框架

Storm集群由運行Nimbus的主控節(jié)點和運行Supervisor的工作節(jié)點組成，Supervisor負(fù)責(zé)接收任務(wù)并管理自己的worker進程，worker進程中運行著Topology任務(wù)。每路設(shè)備作為一個拓?fù)涮峤籒imbus。Spout實例抽象成一路設(shè)備訂閱緩存中的一路碼流，將連續(xù)的流進行完整性分割，然后發(fā)射到集群進行后續(xù)處理，并行度設(shè)置為1。DecAlgBolt任務(wù)負(fù)責(zé)分割單元的解碼以及視頻分析，這個最耗時的任務(wù)在集群中會實例化多個以充分利用集群的性能。MergeBolt任務(wù)負(fù)責(zé)收集識別結(jié)果并且實時通知應(yīng)用層或者持久化寫入數(shù)據(jù)庫。應(yīng)用服務(wù)層提供實時訂閱、系統(tǒng)監(jiān)控、結(jié)果檢索等服務(wù)。

3 Storm平臺下實時視頻分析系統(tǒng)的實現(xiàn)

3．1 視頻流分割

視頻原始數(shù)據(jù)會占用巨大的網(wǎng)絡(luò)傳輸帶寬，以D1＠25fps為例，如果在集群中采用還原的原始視頻數(shù)據(jù)，每一路視頻需要150Mb／s帶寬，在千兆以太網(wǎng)的集群內(nèi)最多為6路設(shè)備提供服務(wù)。

本文針對H．264視頻的特點，以GOP為單位處理視頻，并且由于組件的無狀態(tài)性，需要附上該通道最新的序列參數(shù)集（Sequence Parameter Set，SPS）和圖像參數(shù)集（Picture Parameter Set，PPS）為解碼器提供解碼參數(shù)。具體流分割過程如圖2的步驟（1）～步驟（5）所示。

圖2 視頻流分割具體步驟

GOP大小的選取是帶寬和集群性能之間的博弈。較小的GOP會大幅增加視頻碼流的帶寬，但大的GOP導(dǎo)致消息的處理時間過長影響集群的性能。文獻［7］在MPEG視頻人臉識別系統(tǒng)中選擇12幀～15幀的GOP長度，而且由于視頻中的目標(biāo)在畫面中的存在時間通常大于一個12幀～15幀的GOP時長，因此選擇GOP長度為12，相比于1s的GOP設(shè)置，在靜態(tài)場景下會有不超過50%的帶寬提高，但是由于靜態(tài)場景的本身碼率很低，而且在場景變化劇烈的情況下，GOP＝12較GOP＝25帶寬變化并不明顯。選擇12的另一個原則是基于均勻跳幀考慮的，可以間隔1幀、2幀、3幀、5幀減小冗余運算。

3．2 FFmpeg解碼與視頻分析

采用FFmpeg完成H．264解碼工作。FFmpeg是一個集錄制、轉(zhuǎn)換、音／視頻編碼解碼功能為一體的完整開源解決方案［8］，由于是 C／C＋＋開發(fā)，在Java環(huán)境中為了高效執(zhí)行解碼任務(wù)，通過Java本地接口（Java Native Interface，JNI）技術(shù)調(diào)用FFmpeg本地庫中的方法，提高解碼效率。

DecodeAnalyseBolt為解碼單元和視頻分析單元的任務(wù)處理器，主要流程如下：

Step1DecodeAnalyseBolt在Storm集群中實例化，在prepare方法中創(chuàng)建H264Decoder，創(chuàng)建實際的視頻分析服務(wù)，創(chuàng)建FrameManager用于解碼和視頻分析線程之間的緩沖，創(chuàng)建視頻分析線程。

Step2運行時，接收消息，并同時執(zhí)行H．264解碼以及視頻分析算法，每分析完一幀發(fā)射處理結(jié)果，最終處理完整個消息發(fā)出回應(yīng)。由于解碼速度通常會遠(yuǎn)大于視頻分析算法的速度，因此可以利用多核處理器優(yōu)勢，使用工作竊取（work stealing）［9］機制，在相應(yīng)視頻幀解碼完成后“竊取”分析線程任務(wù)隊列另外一端的任務(wù)，并調(diào)用前面創(chuàng)建的視頻分析服務(wù)，減小算法的執(zhí)行時間。圖3為跳幀間隔為1和2下的任務(wù)序列。

圖3 工作竊取機制下的任務(wù)序列

3．3 Storm調(diào)度算法改進

Storm默認(rèn)的調(diào)度器采用了round－robin機制將每個spout，bolt組件的實例依次分配到配置好的workers中，并將所有workers盡量等量地分配到每臺Worker節(jié)點。這種簡單的分配機制有時也帶來了一定的限制，如圖4所示，后加入機器c，d的Topology4，Topology 5的任務(wù)屬于重負(fù)載，那么c，d就可能會長期處于overload狀態(tài)，影響整體性能，而對于其他機器來說可能存在部分性能浪費。

圖4 默認(rèn)調(diào)度器下的任務(wù)分配結(jié)果

文獻［10－11］從Tuple的傳輸角度改進Storm默認(rèn)的調(diào)度機制，避免大量的網(wǎng)絡(luò)傳輸來改善系統(tǒng)性能。本文從worker的遷移角度動態(tài)調(diào)節(jié)系統(tǒng)的負(fù)載。調(diào)度器的實現(xiàn)機制如圖5所示。worker后臺線程通過zk寫入該worker平均CPU占用率，Worker節(jié)點上的Supervisor后臺進程也有一個監(jiān)控線程，該線程記錄的是本節(jié)點的平均CPU load。

圖5 調(diào)度器實現(xiàn)機制

調(diào)度算法使用了貪心和置換策略。具體描述如下：對于新提交的Topology，可以使用默認(rèn)的調(diào)度器將該Topology需要的worker數(shù)分配到空閑的slot。對于已經(jīng)分配的任務(wù)，找到當(dāng)前Load最高的Worker Nodei，現(xiàn)在目標(biāo)是要將該節(jié)點上的某個worker移動或者置換到其他節(jié)點j，使該節(jié)點Wi1和移動（滿足式（1））或置換（滿足式（2））后的節(jié)點Wi2滿足以下約束條件：

式（1）的做法是直接將wj（workerj）中的executors分配到Wi2可用的slot中。式（2）是因為已經(jīng)沒有slot數(shù)可用了但是此時的負(fù)載存在著不均衡，這時為了改善節(jié)點i的性能，采取的做法是找到節(jié)點k，在k上尋找一個 workerwk，j，將wk，j中的任務(wù)踢出去，空出的slot用于完成式（1）的分配，被提出的任務(wù)需要分配到節(jié)點i空出的slot，稱為一次置換過程。如果遍歷所有節(jié)點采用式（1）和式（2）沒有找到符合條件的方案，則本次處理失敗。如果多次在同一個節(jié)點失敗，則可能要考慮找出這個節(jié)點中l(wèi)oad最大的worker并終止屬于它的topology。算法的偽代碼描述如下：

4 實驗結(jié)果與分析

實驗環(huán)境為槍機和球機設(shè)備以及由PC組成的集群。監(jiān)控設(shè)備的輸出碼流規(guī)格為：H264MP，D1＠25fps以及720＠25fps，VBR，GOP＝12，設(shè)備和集群通過千 兆 交 換 機 連 接，PC 為i5－34704GRAM，運 行Ubuntu，系統(tǒng)上安裝JDK1．6，Zookeeper，ZeroMQ2．17，F(xiàn)Fmpeg2．2．4及Storm0．9．1。

本次視頻分析對象是人臉，人臉?biāo)惴ㄊ褂玫氖荗penCV的級聯(lián)目標(biāo)分類器識別算法［12］，表1給出了本次實驗單機測試下的耗時。

表1 單機下的各項耗時 ms

從表1中可以看出，在一組GOP測試中，由于使用了work stealing機制，使跳幀為6下的處理速度提高了30%，跳幀為10下由于一組只有2幀，一幀的分析時間和幀組的解碼時間接近因此提升不明顯。

為測量系統(tǒng)實時性和Storm調(diào)度算法的改進效果，預(yù)先錄制了一段固定時間間隔（5 s）出現(xiàn)人臉的視頻，然后在大屏幕播放并對著不同制式的網(wǎng)絡(luò)攝像機，同時運行該系統(tǒng)統(tǒng)計MergeBolt的識別結(jié)果出現(xiàn)時間，消息處理延時定義為分割完成到識別結(jié)束的時間。有一臺運行緩存系統(tǒng)，集群中1臺運行Nimbus，UI以及Zookeeper，還有3臺運行supervisor，終端共接入12路IPC，其中9路為D1碼流，3路為720P。圖6為其中一路D1槍機在默認(rèn)調(diào)度器以及改進調(diào)度器下隨時間消息處理延時的情況（跳幀為10）。

圖6 某D1通道下的消息處理延時

從圖6可以看出，由于加入了3個720P負(fù)載較大的設(shè)備，因此默認(rèn)情況下發(fā)現(xiàn)其中2臺機器的負(fù)載情況一直很高，workers在這2臺機器上的消息處理時間就會大大增加。在改進的調(diào)度器下，在20s時進行了rebalance，因此后面的消息延時相對比較穩(wěn)定，并低于默認(rèn)的情況。表2為上述集群配置下系統(tǒng)的整體延時測試。

表2 系統(tǒng)整體延時 ms

從表2看出，負(fù)載增加時，系統(tǒng)整體延時增加并不明顯。由于終端和緩存的時間比較固定，通常在600 ms左右，主要是在負(fù)載增加時會導(dǎo)致延時增加，但因為集群的動態(tài)負(fù)載調(diào)節(jié)所以延時增加并不明顯。因此基于Storm平臺的實時視頻分析系統(tǒng)能在多路負(fù)載的情況下提供低于1 s的視頻分析服務(wù)，并且基于Storm本身高度容錯的特點，該系統(tǒng)能在云環(huán)境下提供可靠的服務(wù)。

5 結(jié)束語

本文根據(jù)云計算平臺下智能視頻分析的實時性需求，設(shè)計了基于Storm的實時視頻處理系統(tǒng)。利用GOP流分割策略降低系統(tǒng)整體延時，解碼和視頻分析算法利用工作竊取機制加速集群內(nèi)消息的處理速度，并通過Storm平臺調(diào)度器的改進防止任務(wù)分配不均。實驗結(jié)果表明，本文提出的系統(tǒng)能為網(wǎng)絡(luò)環(huán)境中的多路終端設(shè)備提供實時視頻分析服務(wù)，延時為1 s～2 s，基本滿足視頻分析的需求。本文系統(tǒng)基于H．264格式以及較短的GOP設(shè)置，但是云環(huán)境下視頻的格式以及規(guī)格較多，如何兼容這些視頻并適合分布式處理是下一步的研究重點。

［1］Neal D，Rahman S．Video Surveillance in the Cloud［J］．International Journal of Cryptography and Information Security，2012，2（3）．

［2］武文斌．智能視頻分析的現(xiàn)狀與未來發(fā)展趨勢［J］．科技情報開發(fā)與經(jīng)濟，2011，21（31）：168－171．

［3］鄭世寶．智能視頻監(jiān)控技術(shù)與應(yīng)用［J］．電視技術(shù)，2009，（1）：94－96．

［4］高東海，李文生，張海濤．基于 Hadoop的離線視頻處理技術(shù)研究與實現(xiàn)［J］．軟件，2013，34（11）：5－9．

［5］Yang Fan，Shen Qiwei．Distributed Video Transcoding on Hadoop［J］．Computer Systems ＆ Applications，2011，20（11）：80－85．

［6］Lee H，Sull S．A VBR Video Encoding for Locally Consistent Picture Quality with Small Buffering Delay Under Limited Bandwidth［J］．IEEE Transactions on Broadcasting，2012，58（1）：47－56．

［7］Wang Hualu，Chang Shih－Fu．A Highly Efficient System for Automatic Face Region Detection in MPEG Video［J］．IEEE Transactions on Circuits and Systems for Video Technology，1997，7（4）：615－628．

［8］Bellard F．Ffmpeg［EB／OL］．（2014－10－10）．http：／／www．ffmpeg．org．

［9］Blumofe R D， Leiserson C E． Scheduling Multithreaded Computations by Work Stealing［J］．Journal of the ACM，1999，46（5）：720－748．

［10］Aniello L，Baldoni R，Querzoni L．Adaptive Online Scheduling in Storm［C］／／Proceedings of the 7th ACM International Conference on Distributed Event－based Systems．New York，USA：ACM Press，2013：207－218．

［11］Xu Jielong，Chen Zhenhua，Tang Jian，et al．T－storm：Traffic－aware Online Scheduling in Storm ［C］／／Proceedings of the 34th International Conference on Distributed Computing Systems．Washington D．C．，USA：IEEE Press，2014：535－544．

［12］Heisele B，Serre T，Poggio T．A Component－based Framework for Face Detection and Identification［J］．International Journal of Computer Vision，2007，74（2）：167－181．