黃潔琛，倪 明

(中國電子科技集團公司第三十二研究所，上海 200233)

1 概述

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展以及家庭網(wǎng)絡(luò)帶寬的提升，網(wǎng)絡(luò)視頻點播已經(jīng)成為當(dāng)下人們生活娛樂不可或缺的一部分。由于Flash 視頻(Flash Video，F(xiàn)LV)格式具有形成的文件極小、可以輕松地導(dǎo)入Flash、加載速度極快、能起到保護版權(quán)的作用，并且可以不通過本地的微軟或者REAL 播放器播放的特點，被眾多新一代視頻分享網(wǎng)站所采用，是目前增長最快、最為廣泛的視頻傳播格式［1］。而用戶上傳或者視頻網(wǎng)站購買的視頻源大都不是FLV 格式，這就需要對視頻源進行轉(zhuǎn)碼。若采用單一服務(wù)器進行轉(zhuǎn)碼，對服務(wù)器壓力很大，且耗時較長。Hadoop 是一個開源的分布式處理框架，可以在很多廉價計算機上搭建集群，對數(shù)據(jù)進行分布式的存儲和計算。MapReduce 是Hadoop 的一個核心模塊，它很適合處理海量的數(shù)據(jù)，可以根據(jù)輸入數(shù)據(jù)的分布情況自動創(chuàng)建多個并行子任務(wù)，并將子任務(wù)調(diào)度到合適的節(jié)點上運行［2］。本文使用Hadoop 框架中的分布式文件系統(tǒng)(Hadoop Distributed File System，HDFS)存儲分割后的視頻分片，根據(jù)MapReduce 分布式計算思想，利用FFmpeg 對視頻進行分布式轉(zhuǎn)碼，旨在不大幅提高硬件成本的基礎(chǔ)上縮短視頻轉(zhuǎn)碼時間。

2 研究現(xiàn)狀

視頻轉(zhuǎn)碼是一個將已經(jīng)壓縮編碼的視頻碼流轉(zhuǎn)換成另一個視頻碼流的過程，本質(zhì)上是一個先解碼再編碼的過程，因為需要大量空域頻域的轉(zhuǎn)換，所以對計算能力的要求較高［3］。而且，隨著高清電影的發(fā)展，影片片源容量從幾兆到幾十兆不等，造成了轉(zhuǎn)碼時間的急劇增加，這對視頻的存儲和轉(zhuǎn)碼服務(wù)提出了很高的要求。

目前主流的轉(zhuǎn)碼方式有以下3 種［4-5］:

(1)單機轉(zhuǎn)碼:使用單臺高性能服務(wù)器完成視頻的轉(zhuǎn)碼工作。將視頻傳輸至轉(zhuǎn)碼服務(wù)器，服務(wù)器對視頻進行轉(zhuǎn)碼，然后將轉(zhuǎn)碼后的視頻返回［3］。這種轉(zhuǎn)碼方式操作簡單，但是單臺服務(wù)器的性能瓶頸會導(dǎo)致轉(zhuǎn)碼時間較長，不適合大量視頻的轉(zhuǎn)碼工作。

(2)基于云計算轉(zhuǎn)碼:使用云的存儲和計算能力進行視頻轉(zhuǎn)碼。一般是有視頻轉(zhuǎn)碼需要的公司租賃提供云服務(wù)公司的實例，利用其強大的計算和存儲能力進行視頻轉(zhuǎn)碼。一般一個視頻由一個實例進行轉(zhuǎn)碼，本質(zhì)上也是單節(jié)點進行視頻轉(zhuǎn)碼。

(3)分布式轉(zhuǎn)碼:其基本思想是先將一個大的視頻分割成分段，然后將這些分段分布到多臺轉(zhuǎn)碼機器上同時進行轉(zhuǎn)碼，再將轉(zhuǎn)碼后的分段合并，生成目標(biāo)視頻，然后將合并后的視頻返回。這種方法優(yōu)點是可以降低視頻轉(zhuǎn)碼的時間成本，并且可以應(yīng)對大量并發(fā)的轉(zhuǎn)碼任務(wù)，缺點在于實現(xiàn)較為復(fù)雜，并且會產(chǎn)生較大的網(wǎng)絡(luò)開銷。

3 Hadoop 和FFmpeg 介紹

3.1 Hadoop

Hadoop 是Apache 組織的一個開源的分布式基礎(chǔ)框架，可以將大量廉價的硬件設(shè)備組織成分布式集群，并在集群上存儲數(shù)據(jù)和運行程序。其核心部件為分布式文件系統(tǒng)(HDFS)和編程模型(MapReduce)兩部分。

HDFS［6］是一個高容錯的分布式文件系統(tǒng)，參照GFS(Google File System)實現(xiàn)，適合部署在廉價硬件上，而且它提供高吞吐量來訪問應(yīng)用程序的數(shù)據(jù)，適合那些有著超大數(shù)據(jù)集的應(yīng)用程序。HDFS 由一個NameNode 節(jié)點和多個 DataNode 節(jié)點組成。NameNode 用于管理文件系統(tǒng)元數(shù)據(jù)和處理客戶端對文件的訪問，而DataNode 節(jié)點用于實際存儲數(shù)據(jù)。在HDFS 內(nèi)部，一個文件被分割成一個或者多個數(shù)據(jù)塊，存儲在一組DataNode 上。

MapReduce［7］是Google 提出的一個并行編程架構(gòu)，適用于對大數(shù)據(jù)集的并行處理。它將一個大的任務(wù)分成多個MapReduce 作業(yè)，每個MapReduce 作業(yè)又可以分為Map 和Reduce 兩個階段。Map 階段對數(shù)據(jù)進行并行處理，Reduce 階段對Map 階段的結(jié)果進行合并，得到最終結(jié)果。通常，需要一個Jobtracker 節(jié)點對計算任務(wù)進行分配和調(diào)度，由多個Tasktracker 執(zhí)行具體的任務(wù)。

3.2 FFmpeg

FFmpeg 是一個開源免費跨平臺的視頻和音頻流方案，屬于自由軟件，采用LGPL 或GPL 許可證。它提供了錄制、轉(zhuǎn)換以及流化音視頻的完整解決方案，包含了非常先進的音頻/視頻編解碼庫libavcodec，支持MPEG，MPEG4，F(xiàn)LV，Div 等40 多種編碼，能快速地進行音視頻格式轉(zhuǎn)換、分割、合并等多種操作。FFmpeg 在Linux 平臺下開發(fā)，但它同樣也可以在其他操作系統(tǒng)環(huán)境中編譯運行［8］。

4 系統(tǒng)架構(gòu)

整個系統(tǒng)由1 個Manager 和1 個Hadoop 集群組成，系統(tǒng)的拓?fù)浣Y(jié)構(gòu)如圖1 所示。

圖1 系統(tǒng)拓?fù)浣Y(jié)構(gòu)

Manager 主要負(fù)責(zé)保存用戶上傳的原始視頻，對原始視頻進行分割［9］，將分割后的視頻分段上傳到HDFS，對之后整個轉(zhuǎn)碼過程進行監(jiān)控和管理，并且負(fù)責(zé)轉(zhuǎn)完成后的清理工作。保存原始視頻是為了確保在視頻轉(zhuǎn)碼完畢之前，原始視頻不會丟失，一旦轉(zhuǎn)碼過程失敗，可以重啟整個轉(zhuǎn)碼過程，增強系統(tǒng)的魯棒性。對原始視頻分割完畢后，Manager 將分割后的視頻分段提交到HDFS 中，然后啟動視頻轉(zhuǎn)碼和合并任務(wù)。在視頻合并結(jié)束后，Manager 負(fù)責(zé)清理轉(zhuǎn)碼過程中產(chǎn)生的中間文件，包括轉(zhuǎn)碼前和轉(zhuǎn)碼后的分段視頻等，然后將用戶上傳的原始視頻刪除，并且將轉(zhuǎn)碼后的視頻信息返回給客戶端。

Hadoop 集群主要負(fù)責(zé)對Manager 分割后的分段視頻進行轉(zhuǎn)碼［2，8］，然后對轉(zhuǎn)碼后的視頻進行合并。當(dāng)Manager 將分割好的視頻分段上傳到HDFS后，Manager 會啟動MapReduce 轉(zhuǎn)碼和合并程序。程序在Map 階段完成各段視頻的轉(zhuǎn)碼，在Reduce階段，由一個Reducer 完成轉(zhuǎn)碼后分段視頻的合并工作。然后將最終的視頻信息(包括視頻名、視頻位置、視頻大小等)返回給Manager。

系統(tǒng)的數(shù)據(jù)處理流程如圖2 所示，其中分段指分割后的視頻分段，新分段指轉(zhuǎn)碼后的視頻分段。

圖2 系統(tǒng)數(shù)據(jù)處理流程

系統(tǒng)按如下流程處理一個用戶的轉(zhuǎn)碼請求:

(1)用戶提交轉(zhuǎn)碼請求，Manager 檢查用戶權(quán)限和提交的視頻信息，若用戶有權(quán)限為此視頻轉(zhuǎn)碼，則回復(fù)允許請求，否則回復(fù)拒絕請求。

(2)若用戶收到拒絕信息，則轉(zhuǎn)碼過程結(jié)束。若收到允許請求，則用戶為視頻添加基本信息，開始上傳視頻。

(3)上傳結(jié)束后，Manager 回復(fù)用戶上傳完畢確認(rèn)信息，此時用戶可以自己設(shè)置轉(zhuǎn)碼參數(shù)，不設(shè)置則Manager 使用默認(rèn)參數(shù)。

(4)系統(tǒng)開始進行轉(zhuǎn)碼，轉(zhuǎn)碼結(jié)束后，NameNode向Manager 返回轉(zhuǎn)碼完成后的視頻的信息(包括視頻名稱、視頻位置、視頻大小等)。

(5)Manager 將轉(zhuǎn)碼完成后的視頻信息返回給用戶，用戶可以根據(jù)返回的信息讀取視頻。

5 視頻分布式轉(zhuǎn)碼的實現(xiàn)

整個轉(zhuǎn)碼過程可分為3 個階段:視頻分割，分段視頻轉(zhuǎn)碼和視頻合并。在視頻轉(zhuǎn)碼的3 個階段中，所有視頻處理類都是基于FFmpeg 軟件實現(xiàn)。由于FFmpeg 只提供C/C++的API，Java 只能對FFmpeg的可執(zhí)行文件進行功能的封裝，而FFmepg 的可執(zhí)行文件只支持本地的文件系統(tǒng)，并不支持HDFS［10］，所以，所有的視頻處理操作都是在本地文件系統(tǒng)中進行的。

5.1 視頻分割

視頻是一些數(shù)據(jù)的集合，在這個集合中，有許多頻域和時域的冗余信息。為了減小視頻的體積，需要使用視頻壓縮編碼技術(shù)來減少冗余數(shù)據(jù)。視頻通常以幀為單位，而視頻壓縮編碼會導(dǎo)致幀與幀之間通常不是獨立的，存在依賴關(guān)系。以MPEG［11］編碼標(biāo)準(zhǔn)為例，其定義了3 類幀，分別為I 幀、P 幀和B 幀。I 幀可以獨立進行編碼，不需要依賴其他幀;P幀為前向預(yù)測幀，需要參考前面的I 幀或者P 幀進行編碼;B 幀為雙向預(yù)測幀，需要參考前后的I 幀或者P 幀進行編碼。通常GOP(Group of Pictures)是視頻最小的顯示單位，它是由3 種幀按一定順序組合而成。每一個GOP 必須以I 幀開始，然后按照依賴關(guān)系插入P 幀和B 幀。圖3 所示為2 個GOP 的編碼過程。

圖3 幀編碼順序

由圖中可以看到，要分割視頻，必須找到關(guān)鍵幀I，從I 之前開始切割，否則會導(dǎo)致GOP 不可用，使分割后的視頻缺少信息，以至于轉(zhuǎn)碼后GOP 丟失，出現(xiàn)視頻卡頓的現(xiàn)象［12］。所以切割視頻的關(guān)鍵在于找到關(guān)鍵幀I，而使用FFmpeg 可以很容易找到關(guān)鍵幀的位置。

由于要驗證分段大小對轉(zhuǎn)碼時間的影響，因此需要按固定的塊大小來切割視頻。FFmpeg 只能根據(jù)時間跨度來切割視頻［10］，需要根據(jù)視頻碼率和塊大小計算分段視頻的時間跨度，從而估算切割點的大致位置，然后在時間點周圍找到關(guān)鍵幀，在關(guān)鍵幀之前切割視頻。視頻分割的流程如圖4所示。

圖4 視頻分割流程

5.2 分段視頻轉(zhuǎn)碼和視頻合并

當(dāng)Manager 將分段視頻上傳到HDFS 后，便啟動分段視頻的轉(zhuǎn)碼工作。首先，使用Hadoop 的balance工具，使視頻盡量均勻地分布到各個DataNode 上。這是為了保證:

(1)數(shù)據(jù)本地化［2］。因為在Map 階段進行轉(zhuǎn)碼時，需要將分段復(fù)制到本地文件系統(tǒng)。這樣可以使針對于某一分段的轉(zhuǎn)碼工作盡量在存儲有該分段的節(jié)點上進行，無需從遠(yuǎn)程節(jié)點復(fù)制，避免了網(wǎng)絡(luò)傳輸所造成的時間消耗和對網(wǎng)絡(luò)的壓力。

(2)使轉(zhuǎn)碼任務(wù)均勻分配到各個節(jié)點［2］。因為在資源充足的情況下，JobTracker 會優(yōu)先在存儲該分段的節(jié)點上啟動針對該分段的轉(zhuǎn)碼任務(wù)。使分段均勻分布到DataNode 可以將轉(zhuǎn)碼任務(wù)均勻分布到各個節(jié)點，避免單節(jié)點壓力過大，保證數(shù)據(jù)的并行性，以減少轉(zhuǎn)碼時間。

然后，MapReduce 程序啟動，JobTracker 會為各個TaskTracker 分配任務(wù)，Map 階段每個TaskTracker分到一個或幾個分段的轉(zhuǎn)碼任務(wù)。TaskTracker 會將分配到的需要轉(zhuǎn)碼的分段復(fù)制到本地文件系統(tǒng)，然后對每一個分段使用FFmpeg 工具，根據(jù)設(shè)定的編碼參數(shù)進行轉(zhuǎn)碼。同時，TaskTracker 可以監(jiān)控FFmpeg的轉(zhuǎn)碼過程，記錄轉(zhuǎn)碼日志，若轉(zhuǎn)碼失敗可以重啟轉(zhuǎn)碼任務(wù)。待分配到的全部分段視頻轉(zhuǎn)碼結(jié)束后，TaskTracker 會將其發(fā)送到將運行Reduce 程序的節(jié)點上進行視頻合并。

當(dāng)Map 階段運行結(jié)束后，Reduce 階段會啟動。此時運行Reduce 程序的節(jié)點已經(jīng)收到轉(zhuǎn)碼后的全部分段視頻。使用FFmpeg 工具，可以順序地對視頻進行合并操作，合并后將會生成一個本地的視頻文件。最后，Reduce 程序會將這個視頻文件上傳到HDFS，然后將其信息(主要是位置信息)發(fā)送給Manager，此時分段視頻轉(zhuǎn)碼和合并過程完成，其流程如圖5 所示。

圖5 分段視頻轉(zhuǎn)碼和視頻合并流程

6 實驗結(jié)果及分析

6.1 實驗環(huán)境

由于缺少服務(wù)器，本文在一臺8 核CPU、64 GB內(nèi)存、6 TB 硬盤、安裝CentOS6.2 64 位系統(tǒng)的服務(wù)器上建立了9 臺虛擬機進行實驗，虛擬化軟件為KVM(Kernel-based Virtual Machine)虛擬機統(tǒng)一配置為:2 核CPU，4 GB 內(nèi)存，50 GB 硬盤，系統(tǒng)為CentOS6.2 64 位系統(tǒng)。虛擬機角色如表1 所示。

表1 節(jié)點角色

實驗所用視頻大小為1.4 GB，將其分別按不同大小的分配進行分割，所得到的分段視頻的數(shù)量如表2 所示。

表2 分段大小與分段數(shù)量

分別使用單機轉(zhuǎn)碼和分布式轉(zhuǎn)碼2 種方式對所用的視頻進行轉(zhuǎn)碼，分布式轉(zhuǎn)碼時，設(shè)置DataNode(TaskTracker)的數(shù)量分別為2，4，6，8，轉(zhuǎn)碼前后視頻的參數(shù)如表3 所示。

表3 轉(zhuǎn)碼前后視頻參數(shù)

6.2 實驗結(jié)果

在單個節(jié)點上使用FFmpeg 工具對視頻進行轉(zhuǎn)碼時，耗時1 422 s。在使用分布式轉(zhuǎn)碼時，耗時如圖6所示。圖7 為分段大小為64 MB 時，分布式轉(zhuǎn)碼消耗的時間隨TaskTracker 數(shù)目增加的變化趨勢。

圖6 分布式轉(zhuǎn)碼消耗時間

圖7 分段大小為64 MB 時轉(zhuǎn)碼消耗時間

6.3 實驗分析

在單節(jié)點上使用FFmpeg 工具對視頻進行轉(zhuǎn)碼時，耗時1 422 s，從圖6 可以看出，只有在2 臺TaskTracker，分段大小為16 MB 時，分布式轉(zhuǎn)碼耗時多于單節(jié)點視頻轉(zhuǎn)碼耗時。使用大于2 個TaskTracker 進行分布式轉(zhuǎn)碼耗時都遠(yuǎn)少于單節(jié)點轉(zhuǎn)碼，尤其是使用8 臺TaskTracker、分段大小為64 MB時，僅需要495 s，相比于單節(jié)點，節(jié)約了大約65%的轉(zhuǎn)碼時間。所以，本文提出的分布式轉(zhuǎn)碼方案可以很大程度上提高視頻轉(zhuǎn)碼的效率。

同時可以看到，在TaskTracker 數(shù)量相同的情況下，隨著分段大小的增加，分布式轉(zhuǎn)碼消耗時間呈現(xiàn)一個先下降后上升的趨勢，當(dāng)分段大小為64 MB 時轉(zhuǎn)碼時間最短。這和2 個原因有關(guān):(1)分段太小，會導(dǎo)致分段數(shù)目太多，MapReduce 的啟動時間增加［2］。(2)分段太大，對每個分段的轉(zhuǎn)碼時間增加，在任務(wù)無法完全平均分配的前提下，會導(dǎo)致節(jié)點壓力不均，并行粒度減小，從而導(dǎo)致性能下降［13］。

從圖7 中可以看到，隨著TaskTracker 數(shù)目的增加，分布式轉(zhuǎn)碼消耗時間呈下降趨勢，但是下降的幅度越來越小。這可能是因為實驗環(huán)境是在一臺服務(wù)器上搭建的虛擬機，它們都是使用物理機的磁盤。當(dāng)并行度太大，會使磁盤I/O 速度成為性能提升的瓶頸。

7 結(jié)束語

本文提出了一種基于Hadoop 的集存儲與轉(zhuǎn)碼于一體的分布式轉(zhuǎn)碼方案。使用HDFS 的多機備份機制可以有效保障視頻存儲的安全性，而使用MapReduce 編程框架，可以很方便地實現(xiàn)分布式轉(zhuǎn)碼工作。實驗結(jié)果表明，與單節(jié)點轉(zhuǎn)碼相比，使用本文方案在有8 臺TaskTracker 的Hadoop 集群中進行轉(zhuǎn)碼可以節(jié)省大約65%的轉(zhuǎn)碼時間，大大提高轉(zhuǎn)碼效率。然而，本文方案還存在如下不足:(1)在對視頻進行處理(分割、轉(zhuǎn)碼、合并)時，只能在本地文件系統(tǒng)中進行，不能直接在HDFS 中操作，從而需要對視頻進行復(fù)制和網(wǎng)絡(luò)傳輸，增加了存儲和時間消耗。(2)只有在所有Map 結(jié)束之后，Reduce 才會執(zhí)行，造成了時間損失。針對上述不足，今后的改進主要是采用Java 完成視頻處理，不依賴于FFmpeg 的可執(zhí)行文件，使其在HDFS 中就可完成處理。并且修改Map 和Reduce 的處理機制，使相鄰的視頻段完成轉(zhuǎn)碼即可進行合并，提高轉(zhuǎn)碼效率。

［1］王奎澎，劉建輝.Flv 文件格式及其嵌入式應(yīng)用［J］.計算機系統(tǒng)應(yīng)用，2010，19(3):190-193.

［2］Lam C.Hadoop 實戰(zhàn)［M］.韓冀中，譯.北京:人民郵電出版社，2011

［3］林杰聰，黃祥林，楊占昕.視頻轉(zhuǎn)碼技術(shù)研究［J］.中國傳媒大學(xué)學(xué)報:自然科學(xué)版，2006，13(3):43-51.

［4］Zhang Hao，Sun Shuxia.Application of Hadoop in Video Transcoding Based on Cloud Computing［J］.Computer ＆Telecommunication，2011，(12):36-37.

［5］Ji Wen，Chen Min，Park J J，et al.Distributed Video Coding:An Overview of Basics，Research Issues and Solutions［J］.International Journal of Ad Hoc and Ubiquitous Computing，2012，9(4):258-271.

［6］許春玲，張廣泉.分布式文件系統(tǒng)Hadoop HDFS 與傳統(tǒng)文件系統(tǒng)Linux FS 的比較與分析［J］.蘇州大學(xué)學(xué)報:工科版，2010，30(4):5-9.

［7］李建江，崔 健，王 聃，等.MapReduce 并行編程模型研究綜述［J］.電子學(xué)報，2011，39(11):2635-2642.

［8］覃 艷.基于FFMPEG 的視頻格式轉(zhuǎn)換技術(shù)研究［J］.電腦知識與技術(shù)，2011，7(12):2912-2913.

［9］Wu Yuan.ffmpeg 視頻分割的方法［EB/OL］.(2012-04-13).http://wuyuans.com/2012/04/ffmpeg-split.

［10］吳張順，張 珣.基于FFmpeg 的視頻編碼存儲研究與實現(xiàn)［J］.杭州電子科技大學(xué)學(xué)報，2006，26(3):30-34.

［11］雷國平，周 琨，吉吟東.MPEG 標(biāo)準(zhǔn)發(fā)展和研究綜述［J］.計算機工程，2003，29(12):185-187.

［12］邱 多.基于MPEG 壓縮域視頻關(guān)鍵幀提取技術(shù)的研究［D］.秦皇島:燕山大學(xué)，2011.

［13］田浪軍，陳衛(wèi)衛(wèi)，陳衛(wèi)東，等.云存儲系統(tǒng)中動態(tài)負(fù)載均衡算法研究［J］.計算機工程，2013，39(10):19-23.