蔣春燕，王佳斌，鄭力新

　　（華僑大學 工學院，福建 泉州 362000）

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

　　關鍵詞：云環境；分布式；視頻解碼

0引言

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

1研究現狀

　　目前廣播數字電視網中實現SDV系統主要基于兩種技術架構:一種是1997年由美國Time Wanner Cable公司提出的基于開放協議的ISA［3］(交互服務架構);另一種是2007年由美國Comcast公司提出的基于私有協議框架的NGOD［4］(下一代視頻點播服務架構)。

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

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

2設計數據接口

　　2.1Hadoop數據類型的分析

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

　　2.2hadoop平臺上視頻數據類型的設計

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

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

3Hadoop平臺處理視頻數據

　　3.1在Hadoop上直接處理視頻數據的局限性

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

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

　　3.2在Hadoop上直接處理視頻數據的方法

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

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

4實驗分析

　　4.1實驗集群概述

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

　　4.2視頻解碼方法

　　本實驗數據使用的是某監控視頻中的一個攝像頭的監控視頻數據，該監控視頻格式是SDV格式，該監控視頻的特點是只有前景變化時才會開啟錄制模式，當前景消失在目標檢測區域時，停止錄制并將錄制視頻數據保存到該設備對應的云環境中。

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

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

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

　　4.3實驗結果分析

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

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

5結論

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

參考文獻

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

　　［2］ 郭奕希.基于Hadoop的視頻轉碼系統設計與實現［D］.武漢：華中科技大學，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］ 顏文清.交換式數字電視(SDV)的應用與推廣［J］.有線電視技術，2012 (1):6064.

　　［6］ 何海林,皮建勇. 大數據處理平臺比較與分析［J］. 微型機與應用,2015,34(11):79,17.

　　［7］ 高東海，李文生，張海濤.基于Hadoop的離線視頻處理技術研究與實現［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］ 趙曉萌.云環境下監控視頻結構化分析研究與實現［D］.北京：北京郵電大學，2015.