蔣春燕，王佳斌，鄭力新（華僑大學(xué)工學(xué)院，福建泉州362000）

?

基于云環(huán)境的網(wǎng)絡(luò)監(jiān)控視頻解碼的研究與應(yīng)用*

蔣春燕，王佳斌，鄭力新
（華僑大學(xué)工學(xué)院，福建泉州362000）

摘 要：隨著社交網(wǎng)站崛起、通信和多媒體技術(shù)的高速發(fā)展，視頻、圖像日益增長并己成為人們傳遞和獲取信息的重要方式，目前H.264和JPEG2000己成為視頻和靜止圖像領(lǐng)域應(yīng)用較為廣泛的壓縮標(biāo)準(zhǔn)。如何高效挖掘海量視頻的價值已經(jīng)成為當(dāng)前研究的熱點問題，然而視頻解碼是發(fā)掘海量視頻知識的前提。重點研究在分布式平臺下對SDV格式的網(wǎng)絡(luò)監(jiān)控視頻進行解碼，利用Xuggler視覺庫設(shè)計了能在云環(huán)境下Hadoop平臺上使用的視頻數(shù)據(jù)類型，解決了Hadoop平臺上直接分割視頻遇到的幀不完整、缺關(guān)鍵幀和少頭數(shù)據(jù)信息的問題，并比較了傳統(tǒng)單機解碼與分布式解碼的優(yōu)缺點。

關(guān)鍵詞：云環(huán)境；分布式；視頻解碼

0　引言

當(dāng)今社會隨著移動終端設(shè)備和多媒體技術(shù)高速發(fā)展，F(xiàn)acebook、YouTube等大型社交網(wǎng)站迅速崛起，人類對信息的要求也越來越豐富，特別是直觀性很強的圖像和視頻信息，人們可以從中獲取更多的細(xì)節(jié)信息。然而，視頻和數(shù)字化圖像信息內(nèi)容復(fù)雜，存在著一些明顯的缺點，如信息量大，不適合應(yīng)用于實時性要求高的場合，這給信息的存儲和網(wǎng)絡(luò)傳輸帶來很大困難，進而成為制約人們獲取和挖掘視頻信息的主要瓶頸。而一種新型的網(wǎng)絡(luò)視頻點播格式——交換式視頻廣播［1］（Switch Digital Video，SDV）格式的視頻系統(tǒng)通過虛擬資源列表能有效解決這一瓶頸。本文將針對該格式的視頻進行云環(huán)境下的分布式解碼［2］研究。

1　研究現(xiàn)狀

目前廣播數(shù)字電視網(wǎng)中實現(xiàn)SDV系統(tǒng)主要基于兩種技術(shù)架構(gòu)：一種是1997年由美國Time Wanner Cable公司提出的基于開放協(xié)議的ISA［3］（交互服務(wù)架構(gòu)）；另一種是2007年由美國Comcast公司提出的基于私有協(xié)議框架的NGOD［4］（下一代視頻點播服務(wù)架構(gòu)）。

SDV［5］系統(tǒng)是廣電網(wǎng)運營商提供的一種新型點播業(yè)務(wù)，意在允許用戶通過點播廣播數(shù)據(jù)的方式獲取更多的廣播電視資源，其實現(xiàn)方案依靠在網(wǎng)絡(luò)中新增SDV服務(wù)器和SDV客戶端，并通過它們的通信交互，完成HFC段帶寬的交換式使用，實現(xiàn)資源列表提前下發(fā)。越來越多的網(wǎng)絡(luò)監(jiān)控視頻也開始使用SDV的視頻格式將監(jiān)控視頻保存在云端，用以形成監(jiān)控視頻云。

單機己經(jīng)沒有能力處理監(jiān)控視頻云端的大量視頻數(shù)據(jù)，云環(huán)境下分布式平臺能解決這一難題，因此需要借助云計算技術(shù)及分布式技術(shù)來分析問題并解決問題。但是現(xiàn)有的分布式計算平臺如Hadoop［6］一般是處理文本數(shù)據(jù)，只提供處理文本數(shù)據(jù)的接口。而視頻文件一般是壓縮文件，且視頻編碼技術(shù)十分復(fù)雜，視頻文件編碼格式多種多樣，如果要使用Hadoop云平臺進行視頻處理［7］，還有許多工作要做，而基于內(nèi)容的視頻分析中視頻解碼是視頻中內(nèi)容分析的前提。

2　設(shè)計數(shù)據(jù)接口

2.1Hadoop數(shù)據(jù)類型的分析

Hadoop在與用戶寫的Mapper和Reducer通信時，總是使用類型化的數(shù)據(jù)從文件讀入到Mapper中，Mapper向Reducer提交的文件和Reducer輸出的文件均以Java對象存儲。而可以與文件和網(wǎng)絡(luò)相互通信的對象必須遵循特定的接口，叫做W ritable［8］，它允許Hadoop以一種序列化的形式讀寫數(shù)據(jù)以適用于傳輸。Hadoop的io包中提供了幾個基本的W ritable類型，如BooleanW ritable（標(biāo)準(zhǔn)布爾型數(shù)值）、ByteW ritable（單字節(jié)數(shù)值）、DoubleW ritable（雙字節(jié)數(shù)值）、FloatW ritable（浮點數(shù)）、IntW ritable（整型數(shù)）、Long-W ritable（長整型數(shù)）、Text（使用UTF8格式存儲的文本）、NullW ritable（當(dāng)〈key，value〉中的key或value為空時使用）等，Hadoop自帶的數(shù)據(jù)類型如圖1所示。

圖1　Hadoop自帶的數(shù)據(jù)類型

這些都是基本數(shù)據(jù)類型，復(fù)雜數(shù)據(jù)類型如xm l文本、圖片、視頻等都需要用戶自定義數(shù)據(jù)類型。自定義數(shù)據(jù)類型就得繼承接口W ritable，實現(xiàn)其方法write（）和read-Fields（），以便該數(shù)據(jù)能被序列化后完成網(wǎng)絡(luò)傳輸或文件輸入/輸出。如果該數(shù)據(jù)需要作為主鍵key使用，或需要比較數(shù)值大小，則需要實現(xiàn)W ritalbeComparable接口，實現(xiàn)其方法write（）、readFields（）等，在MapReduce中使用時，設(shè)置相應(yīng)的Map或Reduce的class類型即可。

2.2hadoop平臺上視頻數(shù)據(jù)類型的設(shè)計

Hadoop的分布式文件系統(tǒng)HDFS設(shè)計之初是為了處理文本大數(shù)據(jù)，但只要被寫入的數(shù)據(jù)很少被改動，并且對數(shù)據(jù)的操作主要是大規(guī)模的流式讀取和小規(guī)模的隨機讀取，原則上HDFS就可以存儲任何類型的數(shù)據(jù)，因此，視頻數(shù)據(jù)可以上傳到HDFS之上。但要分析HDFS上視頻幀數(shù)據(jù)，就得設(shè)計視頻數(shù)據(jù)接口。本文設(shè)計了視頻數(shù)據(jù)接口HVPI。本研究的對象是SDV格式的網(wǎng)絡(luò)監(jiān)控視頻，該視頻是由小視頻組合的，通過不分割視頻，即讓整個數(shù)據(jù)塊作為輸入分片被傳給視頻錄入接口，它使用開源視頻編解碼庫Xuggler來解析視頻中的幀。Xuggler支持非常多的視頻編碼格式，基于它的視頻讀寫接口VRW I也同樣支持很多格式。它將視頻文件轉(zhuǎn)化為鍵值對，這些鍵值對被逐一地傳給map函數(shù)。HVPI接口結(jié)構(gòu)圖如圖2所示。

圖2　hadoop視頻處理接口HVPI接口結(jié)構(gòu)圖

視頻讀寫接口VRW I位于分布式計算框架MapReduce和分布式文件系統(tǒng)HDFS之間，將視頻文件轉(zhuǎn)化為MapReduce計算框架Map階段可以讀取鍵值對的形式。MapReduce依賴于Input-Format抽象讀取輸入數(shù)據(jù)，將其轉(zhuǎn)化為傳送給Map函數(shù)的鍵值對。這一輸入分片抽象類主要包含兩個抽象方法，得到分片方法和視頻錄入接口方法。如圖2所示，視頻讀寫接口首先將視頻文件抽象為InputSplits（輸入文件的邏輯分片），一個輸入分片交由一個Mapper處理。然后視頻接口解析每個輸入分片生成鍵值對＜視頻文件路徑-幀號，幀圖像＞，并傳遞每個鍵值對到Map函數(shù)，為后期對監(jiān)控視頻內(nèi)容進行分布式處理打下基礎(chǔ)。

3　Hadoop平臺處理視頻數(shù)據(jù)

3.1在Hadoop上直接處理視頻數(shù)據(jù)的局限性

視頻文件上傳到HDFS之后，根據(jù)用戶設(shè)定的Block大小，分布式地存儲于集群中的數(shù)據(jù)節(jié)點之上，此時，所有按默認(rèn)順序分配到各數(shù)據(jù)塊上的文件若大于64 MB，將都被物理分割。數(shù)據(jù)節(jié)點通過維護文件系統(tǒng)的元數(shù)據(jù)對文件進行管理，而HDFS面向用戶的接口又是一個完整連續(xù)的文件，HDFS對用戶隱藏了分割的細(xì)節(jié)，視頻文件是經(jīng)過編碼和壓縮后的幀序列，解碼生產(chǎn)幀序列時需要視頻的頭數(shù)據(jù)和關(guān)鍵幀。若頭數(shù)據(jù)和關(guān)鍵幀不在同一個數(shù)據(jù)塊，則分割后的視頻數(shù)據(jù)塊將會缺少關(guān)鍵幀或頭數(shù)據(jù)。因為幀序列大小不一，分割后很可能還會出現(xiàn)幀不完整，如圖3所示。

圖3　按Hadoop默認(rèn)數(shù)據(jù)塊大小分割視頻數(shù)據(jù)示意圖

由圖3可知，若一個視頻大于Hadoop默認(rèn)的數(shù)據(jù)塊大小，若嚴(yán)格按默認(rèn)數(shù)據(jù)塊大小分割，則數(shù)據(jù)塊可能出現(xiàn)幀不完整，如數(shù)據(jù)塊Block1、Block2、Block3；也可能缺少關(guān)鍵幀，如數(shù)據(jù)塊Block2；或缺少頭數(shù)據(jù)，如數(shù)據(jù)塊Block2、Block3、Block4。故數(shù)據(jù)塊Block1、Block2、Block3、Block4均無法得到完整的幀序列。直接使用Hadoop分割監(jiān)控視頻只適用于本地監(jiān)控視頻數(shù)據(jù)大小與HDFS默認(rèn)的數(shù)據(jù)塊大小相等的視頻數(shù)據(jù)，否則將出現(xiàn)以上問題。

3.2在Hadoop上直接處理視頻數(shù)據(jù)的方法

現(xiàn)有的SDV格式的監(jiān)控視頻數(shù)據(jù)的特征是，監(jiān)控視頻都是前景變化才錄制，并將監(jiān)控視頻數(shù)據(jù)存儲在云端，且每段監(jiān)控視頻的大小從8 MB到32 MB不一。若每個本地視頻在上傳到HDFS上之前選經(jīng)過預(yù)處理：在上傳緩沖區(qū)中計算每段視頻的大小，當(dāng)該視頻大小上傳到HDFS上后的數(shù)據(jù)塊累加大小接近默認(rèn)數(shù)據(jù)塊大小時，才允許上傳，否則計算下一段本地視頻大小，依次類推。這樣在HDFS上的數(shù)據(jù)塊大小都接近默認(rèn)數(shù)據(jù)塊大小，在Map階段進行處理時的邏輯分割中保證每個數(shù)據(jù)塊都不再分割，一個Map任務(wù)處理一個數(shù)據(jù)塊，這樣在分布式處理時的數(shù)據(jù)負(fù)載均衡也會得到保證，本文設(shè)計的HVPI數(shù)據(jù)分割示意圖如圖4所示。

圖4　HVPI數(shù)據(jù)分割示意圖

若HVPI接口中的split（）［9］函數(shù)返回值為錯誤，即不分割數(shù)據(jù)塊上的數(shù)據(jù)，則讓整個數(shù)據(jù)塊作為輸入分片傳給視頻錄入接口，實現(xiàn)每個Map任務(wù)處理一個數(shù)據(jù)塊。這樣本地SDV格式的監(jiān)控視頻上傳到HDFS上的數(shù)據(jù)塊后，在MapReduce計算框架中解碼時，將會避免直接使用Hadoop分割視頻時出現(xiàn)的問題。

4　實驗分析

4.1實驗集群概述

硬件環(huán)境：Hadoop集群由3臺PC組成，每臺PC的CPU為Intel（R）Pentium（R）4 CPU 2.80 GHz，內(nèi)存為2 GB，硬盤為455 GB。其中1臺作為集群Master，2臺作為集群Slave。運行環(huán)境：操作系統(tǒng)Ubuntu 14.04.1，Hadoop 2.6.0，JDK 1.7.0-79，Eclipse 4.5（64位），Xuggler 5.4。配置：本Hadoop平臺包括一個master節(jié)點，即namenode節(jié)點，主要負(fù)責(zé)任務(wù)分配和調(diào)度；兩個slave節(jié)點，即datanode節(jié)點，負(fù)責(zé)數(shù)據(jù)存儲和計算。

4.2視頻解碼方法

本實驗數(shù)據(jù)使用的是某監(jiān)控視頻中的一個攝像頭的監(jiān)控視頻數(shù)據(jù)，該監(jiān)控視頻格式是SDV格式，該監(jiān)控視頻的特點是只有前景變化時才會開啟錄制模式，當(dāng)前景消失在目標(biāo)檢測區(qū)域時，停止錄制并將錄制視頻數(shù)據(jù)保存到該設(shè)備對應(yīng)的云環(huán)境中。

本實驗選取了某天的監(jiān)控視頻上傳到本實驗環(huán)境所在的本地系統(tǒng)中，并進行解碼實驗，單機處理視頻解碼的流程圖如圖5所示，本地監(jiān)控視頻通過OpencV接口的IplImage圖像處理函數(shù)庫，逐個進行視頻解碼。在Hadoop上處理分布式視頻解碼的流程圖如圖6所示，本地視頻通過HVPI接口、視頻大小統(tǒng)計等算法上傳至HDFS上，進行分布式并行視頻解碼處理。

圖5　單機處理視頻解碼流程圖

相比早期版本，Hadoop-2.X版本的中HDFS文件塊大小增加了一倍，數(shù)據(jù)塊增大的原因有減輕了命名節(jié)點的壓力，因為Hadoop集群在啟動的時候，數(shù)據(jù)節(jié)點會上報自己的Block信息給命名節(jié)點，命名節(jié)點把這些信息放到內(nèi)存中。如果塊變大了，命名節(jié)點記錄的信息相對減少，所以命名節(jié)點就有更多的內(nèi)存去做別的事情，使得整個集群的性能增強。因為這個可以靈活設(shè)置，所以這里不是問題。關(guān)鍵是什么時候，該如何設(shè)置。如果數(shù)據(jù)量級別為PB的話，建議把Block設(shè)置得大一些。如果數(shù)據(jù)量相對較少，可以設(shè)置得小一些，如64 MB也可以。如果網(wǎng)絡(luò)環(huán)境不好，可能會造成重新傳輸。

圖6　分布式處理視頻解碼流程圖

使用Hadoop-2.X中HDFS文件塊默認(rèn)的大小128 MB，在上傳本地視頻之前先計算待上傳視頻的大小，并累計大小，若超過128 MB，則再判斷下一個視頻數(shù)據(jù)的大小，保證HDFS上每個視頻數(shù)據(jù)塊的大小接近128 MB，從而保證每個數(shù)據(jù)塊對應(yīng)一個Map任務(wù)，流程圖如圖7所示，解碼無需分割視頻塊，同時也保證了整個Hadoop分布式任務(wù)的負(fù)載均衡性。

圖7　視頻解碼流程圖

4.3 實驗結(jié)果分析

如圖8所示，使用單機處理進行解碼，數(shù)據(jù)存儲和解碼都在本地進行，目前流行的視頻播放軟件均采用這種模式。該方式的優(yōu)點是架構(gòu)簡單，不需提供額外的視頻管理機制，即用即解；缺點是解碼效率受節(jié)點配置影響，拓展性較差，數(shù)據(jù)安全性也較差，對大數(shù)據(jù)的處理能力有限。

圖8　解碼效率柱狀圖

然而用云平臺下分布式系統(tǒng)進行解碼，監(jiān)控視頻無需分割，在上傳緩沖區(qū)計算各分塊的大小，然后上傳到分布式文件系統(tǒng)上。該方式的優(yōu)點是利用了分布式計算框架，通過并行處理提高了解碼效率，充分利用分布式文件系統(tǒng)存儲的優(yōu)點；不足在于監(jiān)控視頻數(shù)據(jù)定時讀取而不能實時上傳到分布式文件系統(tǒng)中，難以實現(xiàn)在線實時處理。

5　結(jié)論

本文主要針對SDV格式監(jiān)控視頻特點，提出了一種處理監(jiān)控視頻解碼的分布式方法，并進行了實驗。實驗證明了云環(huán)境下分布式解碼效率比單機處理的優(yōu)勢，然而解碼的正確率和更大集群的分布式在線測試有待更深入的研究。

參考文獻

［1］李福堂，盧強，劉繼華.同洲電子SDV解決方案［C］.2010國際傳輸與覆蓋研討會論文集，2010：327-338.

［2］郭奕希.基于Hadoop的視頻轉(zhuǎn)碼系統(tǒng)設(shè)計與實現(xiàn)［D］.武漢：華中科技大學(xué)，2011.

［3］PEGASUS Interactive Services Architecture 1.4［S］.USA：Time Warner 2003.

［4］Comcast Corp.NGOD Overall Architecture.Version 2.0［Z］. 2006.

［5］顏文清.交換式數(shù)字電視（SDV）的應(yīng)用與推廣［J］.有線電視技術(shù)，2012（1）：60-64.

［6］何海林，皮建勇.大數(shù)據(jù)處理平臺比較與分析［J］.微型機與應(yīng)用，2015，34（11）：7-9，17.

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

［8］WHITH T.Hadoop：the definitive guide：the definitive 2009 ［C］.O′Reilly Media Inc，2009：105-151.

［9］趙曉萌.云環(huán)境下監(jiān)控視頻結(jié)構(gòu)化分析研究與實現(xiàn)［D］.北京：北京郵電大學(xué)，2015.

蔣春燕（1989 -），女，碩士研究生，主要研究方向：云計算。

王佳斌（1975 -），通信作者，男，博士研究生，副教授，主要研究方向：物聯(lián)網(wǎng)、大數(shù)據(jù)方向。E-mail：fatwang@hqu.edu.cn。

鄭力新（1967 -），男，博士，研究生導(dǎo)師，主要研究方向：人工智能、機器視覺。

引用格式：蔣春燕，王佳斌，鄭力新.基于云環(huán)境的網(wǎng)絡(luò)監(jiān)控視頻解碼的研究與應(yīng)用［J］.微型機與應(yīng)用，2016，35（10）：36-39.

Research and application of video decoding based on Cloud environment

Jiang Chunyan，Wang Jiabin，Zheng Lixin
（College of Engineering，Huaqiao University，Quanzhou 362000，China）

Abstrac t：A long with the rise of social networking，the rapid development of communications and modern multimedia technology，video and images are growing and have become importantways，in which people obtain and transfer information.The H.264 and JPEG2000 have become compression standards which has been widely applied in video and still images.How to use the value of large amounts of video effectively has become a hot problem in the current study.However，video decoding is discovering know ledge ofmassive video data.This papermainly researches on the distributed platform for SDV format video decoding network monitoring，use Xuggler visual library to design a video data type which can be used on Hadoop platform in Cloud environment，and solves the problems that on Hadoop platforms directly segmenting video results in the frame incomplete and there's a lack of key frames and header data information.The advantages and disadvantages of the traditional stand -alone decoding and distributed decoding are compared.

Key w ords：Cloud environment；distributed；video decoding

作者簡介：

收稿日期：（2016-01-18）

*基金項目：泉州市重點科研項目（2013Z12）

中圖分類號：TP37

文獻標(biāo)識碼：A

DOI：10.19358 /j.issn.1674-7720.2016.09.013