蔣春燕，王佳斌，鄭力新

　　（華僑大學(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ù)類(lèi)型，解決了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)站迅速崛起，人類(lèi)對(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ù)類(lèi)型的分析

　　Hadoop在與用戶寫(xiě)的Mapper和Reducer通信時(shí)，總是使用類(lèi)型化的數(shù)據(jù)從文件讀入到Mapper中，Mapper向Reducer提交的文件和Reducer輸出的文件均以Java對(duì)象存儲(chǔ)。而可以與文件和網(wǎng)絡(luò)相互通信的對(duì)象必須遵循特定的接口，叫做Writable［8］，它允許Hadoop以一種序列化的形式讀寫(xiě)數(shù)據(jù)以適用于傳輸。Hadoop的io包中提供了幾個(gè)基本的Writable類(lèi)型，如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ù)類(lèi)型如圖1所示。圖1Hadoop自帶的數(shù)據(jù)類(lèi)型這些都是基本數(shù)據(jù)類(lèi)型，復(fù)雜數(shù)據(jù)類(lèi)型如xml文本、圖片、視頻等都需要用戶自定義數(shù)據(jù)類(lèi)型。自定義數(shù)據(jù)類(lèi)型就得繼承接口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類(lèi)型即可。

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

　　Hadoop的分布式文件系統(tǒng)HDFS設(shè)計(jì)之初是為了處理文本大數(shù)據(jù)，但只要被寫(xiě)入的數(shù)據(jù)很少被改動(dòng)，并且對(duì)數(shù)據(jù)的操作主要是大規(guī)模的流式讀取和小規(guī)模的隨機(jī)讀取，原則上HDFS就可以存儲(chǔ)任何類(lèi)型的數(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支持非常多的視頻編碼格式，基于它的視頻讀寫(xiě)接口VRWI也同樣支持很多格式。它將視頻文件轉(zhuǎn)化為鍵值對(duì)，這些鍵值對(duì)被逐一地傳給map函數(shù)。HVPI接口結(jié)構(gòu)圖如圖2所示。

　　視頻讀寫(xiě)接口VRWI位于分布式計(jì)算框架MapReduce和分布式文件系統(tǒng)HDFS之間，將視頻文件轉(zhuǎn)化為MapReduce計(jì)算框架Map階段可以讀取鍵值對(duì)的形式。MapReduce依賴(lài)于InputFormat抽象讀取輸入數(shù)據(jù)，將其轉(zhuǎn)化為傳送給Map函數(shù)的鍵值對(duì)。這一輸入分片抽象類(lèi)主要包含兩個(gè)抽象方法，得到分片方法和視頻錄入接口方法。如圖2所示， 視頻讀寫(xiě)接口首先將視頻文件抽象為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ì)算下一段本地視頻大小，依次類(lèi)推。這樣在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，硬盤(pán)為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.

　　［2］ 郭奕希.基于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.

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

　　［7］ 高東海，李文生，張海濤.基于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.

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