一種多路視頻流并行化處理方法

一種多路視頻流并行化處理方法

基于ha的基于源的分布計(jì)算結(jié)構(gòu)，它是目前并行處理平臺(tái)的代表，文獻(xiàn)。1相關(guān)研究1.1實(shí)時(shí)應(yīng)用程序控制Storm是實(shí)時(shí)的并具備高容錯(cuò)的分布式計(jì)算系統(tǒng)，主要由一個(gè)主節(jié)點(diǎn)(Nimbus)和一群工作節(jié)點(diǎn)(Worker)組成，同時(shí)每個(gè)工作節(jié)點(diǎn)上運(yùn)行一個(gè)監(jiān)督節(jié)點(diǎn)(Supervisor)，通過(guò)Zookeeper進(jìn)行協(xié)調(diào)。主節(jié)點(diǎn)負(fù)責(zé)任務(wù)分配，并監(jiān)控狀態(tài)。監(jiān)督節(jié)點(diǎn)會(huì)監(jiān)聽所分配子節(jié)點(diǎn)機(jī)器的任務(wù)狀態(tài)，根據(jù)需要啟動(dòng)/關(guān)閉工作進(jìn)程。Storm中，各個(gè)組件間的消息流動(dòng)形成邏輯上的拓?fù)浣Y(jié)構(gòu)，故運(yùn)行一個(gè)實(shí)時(shí)應(yīng)用程序通過(guò)提交拓?fù)?Topology)完成。如圖1所示，Spout是消息的生產(chǎn)者，負(fù)責(zé)數(shù)據(jù)的抓取，從來(lái)源處讀取數(shù)據(jù)放入拓?fù)?，然后以元組(Tuple)的形式發(fā)送到數(shù)據(jù)流中，Bolt封裝了所有的消息處理邏輯，通過(guò)流分組(StreamGrouping)將Spouts與Bolts連接起來(lái)。1.2st模型算法的并行人車分類主要分為4個(gè)部分:感興趣前景區(qū)域的提取，目標(biāo)跟蹤預(yù)測(cè)，特征提取，目標(biāo)分類。流程如圖2所示。前景區(qū)域的提取是視頻分析的最初階段，將運(yùn)動(dòng)目標(biāo)從背景中分離，為下一階段的跟蹤與識(shí)別做準(zhǔn)備。目標(biāo)跟蹤是對(duì)場(chǎng)景中的感興趣目標(biāo)進(jìn)行預(yù)測(cè)與定位，可以更準(zhǔn)確地得到目標(biāo)的運(yùn)動(dòng)狀態(tài)。通過(guò)特征提取與目標(biāo)識(shí)別對(duì)運(yùn)動(dòng)信息進(jìn)行篩選，對(duì)人車信息進(jìn)行識(shí)別。在Storm集群中每個(gè)處理的元組相互獨(dú)立，算法的并行實(shí)際是基于文件的并行實(shí)現(xiàn)。本文使用多幀差分法提取前景區(qū)域，卡爾曼濾波實(shí)現(xiàn)目標(biāo)跟蹤預(yù)測(cè)，采用HOG算子與SVM算法實(shí)現(xiàn)目標(biāo)的識(shí)別分類，在實(shí)現(xiàn)每段視頻數(shù)據(jù)處理完整性的前提下也能準(zhǔn)確檢測(cè)出人車目標(biāo)。2車分類及核心任務(wù)并行化本文利用Storm并行化處理框架實(shí)現(xiàn)基于海量視頻流的人車分類，核心思想是將計(jì)算任務(wù)分配給多個(gè)節(jié)點(diǎn)，通過(guò)任務(wù)并行化達(dá)到提升性能的目的。主要包括如下步驟:緩存視頻流獲取、自定義VideoStreamSpout類組件、算法融合。2.1rtsp視頻流的數(shù)據(jù)處理遠(yuǎn)程攝像頭捕捉到的視頻數(shù)據(jù)，通過(guò)網(wǎng)絡(luò)傳輸?shù)奖镜卦破脚_(tái)處理。流媒體在傳輸?shù)倪^(guò)程中，由于帶寬等的影響，不可避免地會(huì)出現(xiàn)數(shù)據(jù)丟失或失序的現(xiàn)象，而且數(shù)據(jù)采集的速度和數(shù)據(jù)處理的速度不一定同步，會(huì)造成數(shù)據(jù)堵塞。RTSP視頻流為幀與幀之間連續(xù)相關(guān)的非結(jié)構(gòu)化數(shù)據(jù)流，物理分割會(huì)造成幀不完整、分割后缺少關(guān)鍵幀(I幀)的問(wèn)題，因此需要對(duì)視頻流數(shù)據(jù)解耦合。提出了一種基于關(guān)鍵幀的視頻流緩存方法，如圖3所示，視頻圖像以序列為單位進(jìn)行組織，一個(gè)序列是一段圖像編碼后的數(shù)據(jù)流，以關(guān)鍵幀開始到下一個(gè)關(guān)鍵幀結(jié)束。根據(jù)關(guān)鍵幀的位置進(jìn)行緩存，可以保證所有的緩存塊都有必要的幀信息，不會(huì)出現(xiàn)缺少關(guān)鍵幀無(wú)法解碼的問(wèn)題。2.2存儲(chǔ)獨(dú)立sds的存儲(chǔ)信息自定義VideoStreamSpout類組件，通過(guò)繼承BaseRichSpout接口實(shí)現(xiàn)數(shù)據(jù)讀取，數(shù)據(jù)讀取流程如圖4所示。如2.1節(jié)所述獲取獨(dú)立的緩存視頻流，當(dāng)緩存流達(dá)到元組要求就以隊(duì)列形式推送。open()方法打開緩存流，將數(shù)據(jù)封裝成一個(gè)個(gè)Tuple，通過(guò)nextTuple()方法不間斷發(fā)送新的Tuple到消息隊(duì)列。為保證數(shù)據(jù)的連續(xù)性，每個(gè)Tuple會(huì)隨機(jī)分發(fā)唯一的ID。拓?fù)涮峤缓髸?huì)一直運(yùn)行直到被手動(dòng)殺死。此外，Storm在檢測(cè)到一個(gè)元組被成功處理時(shí)調(diào)用ack()方法，否則調(diào)用fail()方法，這樣保證了數(shù)據(jù)處理的可靠性。2.3c/c++語(yǔ)言及其數(shù)據(jù)資源整合計(jì)算任務(wù)主要在VideoStreamBolt環(huán)節(jié)實(shí)現(xiàn)，VideoStreamBolt組件與VideoStreamSpout組件之間通過(guò)松耦合的管道機(jī)制實(shí)現(xiàn)流傳輸，這種調(diào)度機(jī)制極大提升了并行計(jì)算的穩(wěn)定性和可擴(kuò)展性。Storm的拓?fù)浣Y(jié)構(gòu)通過(guò)Java語(yǔ)言實(shí)現(xiàn)，Java語(yǔ)言因其簡(jiǎn)單、面向?qū)ο?、可移植、平臺(tái)無(wú)關(guān)等特性，已成為分布式計(jì)算領(lǐng)域的主流程序設(shè)計(jì)語(yǔ)言。影響Java語(yǔ)言算法實(shí)現(xiàn)的最大問(wèn)題是速度，在原始的Java解釋器中，C語(yǔ)言的速度是解釋過(guò)的Java語(yǔ)言的20倍左右，用Java語(yǔ)言來(lái)完成對(duì)性能敏感的高性能密集計(jì)算目前不是最好的選擇。視頻的解碼及人車分類算法分別使用FFMPEG視頻圖像編解碼庫(kù)與Opencv開源計(jì)算機(jī)視覺(jué)處理庫(kù)實(shí)現(xiàn)，采用C/C++語(yǔ)言編寫，在不改變并行結(jié)構(gòu)及算法效率的情況下，Java的JNI(JavaNativeInterface)接口實(shí)現(xiàn)了Java數(shù)據(jù)與C++本地庫(kù)的數(shù)據(jù)交互，但頻繁的數(shù)據(jù)拷貝會(huì)大大降低數(shù)據(jù)傳遞的效率及穩(wěn)定性，且當(dāng)交換數(shù)據(jù)塊較大時(shí)，會(huì)造成內(nèi)存泄漏，對(duì)計(jì)算機(jī)內(nèi)存造成較大損耗。同時(shí)頻繁的數(shù)據(jù)拷貝造成算法的延時(shí)在流式計(jì)算中會(huì)產(chǎn)生數(shù)據(jù)堵塞。本文提出了一種優(yōu)化的高效并行內(nèi)存共享機(jī)制，可以最大化優(yōu)化代碼的運(yùn)算速度，具體結(jié)構(gòu)如圖5所示。在該機(jī)制中，Java端作為程序的起始端，負(fù)責(zé)任務(wù)的分發(fā)及資源調(diào)度，構(gòu)建并行計(jì)算環(huán)境。當(dāng)有數(shù)據(jù)交互發(fā)生時(shí)，Java端開辟堆內(nèi)存空間與JNI層共享，并將數(shù)據(jù)信息導(dǎo)入共享內(nèi)存，通過(guò)地址值的傳遞，實(shí)現(xiàn)本地算法與Java端的數(shù)據(jù)交互，同時(shí)，也可以通過(guò)并行內(nèi)存共享機(jī)制，將本地算法處理完成后的人車等目標(biāo)信息導(dǎo)入Java端。在不打破Storm并行計(jì)算框架和Java應(yīng)用程序環(huán)境的情況下，通過(guò)內(nèi)存共享機(jī)制，Java端與C++本地算法實(shí)現(xiàn)端數(shù)據(jù)同步變化，相比于普通的數(shù)組傳遞，效率更高更快，減少了數(shù)據(jù)堵塞的產(chǎn)生，且適合長(zhǎng)期使用、頻繁訪問(wèn)的大塊內(nèi)存的共享。3kvm系統(tǒng)環(huán)境本實(shí)驗(yàn)在操作系統(tǒng)為centos6.6的64位華碩服務(wù)器下實(shí)現(xiàn)，硬件環(huán)境如下:CPU為2個(gè)6核Intel(R)Xeon(R)CPUE5-2620處理器，內(nèi)存為64Gbyte，通過(guò)KVM虛擬化技術(shù)搭建Storm集群，集群中設(shè)置1個(gè)Nimbus節(jié)點(diǎn)和3個(gè)Supervisor節(jié)點(diǎn)，網(wǎng)絡(luò)環(huán)境為10.0.0.1網(wǎng)段的局域網(wǎng)。軟件環(huán)境為apache-storm-0.9.2-incubating。測(cè)試視頻為編碼方式是H.264，像素為1920×1080高清視頻流數(shù)據(jù)。3.1視頻數(shù)據(jù)的能耗驗(yàn)證內(nèi)存共享機(jī)制的高效性，測(cè)試在相同環(huán)境下本文方法與基于數(shù)組傳遞的方法處理不同大小的視頻數(shù)據(jù)時(shí)耗如表1所示。從表1可以看出，兩種機(jī)制分別實(shí)現(xiàn)人車分類算法，本文方法明顯優(yōu)于基于內(nèi)存拷貝機(jī)制的方法，且隨著數(shù)據(jù)量的增大，本文方法中每幀視頻數(shù)據(jù)平均處理時(shí)間相對(duì)穩(wěn)定，能滿足JNI調(diào)用本地算法高效性需求。3.2兩種模式下視頻處理效果對(duì)比吞吐量指系統(tǒng)單位時(shí)間內(nèi)處理數(shù)據(jù)的大小，是衡量并行系統(tǒng)實(shí)時(shí)高效性的重要指標(biāo)。記錄在Storm單機(jī)模式與集群模式下，隨著數(shù)據(jù)量的增加，完成視頻處理所需時(shí)間，對(duì)比兩種模式下的結(jié)果如圖6所示。由圖6可知，當(dāng)視頻數(shù)據(jù)流比較小時(shí)，由于任務(wù)分發(fā)數(shù)據(jù)傳輸?shù)榷夹枰馁M(fèi)一定的計(jì)算機(jī)資源和時(shí)間，單機(jī)模式下數(shù)據(jù)流處理時(shí)間低于集群模式的處理時(shí)間。但是隨著數(shù)據(jù)流的增大，任務(wù)分發(fā)所需時(shí)間遠(yuǎn)小于視頻處理的時(shí)耗，集群模式處理時(shí)間明顯縮短。3.3高效節(jié)點(diǎn)高效存儲(chǔ)負(fù)載均衡是并行計(jì)算中的一項(xiàng)重要指標(biāo)，數(shù)據(jù)計(jì)算過(guò)多分布于同一計(jì)算節(jié)點(diǎn)，形成數(shù)據(jù)傾斜，會(huì)造成計(jì)算資源的浪費(fèi)，影響集群穩(wěn)定性。Storm并行框架的數(shù)據(jù)處理基于內(nèi)存進(jìn)行，在任務(wù)執(zhí)行過(guò)程中使用nmon工具統(tǒng)計(jì)各節(jié)點(diǎn)內(nèi)存使用情況如圖7所示。圖中IP為10.0.88.55的計(jì)算機(jī)為Nimbus節(jié)點(diǎn)，分配8Gbyte內(nèi)存空間，其他為工作節(jié)點(diǎn)分配4Gbyte內(nèi)存空間。Nimbus節(jié)點(diǎn)需要分配計(jì)算任務(wù)并監(jiān)控集群狀態(tài)，內(nèi)存使用率高于工作節(jié)點(diǎn)，保持穩(wěn)定。各工作節(jié)點(diǎn)在硬件資源分配相同的條件下，在任務(wù)開始階段內(nèi)存上升平穩(wěn)，隨后趨于穩(wěn)定，由此可知各工作節(jié)點(diǎn)內(nèi)存使用率大致相同，沒(méi)有出現(xiàn)某一節(jié)點(diǎn)內(nèi)存使用過(guò)高的情形，說(shuō)明在任務(wù)執(zhí)行過(guò)程中，集群內(nèi)存使用相對(duì)合理，沒(méi)有出現(xiàn)數(shù)據(jù)傾斜的情況，負(fù)載均衡。4實(shí)驗(yàn)結(jié)果分析針對(duì)海量監(jiān)控視頻流數(shù)據(jù)實(shí)時(shí)分析的需求，設(shè)計(jì)了基于多路視頻流的并行處理框架，提高了視頻流數(shù)據(jù)處理的效率