本發(fā)明屬于數(shù)字圖像處理、分布式計算技術(shù)領域，具體涉及一種分布式大規(guī)模視頻流處理系統(tǒng)。

背景技術(shù)：

智能視頻監(jiān)控技術(shù)在公共安全、交通管理、智慧城市等方面有著廣泛的運用前景，需求日益增長。隨著攝像頭安裝的數(shù)量越來越多，采集的圖像的數(shù)據(jù)量越來越大，靠單臺計算機處理已經(jīng)遠遠不能滿足需求了。并且智能視頻監(jiān)控很多情況下是要求對采集圖像進行實時處理。數(shù)量眾多的監(jiān)控攝像頭，龐大的監(jiān)控網(wǎng)絡，很短時間之內(nèi)就會產(chǎn)生海量的圖像視頻數(shù)據(jù)，如何從這些海量數(shù)據(jù)中高效地提取出有用的信息，就成為智能視頻監(jiān)控技術(shù)要解決的問題[7]。分布式計算的興起與發(fā)展為解決大規(guī)模的數(shù)據(jù)處理問題提供了很好的途徑。

很多“大數(shù)據(jù)”是實時接收得到的，這些數(shù)據(jù)往往在得到時具有最大的價值[1]。并且這些不斷產(chǎn)生的“大數(shù)據(jù)”無論是數(shù)據(jù)存儲還是數(shù)據(jù)快速處理問題都已經(jīng)不是單臺物理機器能夠解決的。因此，許多分布式流式處理平臺不斷被開發(fā)出來，如twitter公司開發(fā)的storm[2]、yahoo!公司開發(fā)的s4[3]、微軟的timestream[4]以及ucberkeleyamplab開發(fā)的sparkstreaming[5]等。這里sparkstreaming是基于d-steam[1]模型并構(gòu)建在spark計算引擎上[6]的分布式流式計算框架，其特點是結(jié)合了流式處理和批處理。由于一些視頻流處理存在幀與幀之間的依賴關(guān)系，這些框架不適合該類視頻流的處理。針對這些問題，本發(fā)明采用了兩種處理模式來解決現(xiàn)有框架在大規(guī)模視頻流處理方面的問題。

技術(shù)實現(xiàn)要素：

本發(fā)明的在于提供一種數(shù)據(jù)采集速度快、處理效率高的分布式大規(guī)模視頻流處理系統(tǒng)。

本發(fā)明提供的大規(guī)模視頻流處理系統(tǒng)，如附圖1所示，采用集群的形式，集群中，主節(jié)點負責客戶端進行交互、集群中從節(jié)點的狀況監(jiān)控以及視頻流處理任務調(diào)度，從節(jié)點的狀況信息包括硬盤狀況、cpu狀況、內(nèi)存狀況、運行的任務狀況等；從節(jié)點負責對視頻幀進行采集和處理，其中采集器是運行在從節(jié)點的一個進程，負責采集視頻流數(shù)據(jù)；視頻數(shù)據(jù)處理結(jié)果通過調(diào)用視頻/圖像處理庫的相應接口存儲到存儲系統(tǒng)中，如本地文件系統(tǒng)、分布式文件系統(tǒng)等；視頻/圖像處理庫可以動態(tài)添加，如行人檢測等。

本發(fā)明中，利用多臺機器采集視頻數(shù)據(jù)，當視頻幀前后存在依賴關(guān)系時可以在本地處理，否則，先解碼，然后按照一定的格式組織成字節(jié)數(shù)組的形式（數(shù)據(jù)包），隨機選擇一個節(jié)點（屬于從節(jié)點，為了與其他從節(jié)點區(qū)分，這里稱其為元數(shù)據(jù)管理節(jié)點，下同）記錄數(shù)據(jù)包的元數(shù)據(jù)，元數(shù)據(jù)管理節(jié)點負責分發(fā)任務到集群的其他從節(jié)點，由這些節(jié)點對數(shù)據(jù)包進行處理，處理結(jié)果返回元數(shù)據(jù)管理節(jié)點。在整個過程中對集群的資源情況進行監(jiān)控，進而調(diào)整集群的資源分配情況。

整個系統(tǒng)包括視頻數(shù)據(jù)采集模塊、視頻數(shù)據(jù)處理模塊和數(shù)據(jù)存儲模塊。視頻數(shù)據(jù)采集模塊，利用多臺機器采集視頻數(shù)據(jù)，采用poll的方式從外部獲取視頻流數(shù)據(jù)，支持rtsp、http等多種視頻流傳輸協(xié)議，并且在獲取視頻流數(shù)據(jù)的過程中支持失敗重試、斷點續(xù)傳；視頻數(shù)據(jù)處理模塊對視頻幀數(shù)據(jù)進行結(jié)構(gòu)化組織，形成數(shù)據(jù)包的形式，然后由主節(jié)點來進行任務劃分和調(diào)度，從節(jié)點從視頻庫中調(diào)用相應算法來對數(shù)據(jù)包中的數(shù)據(jù)進行處理；數(shù)據(jù)存儲模塊提供了包括本地文件系統(tǒng)、分布式文件系統(tǒng)以及數(shù)據(jù)庫的存儲接口，視頻數(shù)據(jù)處理后的結(jié)果由數(shù)據(jù)存儲模塊負責存儲。

上述大規(guī)模視頻流處理系統(tǒng)的工作具體流程如下：

步驟1、客戶端向主節(jié)點提交視頻流處理請求，請求信息包括視頻流來源（可通過網(wǎng)絡獲取該視頻流數(shù)據(jù)）、視頻流的處理方式以及存儲方式。主節(jié)點得到對請求信息進行檢查，檢查內(nèi)容包括對視頻流來源是否可以訪問等。如果檢查不通過，則主節(jié)點向從節(jié)點返回錯誤信息，否則主節(jié)點對該請求一個唯一的id，并將id返回給客戶端，客戶端通過id向主節(jié)點實時查詢?nèi)蝿盏臓顟B(tài)。

步驟2、多路視頻流數(shù)據(jù)的采集

采用多臺（n臺）機器對多視頻流數(shù)據(jù)進行采集（采集器），充分利用各個機器的網(wǎng)絡帶寬，可極大提高網(wǎng)絡吞吐量。設各臺機器的吞吐量分別為,則平臺總的吞吐量為。

步驟3、對視頻進行解碼

當視頻幀前后存在依賴關(guān)系時，可以在本地處理；否則，在視頻進行處理之前需要對視頻流進行解碼，將視頻里面的視頻幀解碼出來，并給每一幀打上標簽，標簽包括id（從0開始遞增），視頻來源（host地址等形式），視頻流唯一標識（每一路視頻對應一個唯一的標識）。以字節(jié)數(shù)組的形式進行封裝，組成數(shù)據(jù)包；數(shù)據(jù)包的組織形式如圖2所示，其中，數(shù)據(jù)塊0為數(shù)據(jù)包頭部，整形，4個字節(jié)，記錄后面一個數(shù)據(jù)的總長度；數(shù)據(jù)塊2k+1為整形，4個字節(jié)，記錄數(shù)據(jù)塊2k+2的字節(jié)長度(k=0,1,2…n)；數(shù)據(jù)塊2k+2為任意長的字節(jié)數(shù)組，是真正的數(shù)據(jù)(k=0,1,2…n)；數(shù)據(jù)塊2k+3為crc校驗，一個字節(jié)。

步驟4、將視頻幀提交到集群中處理

步驟2和步驟3產(chǎn)生的數(shù)據(jù)由所在的機器管理，而這些數(shù)據(jù)的元數(shù)據(jù)（視頻流唯一標識、數(shù)據(jù)塊唯一標識、所在的機器位置）由單獨一個進程管理（元數(shù)據(jù)管理節(jié)點），元數(shù)據(jù)管理節(jié)點根據(jù)步驟2的元數(shù)據(jù)產(chǎn)生任務，然后將這些任務分發(fā)給其他從節(jié)點；接收到任務的從節(jié)點，首先向數(shù)據(jù)所在的節(jié)點獲取要處理的數(shù)據(jù)，并對這些數(shù)據(jù)進行處理，處理后數(shù)據(jù)返回到元數(shù)據(jù)管理節(jié)點。

步驟5、元數(shù)據(jù)管理節(jié)點維護數(shù)據(jù)的順序

元數(shù)據(jù)管理節(jié)點會收到多路視頻處理后的數(shù)據(jù)，由于視頻中的幀與幀之間有先后順序，并且不同視頻流之間的幀是獨立的。這里采用哈希表和最小堆（可稱為資源池）的形式維護數(shù)據(jù)的順序性與獨立性。資源池中的數(shù)據(jù)可以進行與業(yè)務相關(guān)的應用。

步驟6、集群資源的監(jiān)控與調(diào)整，

本發(fā)明提出采用cpu時間占用率來衡量集群的資源的使用情況，并根據(jù)此來調(diào)整集群資源。

cpu時間占有率表示某一段時間內(nèi)cpu各個核數(shù)用于數(shù)據(jù)處理的時間占總時間的比率。由于每個任務都在單獨的線程中運行，統(tǒng)計任務的運行時間，就不難得出線程處理數(shù)據(jù)的時間。

設n表示為用戶所需的最大使用的cpu核數(shù)，表示第n個核t時刻（以毫秒為單位）的使用狀態(tài)，，則可表示為：

；

則從1到k時刻第n個核的時間占用率為。由于多核cpu中無法確定線程使用的是哪個核，因此第n個核的時間占用率比較難得到，但這里可以得到從1到k時刻n個核總的時間占用率，表示為：

越大，也就是處理數(shù)據(jù)的時間占任務的總時間（包括處理數(shù)據(jù)的時間、任務調(diào)度時間，網(wǎng)絡傳輸時間等）的比重也大，說明平臺越高效。當過大時需要增加集群資源，可以通過加機器的形式實現(xiàn)。

步驟7、視頻數(shù)據(jù)存儲

數(shù)據(jù)處理的過程得到的結(jié)果可以通過元數(shù)據(jù)管理節(jié)點直接存儲到本地文件系統(tǒng)、分布式文件系統(tǒng)或者數(shù)據(jù)庫中。數(shù)據(jù)的存儲格式以及存儲方式可以由客戶端來指定，如結(jié)構(gòu)化的數(shù)據(jù)可以存到數(shù)據(jù)庫中，數(shù)據(jù)量比較大的情況可以存到分布式文件系統(tǒng)中。

與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點和效果有：

1、數(shù)據(jù)采集速度快。對于視頻的采集，采用多臺機器同時采集，極大提高了數(shù)據(jù)采集的速度；

2、資源整合利用。集群中的cpu資源、內(nèi)存資源等作為一個資源池的形式進行分配，可以充分利用到集群的資源；

3、中間數(shù)據(jù)優(yōu)先保存在內(nèi)存。為了提高速度，中間數(shù)據(jù)優(yōu)先保存在內(nèi)存中而不是磁盤中，當內(nèi)存不足時才保存在磁盤中。由于對內(nèi)存數(shù)據(jù)的讀取速度遠遠大于對磁盤數(shù)據(jù)的讀取速度，因此可以大大提高系統(tǒng)效率；

4、引入cpu時間占用率。本發(fā)明提出cpu時間占用率來衡量集群的利用率，更加直觀和科學。

附圖說明

圖1為分布式大規(guī)模視頻流處理平臺架構(gòu)圖示。

圖2為視頻幀封裝數(shù)據(jù)包結(jié)構(gòu)圖。

圖3為分布式大規(guī)模視頻流處理平臺部署示意圖。

圖4為測試視頻流信息的檢測效果圖示。

圖5為本發(fā)明（分布式處理）取得的處理速度與單臺同樣機器（單機處理）處理速度的對比圖示。

具體實施方式

下面結(jié)合附圖對本發(fā)明所述技術(shù)方案進一步說明。此處所描述的具體實施例僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

圖3是分布式大規(guī)模視頻流處理平臺部署示意圖，主節(jié)點和從節(jié)點之間的信息交互通過交換機完成，客戶端通過以太網(wǎng)與集群進行信息機交互，集群通過以太網(wǎng)獲取視頻流數(shù)據(jù)。本發(fā)明主節(jié)點數(shù)量為1臺，機器配置如下：

從節(jié)點數(shù)量為3臺，機器配置如下：

。

具體流程如下：

1、啟動集群，從節(jié)點向主節(jié)點發(fā)送節(jié)點的cpu、內(nèi)存和硬盤信息，完成從節(jié)點向主節(jié)點的注冊過程，此后從節(jié)點以心跳包的形式定時向主節(jié)點更新從節(jié)點的狀態(tài)信息；

2、客戶端向主節(jié)點提交視頻流處理請求，請求信息包括視頻源的網(wǎng)絡地址，處理的方式，如行人檢測、車牌識別等。本發(fā)明采用的測試視頻流信息如下表所示，采用的處理方式為hog特[8]的行人檢測，檢測效果如圖4所示；

；

3、主節(jié)點通過網(wǎng)絡來檢查視頻源的網(wǎng)絡地址是否正確，通過檢查后為該請求生成唯一id返回給客戶端，同時將任務交由元數(shù)據(jù)管理節(jié)點運行；

4、元數(shù)據(jù)管理節(jié)點啟動采集器來采集視頻流數(shù)據(jù)，具體數(shù)據(jù)保存在采集器所在的機器，采集器將元數(shù)據(jù)交由元數(shù)據(jù)管理節(jié)點管理，元數(shù)據(jù)管理節(jié)點根據(jù)元數(shù)據(jù)以及客戶端請求的處理方式生成具體的計算任務；

5、從節(jié)點不斷從元數(shù)據(jù)管理節(jié)點獲取要處理的任務，并根據(jù)元數(shù)據(jù)信息獲取實際的視頻幀數(shù)據(jù)來進行處理；

6、處理結(jié)果返回元數(shù)據(jù)管理節(jié)點，由元數(shù)據(jù)管理節(jié)點輸出；此外元數(shù)據(jù)管理節(jié)點不斷向主節(jié)點匯報任務的運行狀態(tài)；

7、客戶端可以通過id來向主節(jié)點查詢?nèi)蝿者\行的狀態(tài)；

8、在本發(fā)明的實際部署條件下和在相同處理方式的情況下，本發(fā)明（分布式處理）取得的處理速度是單臺同樣機器（單機處理）處理速度的35倍左右，如圖5所示。

參考文獻：

[1]mateiz,tathagatad,haoyuanl,etal.discretizedstreams:fault-tolerantstreamingcomputationatscala[c]//procofthetwenty-fourthacmsymposiumonoperatingsystemsprinciples,farmington,pennsylvania,usa:acm,2013.

[2]apachesoftwarefoundation.storm,distributedandfault-tolerantrealtimecomputation[eb/ol].[2015-06-25].http://storm.apache.org/.

[3]neumeyerl,robbinsb,naira,kesaria.s4:distributedstreamcomputingplatform[c]//procofthe10thieeeint’lconfondataminingworkshops(icdmw2010).sydney:ieeepress,2010.

[4]z.qian,y.he,c.su,etal.timestream:reliablestreamcomputationinthecloud[c]//procofthe8thacmeuropeanconfoncomputersystems.newyork,ny,usa:acm,2013.

[5]apachesoftwarefoundation.apachespark,lightning-fastclustercomputing[eb/ol].[2015-06-28].http://spark.apache.org/.

[6]m.zaharia,m.chowdhury,t.das,etal.resilientdistributeddatasets:afaulttolerantabstractionforin-memoryclustercomputing[c]//proceedingsofthe9thusenixconferenceonnetworkedsystemsdesignandimplementation.ca,usa:usenixassociation,2012.

[7]黃凱奇，陳曉棠，康運鋒，等.智能視頻監(jiān)控技術(shù)綜述[j].計算機學報,2015,38(6):1094-1094.

[8]navneetdalal,billtriggs.histogramsoforientedgradientsforhumandetection[c]//procofthe2005ieeecomputersocietyconfoncomputervisionandpatternrecognition.sandiego,ca,usa:ieee,2005。