蔣春燕，王佳斌，鄭力新

　?。ㄈA僑大學 工學院，福建 泉州 362000）

　　摘要：隨著社交網(wǎng)站崛起、通信和多媒體技術(shù)的高速發(fā)展，視頻、圖像日益增長并己成為人們傳遞和獲取信息的重要方式，目前H.264和JPEG2000己成為視頻和靜止圖像領(lǐng)域應(yīng)用較為廣泛的壓縮標準。如何高效挖掘海量視頻的價值已經(jī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引言

　　*基金項目：泉州市重點科研項目（2013Z12）當今社會隨著移動終端設(shè)備和多媒體技術(shù)高速發(fā)展，F(xiàn)acebook、YouTube等大型社交網(wǎng)站迅速崛起，人類對信息的要求也越來越豐富，特別是直觀性很強的圖像和視頻信息，人們可以從中獲取更多的細節(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ò)相互通信的對象必須遵循特定的接口，叫做Writable［8］，它允許Hadoop以一種序列化的形式讀寫數(shù)據(jù)以適用于傳輸。Hadoop的io包中提供了幾個基本的Writable類型，如BooleanWritable(標準布爾型數(shù)值)、ByteWritable（單字節(jié)數(shù)值）、DoubleWritable（雙字節(jié)數(shù)值）、FloatWritable(浮點數(shù))、IntWritable(整型數(shù))、LongWritable(長整型數(shù))、Text(使用UTF8格式存儲的文本)、NullWritable（當〈key,value〉中的key或value為空時使用）等，Hadoop自帶的數(shù)據(jù)類型如圖1所示。圖1Hadoop自帶的數(shù)據(jù)類型這些都是基本數(shù)據(jù)類型，復(fù)雜數(shù)據(jù)類型如xml文本、圖片、視頻等都需要用戶自定義數(shù)據(jù)類型。自定義數(shù)據(jù)類型就得繼承接口Writable,實現(xiàn)其方法write()和readFields(), 以便該數(shù)據(jù)能被序列化后完成網(wǎng)絡(luò)傳輸或文件輸入/輸出。如果該數(shù)據(jù)需要作為主鍵key使用，或需要比較數(shù)值大小，則需要實現(xiàn)WritalbeComparable接口,實現(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支持非常多的視頻編碼格式，基于它的視頻讀寫接口VRWI也同樣支持很多格式。它將視頻文件轉(zhuǎn)化為鍵值對，這些鍵值對被逐一地傳給map函數(shù)。HVPI接口結(jié)構(gòu)圖如圖2所示。

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

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

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

　　視頻文件上傳到HDFS之后，根據(jù)用戶設(shè)定的Block大小，分布式地存儲于集群中的數(shù)據(jù)節(jié)點之上，此時，所有按默認順序分配到各數(shù)據(jù)塊上的文件若大于64 MB，將都被物理分割。數(shù)據(jù)節(jié)點通過維護文件系統(tǒng)的元數(shù)據(jù)對文件進行管理，而HDFS面向用戶的接口又是一個完整連續(xù)的文件，HDFS對用戶隱藏了分割的細節(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默認的數(shù)據(jù)塊大小，若嚴格按默認數(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默認的數(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ū)中計算每段視頻的大小，當該視頻大小上傳到HDFS上后的數(shù)據(jù)塊累加大小接近默認數(shù)據(jù)塊大小時，才允許上傳，否則計算下一段本地視頻大小，依次類推。這樣在HDFS上的數(shù)據(jù)塊大小都接近默認數(shù)據(jù)塊大小，在Map階段進行處理時的邏輯分割中保證每個數(shù)據(jù)塊都不再分割，一個Map任務(wù)處理一個數(shù)據(jù)塊，這樣在分布式處理時的數(shù)據(jù)負載均衡也會得到保證，本文設(shè)計的HVPI數(shù)據(jù)分割示意圖如圖4所示。

　　若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é)點，主要負責任務(wù)分配和調(diào)度；兩個slave節(jié)點，即datanode節(jié)點，負責數(shù)據(jù)存儲和計算。

　　4.2視頻解碼方法

　　本實驗數(shù)據(jù)使用的是某監(jiān)控視頻中的一個攝像頭的監(jiān)控視頻數(shù)據(jù)，該監(jiān)控視頻格式是SDV格式，該監(jiān)控視頻的特點是只有前景變化時才會開啟錄制模式，當前景消失在目標檢測區(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上，進行分布式并行視頻解碼處理。

　　相比早期版本，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)境不好，可能會造成重新傳輸。

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

　　4.3實驗結(jié)果分析

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

　　然而用云平臺下分布式系統(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］.武漢：華中科技大學，2011.

　?。?］ PEGASUS Interactive Services Architecture 1.4［S］.USA: Time Warner 2003.

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

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

　?。?］ 何海林,皮建勇. 大數(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］.北京：北京郵電大學，2015.