基于Hadoop的分布式視頻轉(zhuǎn)碼系統(tǒng)研究

邢艷芳，周舒琪

(南京傳媒學(xué)院，江蘇 南京 211172)

0 引 言

隨著各類音視頻平臺(tái)的發(fā)展升級(jí)，產(chǎn)生了多種音視頻封裝格式和音視頻編碼格式。用戶相應(yīng)的轉(zhuǎn)碼需求日趨多樣化且高清轉(zhuǎn)碼請求也日益增多。目前普遍采用的單機(jī)版視頻轉(zhuǎn)碼技術(shù)的處理時(shí)間過長，占用服務(wù)器資源高，受制于單節(jié)點(diǎn)計(jì)算量和轉(zhuǎn)碼算法的并發(fā)能力[1]。在此基礎(chǔ)上進(jìn)行的技術(shù)革新仍會(huì)受到基本物理?xiàng)l件的影響，無法實(shí)現(xiàn)大幅度的轉(zhuǎn)碼速度提升。

音視頻數(shù)據(jù)具有的數(shù)據(jù)量龐大以及數(shù)據(jù)非結(jié)構(gòu)化的特點(diǎn)，導(dǎo)致難以使用普通的關(guān)系型數(shù)據(jù)庫滿足其數(shù)據(jù)存儲(chǔ)的需求。雖然當(dāng)前主流應(yīng)用的磁盤陣列存儲(chǔ)方法，其保密性和穩(wěn)定性都達(dá)到很高的水平，但價(jià)格高昂，有一定的應(yīng)用壓力，而且無法實(shí)現(xiàn)數(shù)據(jù)儲(chǔ)存與數(shù)據(jù)解析的一體化[2]。因此，為了解決存儲(chǔ)額數(shù)據(jù)處理的問題，分布式的存儲(chǔ)計(jì)算方式得到了研究發(fā)展。當(dāng)前主要應(yīng)用于互聯(lián)網(wǎng)領(lǐng)域，如Facebook社交網(wǎng)站、淘寶、華為等。HDFS是根據(jù)Googles在創(chuàng)業(yè)初期設(shè)計(jì)發(fā)展的GFS(Google File System)分布式文件系統(tǒng)發(fā)展而來，它的工作機(jī)制是利用Hadoop實(shí)現(xiàn)海量數(shù)據(jù)存儲(chǔ)的關(guān)鍵。

Hadoop系統(tǒng)通過底層的分布式存儲(chǔ)系統(tǒng)HDFS優(yōu)化存儲(chǔ)方式，擴(kuò)大存儲(chǔ)容量，提高讀寫速度[3]。應(yīng)用其突出的技術(shù)優(yōu)勢，該文提出一種基于Hadoop的分布式視頻轉(zhuǎn)碼系統(tǒng)。依托Hadoop云計(jì)算平臺(tái)，采用開源項(xiàng)目FFmpeg實(shí)現(xiàn)音視頻編解碼及格式轉(zhuǎn)換等功能。

1 系統(tǒng)應(yīng)用技術(shù)概述

1.1 Hadoop云平臺(tái)概述

Hadoop由Apache基金會(huì)開發(fā)，是一種穩(wěn)定的開源分布式結(jié)構(gòu)框架，為當(dāng)前常用的云計(jì)算存儲(chǔ)平臺(tái)之一，被國內(nèi)外企業(yè)如Facebook、Amazon、網(wǎng)易、中國移動(dòng)等廣泛應(yīng)用[4]。Hadoop的任務(wù)實(shí)現(xiàn)主要靠Client機(jī)器、主節(jié)點(diǎn)和從節(jié)點(diǎn)三部分。由主節(jié)點(diǎn)負(fù)責(zé)HDFS和MapReduce兩大Hadoop關(guān)鍵任務(wù)模塊的監(jiān)督。

Hadoop由HDFS、MapReduce、HBase、Pig等成員組成，其中最基礎(chǔ)的組成成分為底層數(shù)據(jù)存儲(chǔ)系統(tǒng)HDFS和執(zhí)行編程程序的MapReduce模型。采用開源項(xiàng)目FFmpeg實(shí)現(xiàn)音視頻編解碼及格式轉(zhuǎn)換等項(xiàng)目。

1.2 HDFS分布式文件系統(tǒng)

HDFS是基于GFS發(fā)展實(shí)現(xiàn)的分布式文件存儲(chǔ)系統(tǒng)。以流訪問的形式對整體程序應(yīng)用數(shù)據(jù)進(jìn)行訪問，減少數(shù)據(jù)錯(cuò)誤率，提高數(shù)據(jù)吞吐量。同時(shí)對于音視頻類特殊的非結(jié)構(gòu)式的數(shù)據(jù)仍具有很好的存儲(chǔ)能力。單個(gè)NameNode節(jié)點(diǎn)搭配多個(gè)DataNode節(jié)點(diǎn)進(jìn)行工作是一個(gè)HDFS架構(gòu)的典型集群方式。通常只有一臺(tái)機(jī)器在存入中使用NameNode，處理實(shí)現(xiàn)過程中存儲(chǔ)及管理元數(shù)據(jù)文件，設(shè)置數(shù)據(jù)文件命名，數(shù)據(jù)塊復(fù)制，集群配置等功能。DataNode節(jié)點(diǎn)將數(shù)據(jù)存儲(chǔ)在空間中，是文件存儲(chǔ)的基本單元，并且每次寫入中的設(shè)備都使用DataNode模型，周期性發(fā)送文件塊報(bào)告給NameNode進(jìn)行反饋通信。

1.3 MapReduce計(jì)算模型概述

MapReduce編程框架是適合應(yīng)用于超大型數(shù)據(jù)集處理的編程模型。將數(shù)據(jù)運(yùn)算分成了Map和Reduce兩部分實(shí)現(xiàn)，互相獨(dú)立又相互協(xié)同工作[5]。在Map階段將完整數(shù)據(jù)分片發(fā)送至多節(jié)點(diǎn)上進(jìn)行并行計(jì)算，完成后在Reduce階段將其合并成為最終計(jì)算結(jié)果?？梢院喕跀?shù)據(jù)處理中涉及到的任務(wù)分配、容錯(cuò)處理、負(fù)載均衡量等問題。適合應(yīng)用MapReduce計(jì)算方式的數(shù)據(jù)集必須要滿足兩大前提條件，首先元數(shù)據(jù)文件可以被分解為多個(gè)小型數(shù)據(jù)集，其次分成的每一個(gè)小的數(shù)據(jù)集都可以滿足并行處理方式。

2 系統(tǒng)分析及方案設(shè)計(jì)

2.1 系統(tǒng)功能概要

視頻文件常以幀形式存儲(chǔ)，對于存儲(chǔ)方式的選擇具有很大的要求，視頻的畫面大小，拍攝質(zhì)量，幀率編碼的不同會(huì)導(dǎo)致存儲(chǔ)容量發(fā)生變化。由于視頻文件本身的特殊性，存儲(chǔ)數(shù)據(jù)庫需要滿足連續(xù)讀寫以及數(shù)據(jù)流量大等特點(diǎn)。為實(shí)現(xiàn)多種編碼格式之間的相互轉(zhuǎn)換，則需要進(jìn)行大量的數(shù)據(jù)分析運(yùn)算?，F(xiàn)有傳統(tǒng)系統(tǒng)主要應(yīng)用以下三種轉(zhuǎn)碼模式，很難高效完成如此體量的實(shí)時(shí)并發(fā)轉(zhuǎn)碼請求。

(1)單機(jī)模式：最基礎(chǔ)也是最簡單的服務(wù)方式。由用戶和轉(zhuǎn)碼服務(wù)器直接交換數(shù)據(jù)實(shí)現(xiàn)。僅適合用于低轉(zhuǎn)碼量的目標(biāo)文件，并且受單一轉(zhuǎn)碼服務(wù)器的性能限制，轉(zhuǎn)碼時(shí)間很難得到大幅度提升，轉(zhuǎn)碼質(zhì)量也無法應(yīng)對高數(shù)據(jù)量的轉(zhuǎn)碼任務(wù)。

(2)基于云的轉(zhuǎn)碼模式[6]：將第一種轉(zhuǎn)碼方式的轉(zhuǎn)碼服務(wù)器部署在云平臺(tái)進(jìn)行。利用云計(jì)算大幅提高了數(shù)據(jù)計(jì)算量和處理速度。但基本轉(zhuǎn)碼方式內(nèi)核未得到改變，仍不具有高效率處理多并發(fā)轉(zhuǎn)碼任務(wù)的能力。

(3)分布式轉(zhuǎn)碼模式[7]：將大任務(wù)量視頻分解成多個(gè)小任務(wù)量視頻，分別傳送到多個(gè)轉(zhuǎn)碼機(jī)器上進(jìn)行數(shù)據(jù)處理，完成后將分片任務(wù)合成返回給用戶。應(yīng)用了并行轉(zhuǎn)碼的思想，降低了時(shí)間成本。但是操作復(fù)雜，很容易造成數(shù)據(jù)丟失和亂序排列。應(yīng)用成本高昂。

根據(jù)現(xiàn)有的視頻轉(zhuǎn)碼模式的問題進(jìn)行總結(jié)，本課題利用分布式轉(zhuǎn)碼的并發(fā)轉(zhuǎn)碼思想和云服務(wù)器部署解決了實(shí)體轉(zhuǎn)碼服務(wù)器價(jià)格高昂的問題[8]。Hadoop平臺(tái)自身的HDFS文件存儲(chǔ)系統(tǒng)和MapReduce編程框架分別為海量視頻存儲(chǔ)和視頻分段及任務(wù)下發(fā)的難題提供了簡便的應(yīng)用條件。系統(tǒng)應(yīng)用的開源可編譯的FFmpeg為視頻轉(zhuǎn)碼過程中的解碼和再編碼提供了豐富的函數(shù)庫支持。本系統(tǒng)結(jié)合視頻存儲(chǔ)和視頻轉(zhuǎn)碼功能，大幅減少了轉(zhuǎn)碼時(shí)間，提高了轉(zhuǎn)碼效率。

2.2 系統(tǒng)的架構(gòu)設(shè)計(jì)

2.2.1 系統(tǒng)架構(gòu)模型

時(shí)至今日，“泰諾”投毒案仍未告破，強(qiáng)生公司的10萬美元獎(jiǎng)金還無人領(lǐng)取。但我們相信在安保體系更加完善的今天，恐怖襲擊的陰霾終將消散。

系統(tǒng)整體架構(gòu)模型如圖1所示，系統(tǒng)主體由一個(gè)網(wǎng)絡(luò)服務(wù)器(WebServer)和搭建其上的Hadoop集群組成?？梢杂啥喾N形式的客戶端(Client)對中心WebServer服務(wù)器發(fā)送訪問請求，接收用戶需要進(jìn)行轉(zhuǎn)碼的視頻文件。這類接收工作由服務(wù)器上Hadoop集群中的NameNode節(jié)點(diǎn)完成，并將其轉(zhuǎn)發(fā)給集群中的多個(gè)DataNode節(jié)點(diǎn)進(jìn)行數(shù)據(jù)處理，完成任務(wù)調(diào)度。

2.2.2 系統(tǒng)運(yùn)行流程

本系統(tǒng)處理完成一個(gè)用戶轉(zhuǎn)碼請求的步驟如下：

①用戶Client發(fā)送請求：用戶向中心服務(wù)器發(fā)送視頻請求，如所需視頻名稱、視頻格式、視頻碼率及其他視頻信息。

圖1 系統(tǒng)整體架構(gòu)模型

②發(fā)送轉(zhuǎn)碼命令：由WebServer服務(wù)器對用戶請求進(jìn)行接收處理，并將其發(fā)送給承載的Hadoop集群中的NameNode節(jié)點(diǎn)上。

③進(jìn)行分布式轉(zhuǎn)碼：由NameNode節(jié)點(diǎn)負(fù)責(zé)調(diào)用集群中的DataNodes節(jié)點(diǎn)，多節(jié)點(diǎn)進(jìn)行轉(zhuǎn)碼任務(wù)的并行計(jì)算。

④完成視頻轉(zhuǎn)碼任務(wù)：分布式轉(zhuǎn)碼進(jìn)程結(jié)束后，文件會(huì)暫存在DataNode節(jié)點(diǎn)中。由NameNode向WebServer返回轉(zhuǎn)碼完成后的視頻文件所在地DataNodeX。

⑤發(fā)送視頻所在位置：將WebServer接收到的視頻所在位置DataNodeX發(fā)送給用戶端。

⑥讀取視頻：用戶從DataNodeX節(jié)點(diǎn)上獲取轉(zhuǎn)碼完成后的新視頻文件。

3 系統(tǒng)模塊設(shè)計(jì)

3.1 視頻數(shù)據(jù)在HDFS上的存儲(chǔ)模塊

通常采用的視頻分段思想主要分為以下兩種：獨(dú)立視頻獨(dú)立成段、單一視頻多個(gè)分段方式。由于音視頻文件本身數(shù)據(jù)為非結(jié)構(gòu)化數(shù)據(jù)，不可直接采用傳統(tǒng)壓縮編碼方式進(jìn)行存儲(chǔ)。HDFS中所有的文件都以數(shù)據(jù)塊形式進(jìn)行存儲(chǔ)，每個(gè)數(shù)據(jù)塊的大小都可以根據(jù)需求進(jìn)行調(diào)整[9]。在執(zhí)行集群處理時(shí)，由NameNode進(jìn)行HDFS文件存儲(chǔ)系統(tǒng)的監(jiān)督調(diào)度，由從節(jié)點(diǎn)負(fù)責(zé)運(yùn)行系統(tǒng)大部分功能，實(shí)行數(shù)據(jù)分析和計(jì)算，并需要對自身與主節(jié)點(diǎn)的通信進(jìn)程進(jìn)行監(jiān)督守護(hù)[10]。

在文件寫入HDFS文件管理系統(tǒng)的過程中，首先需要Client節(jié)點(diǎn)向NameNode名稱節(jié)點(diǎn)獲取文件寫入許可；NameNode啟動(dòng)工作，此節(jié)點(diǎn)是整個(gè)文件系統(tǒng)中數(shù)據(jù)目錄和元數(shù)據(jù)存放地點(diǎn)，負(fù)責(zé)獲取和管理其下管理的各數(shù)據(jù)節(jié)點(diǎn)的運(yùn)行信息，將文件存儲(chǔ)的地址位置信息發(fā)送返回給Client；Client接收后，將各數(shù)據(jù)片段文件按順序?qū)懭氲綄?yīng)的DataNode中。在文件讀取的過程中，由Client向NameNode節(jié)點(diǎn)發(fā)起文件讀取請求，NameNode節(jié)點(diǎn)對其回復(fù)文件存儲(chǔ)的DataNode節(jié)點(diǎn)信息，以使Client獲取完整文件數(shù)據(jù)。

視頻幀分為IP、PF和BF三種形式。其中IF為關(guān)鍵幀，它是GOP的第一個(gè)幀，包含第一個(gè)場景的全部信息；RF為單項(xiàng)預(yù)測幀，它只保留與前一幀的畫面差值信息；BF為雙向預(yù)測幀，它存儲(chǔ)了前后兩幀全部的畫面信息[11]。如果直接將視頻數(shù)據(jù)存儲(chǔ)至HDFS系統(tǒng)中，在后續(xù)分段中會(huì)導(dǎo)致視頻分段之間存在關(guān)聯(lián)性。由此可見，視頻分片不可隨便切割，要嚴(yán)格按照IF幀進(jìn)行分片，以保證幀的完整性以及GOP畫面的完整。

本系統(tǒng)利用了FFmpeg進(jìn)行獨(dú)立分段，將一個(gè)視頻文件切割成多個(gè)獨(dú)立段。首先設(shè)置一個(gè)固定的視頻文件大小m(通常將視頻切片數(shù)據(jù)大小設(shè)定為16 MB～64 MB)，依照m的大小將整個(gè)文件分割成n份可以獨(dú)立播放的視頻文件。此時(shí)，在存儲(chǔ)系統(tǒng)中會(huì)存在(n-1)個(gè)大小等于m的分段文件和1個(gè)小于或等于m大小的分段文件。之后將分段文件存儲(chǔ)至HDFS中的n個(gè)大小為m的block中，在Hadoop的集群中進(jìn)行存取。分割方式如表1所示。

表1 視頻分割方式

由于分段視頻文件大小m的選取存在差異，因此即使對于同一視頻，也會(huì)存在不同的分段視頻量n。雖然單一小數(shù)據(jù)量的視頻段可以減少數(shù)據(jù)節(jié)點(diǎn)的運(yùn)算壓力，但是視頻合成壓力也應(yīng)運(yùn)而生，會(huì)對視頻文件的讀取和寫入過程產(chǎn)生較大的影響[12]。以下選取一個(gè)1.2 G視頻量的目標(biāo)視頻，探究不同數(shù)據(jù)量m和分段量對視頻讀取速度的影響，結(jié)果如圖2所示。

從圖表結(jié)果中可以看出，在整體趨勢下，不同數(shù)據(jù)量m和分段量n在視頻切割階段的讀取速度并沒有存在很大的差異。但是，在對大數(shù)據(jù)量視頻進(jìn)行視頻轉(zhuǎn)碼時(shí)，小數(shù)據(jù)量m的選取會(huì)導(dǎo)致分段量n的增加，這時(shí)會(huì)影響后續(xù)視頻合成時(shí)的速度。并且過多切割可能會(huì)對切口處的數(shù)據(jù)量存在一定范圍的丟失，不利于視頻轉(zhuǎn)碼后的完整性，還是存在很大弊端，因此需要尋找一個(gè)最佳數(shù)據(jù)量mmax，以此實(shí)現(xiàn)功能的最大化。

圖2 視頻分段對視頻讀取速度的影響

在系統(tǒng)分片存儲(chǔ)完成后，在分段分發(fā)的過程中應(yīng)注意在NameNode節(jié)點(diǎn)上使用Hadoop balancer的命令，保證數(shù)據(jù)量均衡分布在各DataNode節(jié)點(diǎn)上，在后續(xù)MapReduce的工作過程中減少網(wǎng)絡(luò)數(shù)據(jù)傳輸誤差。

3.2 基于FFmpeg的分布式轉(zhuǎn)碼模塊

FFmpeg[13]是一種適用于多種編譯環(huán)境的跨平臺(tái)開源多媒體架構(gòu)，遵循LGPL/GPL許可協(xié)議?？梢詫?shí)現(xiàn)編解碼在內(nèi)的多種功能。包含了先進(jìn)音視頻編解碼庫libavcodes，因此在視頻格式不斷推陳出新的今天，它仍然可以支持最古老的視頻格式。

在Map端實(shí)現(xiàn)轉(zhuǎn)碼時(shí)，需要對任務(wù)視頻的多個(gè)分段部分分別進(jìn)行轉(zhuǎn)碼，因此需要確保原視頻文件的分段均勻發(fā)送給多個(gè)負(fù)責(zé)視頻處理的DataNode節(jié)點(diǎn)，從而實(shí)現(xiàn)節(jié)點(diǎn)的最大化利用，將數(shù)據(jù)并行化處理的優(yōu)勢發(fā)揮到極致。在數(shù)據(jù)節(jié)點(diǎn)上，啟動(dòng)安裝的FFmpeg設(shè)定轉(zhuǎn)碼參數(shù)，按照用戶需求，對視頻文件進(jìn)行轉(zhuǎn)碼業(yè)務(wù)。在Reduce端進(jìn)行視頻分段的合并，和多節(jié)點(diǎn)轉(zhuǎn)碼不同，視頻合并通常采用單一Reduce進(jìn)行，負(fù)責(zé)將來自多個(gè)Map端的轉(zhuǎn)碼完成后的輸出視頻文件進(jìn)行合并。

在功能上MapReduce實(shí)現(xiàn)將一個(gè)任務(wù)視頻文件劃分為多個(gè)Key/Value形式對的子任務(wù)文件。采用單個(gè)Map數(shù)值對應(yīng)單個(gè)視頻分段文件的方式進(jìn)行文件輸入，以保證單獨(dú)視頻段的完整性。依據(jù)特定的Map數(shù)值在HDFS存儲(chǔ)系統(tǒng)中找到對應(yīng)的視頻分段文件，將其作為對應(yīng)Key的value值返回，以Key/value函數(shù)對的形式寫入Map函數(shù)，由Map()函數(shù)調(diào)度啟用轉(zhuǎn)碼程序。

用戶提交任務(wù)文件給JobTracer，一般一個(gè)處理過程中只存在單個(gè)JobTracer節(jié)點(diǎn)進(jìn)行數(shù)據(jù)任務(wù)的分配和傳達(dá)，而存在多個(gè)TaskTracer節(jié)點(diǎn)執(zhí)行具體的數(shù)據(jù)處理操作。隨后將分段后的切片文件作為小型數(shù)據(jù)塊傳送至Map節(jié)點(diǎn)；Map節(jié)點(diǎn)得到每個(gè)Key/value數(shù)據(jù)對，并通過處理寫入文件；Reduce節(jié)點(diǎn)獲取暫存文件中的多個(gè)Key/value數(shù)據(jù)對，根據(jù)相同的Key值進(jìn)行匹配后迭代計(jì)算，從而將最終數(shù)據(jù)存入文件。由于整個(gè)Hadoop系統(tǒng)框架都是使用Java語言編寫完成的程序，而FFmpeg的函數(shù)庫是由C/C++語言編寫，因此需要使用Hadoop Pipes工具或使用如圖3所示的JNI技術(shù)調(diào)用[14]，實(shí)現(xiàn)Java語言和C++程序之間的通信。

圖3 JNI調(diào)用C/C++接口

視頻轉(zhuǎn)碼系統(tǒng)的基本步驟是先解碼后編碼。在整個(gè)視頻轉(zhuǎn)碼過程中，首先使用函數(shù)av_read_frame( )的調(diào)用實(shí)現(xiàn)視頻碼流中的單幀讀取；隨后通過向終端窗口輸入avcodec_decode_video0( )視頻文件格式解碼命令和avcodec_encode_video0( )編碼命令分別實(shí)現(xiàn)單幀視頻的解碼和重編碼，最后寫入文件[15]。

4 系統(tǒng)測試與數(shù)據(jù)分析

4.1 實(shí)驗(yàn)環(huán)境部署

本系統(tǒng)的部署主要分為兩大部分，第一部分是完成Hadoop完全分布式集群的搭建與環(huán)境變量設(shè)置；第二部分是完成FFmpeg的轉(zhuǎn)碼功能部署。并且完成Hadoop核心文件core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml的部署。配置分發(fā)節(jié)點(diǎn)和集群全啟動(dòng)。本課題使用虛擬機(jī)進(jìn)行系統(tǒng)測試。WebServer：使用2核CPU、12線G內(nèi)存的筆記本作為小型服務(wù)器。Hadoop集群：三臺(tái)虛擬機(jī)都使用Linux CentOS 7 64位系統(tǒng)。配置一臺(tái)作為NameNode，其余兩臺(tái)虛擬機(jī)為DataNode。

4.2 實(shí)驗(yàn)視頻輸入條件

該實(shí)驗(yàn)視頻文件按照FFmpeg模塊設(shè)計(jì)的m值范圍進(jìn)行分片切割。分割后的視頻片段數(shù)如表2所示。

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

實(shí)驗(yàn)從兩種變量方式進(jìn)行了設(shè)計(jì)，分別探究了不同條件影響下的轉(zhuǎn)碼能力差距。

表2 視頻分段大小與分段個(gè)數(shù)

(1)按以上實(shí)驗(yàn)視頻的選取標(biāo)準(zhǔn)，將1.2 G的目標(biāo)視頻進(jìn)行轉(zhuǎn)碼實(shí)現(xiàn)，實(shí)驗(yàn)?zāi)康氖菍KV的視頻格式轉(zhuǎn)化為MP4的視頻格式。轉(zhuǎn)碼方案都采用本課題設(shè)計(jì)的基于Hadoop的分布式視頻轉(zhuǎn)碼系統(tǒng)。實(shí)驗(yàn)變量為目標(biāo)視頻不同大小的分段量，通過比較不同變量條件下對應(yīng)使用的轉(zhuǎn)碼時(shí)間，得出最優(yōu)分片大小。其結(jié)果如圖4所示。

圖4 分段式轉(zhuǎn)碼時(shí)間對比

從圖中可以看出，當(dāng)分段大小為32 MB時(shí)，達(dá)到折線最低點(diǎn)，僅使用351秒，轉(zhuǎn)碼速率最快。結(jié)合之前圖3中的分析得出結(jié)論：當(dāng)視頻分段過多時(shí)，雖然單一視頻分段所需的處理時(shí)間變短，但同樣也增加了視頻段合成的時(shí)間，造成了總體轉(zhuǎn)碼時(shí)長的增加。而在分片量為32 MB時(shí)，各節(jié)點(diǎn)處理任務(wù)的速度和合成節(jié)點(diǎn)還原視頻文件的速度互相平衡，使系統(tǒng)運(yùn)行速度達(dá)到最大值，因此32 MB為視頻處理的最優(yōu)分片量。

(2)在實(shí)驗(yàn)一的基礎(chǔ)上，選取最優(yōu)的32 MB視頻分段。分別使用單臺(tái)DataNode模擬的單機(jī)轉(zhuǎn)碼方式和多臺(tái)DataNodes組成的分布式集群方式進(jìn)行視頻轉(zhuǎn)碼。利用本實(shí)驗(yàn)探究本課題設(shè)計(jì)系統(tǒng)相對于傳統(tǒng)單機(jī)轉(zhuǎn)碼的優(yōu)勢，其實(shí)驗(yàn)結(jié)果如圖5所示。

圖5 32 MB分段下不同轉(zhuǎn)碼方式的轉(zhuǎn)碼時(shí)間

從圖中可以看出，對于相同的目標(biāo)視頻，轉(zhuǎn)碼時(shí)間由單機(jī)方式轉(zhuǎn)碼消耗的952秒縮短至分布式視頻轉(zhuǎn)碼方式的475秒。由此得出結(jié)論：使用分布式集群方式進(jìn)行數(shù)據(jù)轉(zhuǎn)碼，可大幅度降低轉(zhuǎn)碼時(shí)間，提高轉(zhuǎn)碼效率。

5 結(jié)束語

相比于單機(jī)轉(zhuǎn)碼方式，分布式轉(zhuǎn)碼的轉(zhuǎn)碼時(shí)間更短，實(shí)驗(yàn)中的數(shù)據(jù)可以看出至少實(shí)現(xiàn)了50%的速度提升。增加數(shù)據(jù)節(jié)點(diǎn)數(shù)量可以分擔(dān)各節(jié)點(diǎn)上的數(shù)據(jù)處理量，提高轉(zhuǎn)碼速度。但由于服務(wù)器計(jì)算能力的限制，越多的數(shù)據(jù)節(jié)點(diǎn)需要越高質(zhì)量的處理器運(yùn)行，因此轉(zhuǎn)碼時(shí)間也不會(huì)一直縮減下去，而是維持在一個(gè)臨界點(diǎn)附近。在當(dāng)前三網(wǎng)融合的發(fā)展策略下，企業(yè)和用戶的需求得到了多樣化變革。因此在挑戰(zhàn)和需要并存的當(dāng)下，該系統(tǒng)可以提供一種更高效、更便捷、更經(jīng)濟(jì)化的轉(zhuǎn)碼方案，是具有現(xiàn)實(shí)應(yīng)用和客觀商業(yè)價(jià)值的一款視頻轉(zhuǎn)碼系統(tǒng)。