蔣春燕,，王佳斌,，鄭力新

　　（華僑大學(xué) 工學(xué)院,，福建 泉州 362000）

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

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

0引言

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

1研究現(xiàn)狀

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

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

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

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

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

　　Hadoop在與用戶寫的Mapper和Reducer通信時(shí)，總是使用類型化的數(shù)據(jù)從文件讀入到Mapper中,，Mapper向Reducer提交的文件和Reducer輸出的文件均以Java對(duì)象存儲(chǔ),。而可以與文件和網(wǎng)絡(luò)相互通信的對(duì)象必須遵循特定的接口,，叫做Writable［8］，它允許Hadoop以一種序列化的形式讀寫數(shù)據(jù)以適用于傳輸,。Hadoop的io包中提供了幾個(gè)基本的Writable類型,，如BooleanWritable(標(biāo)準(zhǔn)布爾型數(shù)值)、ByteWritable（單字節(jié)數(shù)值）,、DoubleWritable（雙字節(jié)數(shù)值）,、FloatWritable(浮點(diǎn)數(shù))、IntWritable(整型數(shù)),、LongWritable(長(zhǎng)整型數(shù)),、Text(使用UTF8格式存儲(chǔ)的文本)、NullWritable（當(dāng)〈key,value〉中的key或value為空時(shí)使用）等,，Hadoop自帶的數(shù)據(jù)類型如圖1所示,。圖1Hadoop自帶的數(shù)據(jù)類型這些都是基本數(shù)據(jù)類型，復(fù)雜數(shù)據(jù)類型如xml文本,、圖片,、視頻等都需要用戶自定義數(shù)據(jù)類型。自定義數(shù)據(jù)類型就得繼承接口Writable,實(shí)現(xiàn)其方法write()和readFields(), 以便該數(shù)據(jù)能被序列化后完成網(wǎng)絡(luò)傳輸或文件輸入/輸出,。如果該數(shù)據(jù)需要作為主鍵key使用,，或需要比較數(shù)值大小，則需要實(shí)現(xiàn)WritalbeComparable接口,實(shí)現(xiàn)其方法write(),、readFields()等,，在MapReduce中使用時(shí)，設(shè)置相應(yīng)的Map或Reduce的class類型即可,。

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

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

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

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

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

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

　　由圖3可知,，若一個(gè)視頻大于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均無(wú)法得到完整的幀序列。直接使用Hadoop分割監(jiān)控視頻只適用于本地監(jiān)控視頻數(shù)據(jù)大小與HDFS默認(rèn)的數(shù)據(jù)塊大小相等的視頻數(shù)據(jù),，否則將出現(xiàn)以上問(wèn)題,。

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

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

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

4實(shí)驗(yàn)分析

　　4.1實(shí)驗(yàn)集群概述

　　硬件環(huán)境：Hadoop集群由3臺(tái)PC組成，每臺(tái)PC的CPU為Intel(R) Pentium(R) 4 CPU 2.80 GHz,，內(nèi)存為2 GB,，硬盤為455 GB。其中1臺(tái)作為集群Master,，2臺(tái)作為集群Slave,。運(yùn)行環(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平臺(tái)包括一個(gè)master節(jié)點(diǎn)，即namenode節(jié)點(diǎn),，主要負(fù)責(zé)任務(wù)分配和調(diào)度,；兩個(gè)slave節(jié)點(diǎn)，即datanode節(jié)點(diǎn),，負(fù)責(zé)數(shù)據(jù)存儲(chǔ)和計(jì)算,。

　　4.2視頻解碼方法

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

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

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

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

　　4.3實(shí)驗(yàn)結(jié)果分析

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

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

5結(jié)論

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

參考文獻(xiàn)

　　［1］ 李福堂,，盧強(qiáng),，劉繼華.同洲電子SDV解決方案［C］. 2010國(guó)際傳輸與覆蓋研討會(huì)論文集，2010：327338.

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

　　［3］ 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ù)處理平臺(tái)比較與分析［J］. 微型機(jī)與應(yīng)用,2015,34(11):79,17.

　?。?］ 高東海，李文生,，張海濤.基于Hadoop的離線視頻處理技術(shù)研究與實(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.

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