基于Hadoop 的分布式視頻轉(zhuǎn)碼方案

黃潔琛，倪 明

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

1 概述

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

2 研究現(xiàn)狀

視頻轉(zhuǎn)碼是一個(gè)將已經(jīng)壓縮編碼的視頻碼流轉(zhuǎn)換成另一個(gè)視頻碼流的過(guò)程，本質(zhì)上是一個(gè)先解碼再編碼的過(guò)程，因?yàn)樾枰罅靠沼蝾l域的轉(zhuǎn)換，所以對(duì)計(jì)算能力的要求較高［3］。而且，隨著高清電影的發(fā)展，影片片源容量從幾兆到幾十兆不等，造成了轉(zhuǎn)碼時(shí)間的急劇增加，這對(duì)視頻的存儲(chǔ)和轉(zhuǎn)碼服務(wù)提出了很高的要求。

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

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

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

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

3 Hadoop 和FFmpeg 介紹

3.1 Hadoop

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

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

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

3.2 FFmpeg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1 視頻分割

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

圖3 幀編碼順序

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

由于要驗(yàn)證分段大小對(duì)轉(zhuǎn)碼時(shí)間的影響，因此需要按固定的塊大小來(lái)切割視頻。FFmpeg 只能根據(jù)時(shí)間跨度來(lái)切割視頻［10］，需要根據(jù)視頻碼率和塊大小計(jì)算分段視頻的時(shí)間跨度，從而估算切割點(diǎn)的大致位置，然后在時(shí)間點(diǎn)周?chē)业疥P(guān)鍵幀，在關(guān)鍵幀之前切割視頻。視頻分割的流程如圖4所示。

圖4 視頻分割流程

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

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

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

(2)使轉(zhuǎn)碼任務(wù)均勻分配到各個(gè)節(jié)點(diǎn)［2］。因?yàn)樵谫Y源充足的情況下，JobTracker 會(huì)優(yōu)先在存儲(chǔ)該分段的節(jié)點(diǎn)上啟動(dòng)針對(duì)該分段的轉(zhuǎn)碼任務(wù)。使分段均勻分布到DataNode 可以將轉(zhuǎn)碼任務(wù)均勻分布到各個(gè)節(jié)點(diǎn)，避免單節(jié)點(diǎn)壓力過(guò)大，保證數(shù)據(jù)的并行性，以減少轉(zhuǎn)碼時(shí)間。

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

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

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

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

6.1 實(shí)驗(yàn)環(huán)境

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

表1 節(jié)點(diǎn)角色

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

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

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

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

6.2 實(shí)驗(yàn)結(jié)果

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

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

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

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

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

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

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

7 結(jié)束語(yǔ)

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

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

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

［3］林杰聰，黃祥林，楊占昕.視頻轉(zhuǎn)碼技術(shù)研究［J］.中國(guó)傳媒大學(xué)學(xué)報(bào):自然科學(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é)報(bào):工科版，2010，30(4):5-9.

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

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

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

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

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

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

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