付 眸，楊賀昆，吳唐美，何 潤，馮朝勝,2，康 勝

(1.四川師范大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院,成都 610101； 2.可視化計(jì)算與虛擬現(xiàn)實(shí)四川省重點(diǎn)實(shí)驗(yàn)室(四川師范大學(xué)),成都 610101； 3.四川師大科技園發(fā)展有限公司,成都 610066)(*通信作者電子郵箱fymen@naver.com)

0 引言

隨著多媒體服務(wù)的蓬勃發(fā)展，尤其是智能手機(jī)的普及，人們越來越便捷地生成和傳播圖片、語音、視頻等多媒體數(shù)據(jù)；其中，視頻是主要的內(nèi)容形式之一。根據(jù)中國互聯(lián)網(wǎng)信息中心(China Internet Network Information Center, CNNIC)于2018年1月發(fā)布的《第41次中國互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告》[1]，截至2017年12月，中國網(wǎng)民總數(shù)已達(dá)7.72億；其中，有7.53億網(wǎng)民同時(shí)使用手機(jī)。有5.79億網(wǎng)民使用過網(wǎng)絡(luò)視頻類應(yīng)用，占總數(shù)的75%，比2016年增加了3 437萬。

視頻內(nèi)容的制作、上傳、分享離不開視頻轉(zhuǎn)碼處理；尤其是移動(dòng)端視頻分享，例如，通過QQ空間上傳分享一段視頻，上傳完成后，需要一段時(shí)間進(jìn)行視頻轉(zhuǎn)碼工作，才能在網(wǎng)頁中觀看，轉(zhuǎn)碼時(shí)間的長短與視頻的參數(shù)相關(guān)。隨著網(wǎng)絡(luò)視頻用戶規(guī)模的不斷增加，傳統(tǒng)的單機(jī)轉(zhuǎn)碼方式開始出現(xiàn)性能瓶頸，各類視頻網(wǎng)站或視頻應(yīng)用開始借助云計(jì)算技術(shù)[2-3]，搭建并行轉(zhuǎn)碼平臺(tái)以提升視頻轉(zhuǎn)碼效率。

本文根據(jù)視頻轉(zhuǎn)碼特點(diǎn)，采用分布式流處理技術(shù)，提出一種基于Spark Streaming的快速視頻轉(zhuǎn)碼方法。本文分析了傳統(tǒng)的單機(jī)轉(zhuǎn)碼方法和基于Hadoop的視頻轉(zhuǎn)碼方法，改進(jìn)了視頻切割的流程；并減少了批處理轉(zhuǎn)碼方式中大量等待時(shí)間。實(shí)驗(yàn)結(jié)果表明，本文提出的轉(zhuǎn)碼方法顯著提升了轉(zhuǎn)碼效率。

1 相關(guān)工作

視頻數(shù)據(jù)的編碼方式有很多種，如常見的HEVC(High Efficiency Video Coding)[4]、MPEG2(Moving Picture Experts Group 2)、MPEG4、H.264、VP9、VC1等。其中，聯(lián)合國下屬機(jī)構(gòu)國際電信聯(lián)盟電信標(biāo)準(zhǔn)分局(International Telecommunication Union Telecommunication standardization sector, ITU-T)制定了H.26X系列視頻編碼標(biāo)準(zhǔn)[5]，因其高效的壓縮算法、良好的實(shí)時(shí)傳播兼容性，在遠(yuǎn)程會(huì)議、網(wǎng)上聊天、在線視頻等領(lǐng)域得到廣泛應(yīng)用。

不同的視頻編碼方法有不同的使用場景，根據(jù)需要將視頻編碼進(jìn)行轉(zhuǎn)換是不可或缺的工作。傳統(tǒng)視頻轉(zhuǎn)碼方法是使用單機(jī)進(jìn)行轉(zhuǎn)碼工作，但在處理大量視頻資源時(shí)會(huì)有三種情況產(chǎn)生：1)多個(gè)視頻文件進(jìn)行轉(zhuǎn)碼時(shí)，通常會(huì)按序進(jìn)入轉(zhuǎn)碼隊(duì)列；單機(jī)在處理長隊(duì)列視頻轉(zhuǎn)碼工作十分耗時(shí)。2)某個(gè)視頻轉(zhuǎn)碼工作出現(xiàn)問題，后續(xù)工作停止，需要人工值守。3)不具備并發(fā)視頻轉(zhuǎn)碼能力。

針對上述情況，使用并行處理方法，可以較好解決以上問題。目前廣泛使用Hadoop框架[6]、Mapreduce編程模型[6-8]、分布式文件系統(tǒng)(Hadoop Distributed File System, HDFS)實(shí)現(xiàn)分布式存儲(chǔ)，開源多媒體處理框架執(zhí)行視頻轉(zhuǎn)碼任務(wù)。使用Hadoop分布式視頻轉(zhuǎn)碼方案，一般會(huì)有以下幾個(gè)步驟[9]：1)將源視頻切分成視頻分片，并上傳至HDFS。2)運(yùn)行Map()從HDFS下載視頻分片。3)節(jié)點(diǎn)通過多媒體處理框架進(jìn)行轉(zhuǎn)碼，并將轉(zhuǎn)碼后的文件上傳至HDFS。4)運(yùn)行Reduce()，對轉(zhuǎn)碼后的視頻分片進(jìn)行合并。

根據(jù)不同視頻轉(zhuǎn)碼任務(wù)，多媒體處理框架有多種選擇，F(xiàn)Fmpeg[10]支持多種視頻編碼方式的解碼和編碼，并能跨平臺(tái)運(yùn)行，成為眾多視頻轉(zhuǎn)碼研究的主要技術(shù)。MEncoder[11]因命令行解碼的方式，被廣泛應(yīng)用在二次開發(fā)的視頻播放器中。Kim等[12]的團(tuán)隊(duì)對分布式視頻轉(zhuǎn)碼技術(shù)進(jìn)一步研究，2012年研發(fā)了SMCCSE(Social Media Cloud Computing Service Environment)，該系統(tǒng)將社交網(wǎng)絡(luò)作為切入點(diǎn)，以人們在社交網(wǎng)絡(luò)活動(dòng)中產(chǎn)生的音頻、視頻、圖像等多媒體文件作為轉(zhuǎn)碼對象，使用平臺(tái)即服務(wù)(Platform-as-a-Service, PaaS)云平臺(tái)[13]，構(gòu)建了基于Hadoop的多媒體轉(zhuǎn)碼系統(tǒng)，從而拓展了分布式轉(zhuǎn)碼技術(shù)的應(yīng)用范圍。Kim等[14]持續(xù)關(guān)注分布式轉(zhuǎn)碼技術(shù)的研究進(jìn)展，于2015年提出了多媒體轉(zhuǎn)碼服務(wù)的優(yōu)化轉(zhuǎn)碼方案，該方案進(jìn)一步研究HDFS塊大小、塊備份數(shù)量、Java虛擬機(jī)資源占用、輸入/輸出緩存大小等多種因素對轉(zhuǎn)碼效率的影響，通過大量實(shí)驗(yàn)，解決了影響效率的關(guān)鍵問題。2017年，Kim等[15]研發(fā)了另一套基于Hadoop的分布式視頻轉(zhuǎn)碼方案HVTS (Hadoop-based Video Transcoding System),該方案的優(yōu)點(diǎn)是整合了視頻上傳、視頻轉(zhuǎn)碼、視頻分布式保存等模塊，提供了靈活的轉(zhuǎn)碼參數(shù)配置。

國內(nèi)的相關(guān)研究工作中，重點(diǎn)是對分布式視頻轉(zhuǎn)碼技術(shù)進(jìn)行優(yōu)化。早在2009年，龐一等[16]面向單機(jī)多核視頻編碼并行化技術(shù)進(jìn)行了綜述研究，介紹了在多核環(huán)境中視頻并行化處理的技術(shù)特點(diǎn)。分布式視頻轉(zhuǎn)碼的負(fù)載均衡設(shè)計(jì)也是一個(gè)相當(dāng)重要的研究工作；良好的集群的心跳連接不但可以提升系統(tǒng)穩(wěn)定性，結(jié)合調(diào)度算法，還能最大限度提升集群性能[17]。2014年，Song等[18]的團(tuán)隊(duì)研發(fā)了使用FFmpeg和MEncoder進(jìn)行解碼的分布式系統(tǒng)，該系統(tǒng)的特點(diǎn)是在Map階段，使用FFmpeg進(jìn)行轉(zhuǎn)碼任務(wù)；在Reduce階段，使用MEncoder進(jìn)行視頻的合并工作。2016年，Chen等[19]提出一種基于Hadoop平臺(tái)的視頻并行轉(zhuǎn)碼方法，該方法通過Mapreduce編程，并行化執(zhí)行FFmpeg命令，實(shí)現(xiàn)視頻分割、轉(zhuǎn)碼、合成。該方法與單機(jī)視頻轉(zhuǎn)碼的實(shí)驗(yàn)結(jié)果表明，該方法的轉(zhuǎn)碼效率有明顯提升。但該方法本質(zhì)是基于Hadoop的批處理方式，轉(zhuǎn)碼時(shí)，需要等待視頻切割任務(wù)完成后，Map節(jié)點(diǎn)才開始執(zhí)行視頻轉(zhuǎn)碼任務(wù)，冗余的等待時(shí)間使得轉(zhuǎn)碼效率提升有限。

2 關(guān)鍵技術(shù)

2.1 FFmpeg多媒體框架

FFmpeg是由開源社區(qū)維護(hù)的多媒體處理框架，提供解碼、編碼、轉(zhuǎn)碼、音頻視頻合成、音視頻分解、流媒體、視頻播放等功能。視頻轉(zhuǎn)碼流程如圖1所示。FFmpeg核心組件和功能如表1所示。

圖1 視頻轉(zhuǎn)碼流程Fig. 1 Flow chart of video transcoding表1 FFmpeg核心庫Tab. 1 FFmpeg core library

組件功能libavutil核心工具集,提供編程示例、數(shù)學(xué)函數(shù)、數(shù)據(jù)結(jié)構(gòu)等libavcodec基本的音視頻編碼、解碼庫libavformat對音視頻進(jìn)行分解和合并libavdevice可從第三方抓取和輸入媒體流libswscale提供視頻按照一定規(guī)格進(jìn)行縮放轉(zhuǎn)換功能libswresam-ple提供對音頻進(jìn)行重采樣、重編碼等轉(zhuǎn)碼操作

FFmpeg通過使用命令行的方式提供強(qiáng)大的多媒體操作功能，可以完成視頻的編碼、解碼。文獻(xiàn)[10]研究實(shí)現(xiàn)了對H.264和HEVC的視頻編碼，并能對這兩種編碼的視頻文件進(jìn)行相互轉(zhuǎn)換。

FFmpeg作為開源的多媒體框架，并不只針對視頻進(jìn)行處理，還擅長處理音頻、圖片、字幕、視頻/圖片采集等。

2.2 Spark Streaming流處理框架

Spark是目前流行的分布式框架之一，其核心由一組功能強(qiáng)大的擴(kuò)展庫組成。目前這些庫包括SparkSQL、Spark Streaming、MLlib以及GraphX，其他一些Spark庫和擴(kuò)展也在陸續(xù)開發(fā)中。Spark Streaming是Spark的組件之一，主要功能是實(shí)現(xiàn)流處理。

3 構(gòu)建視頻轉(zhuǎn)碼模型

Hadoop分布式系統(tǒng)擅長處理批量作業(yè)，分布式作業(yè)的運(yùn)行依賴于前一步驟作業(yè)的處理結(jié)果，需要數(shù)據(jù)全部處理完畢后，再進(jìn)行下一步作業(yè)；根據(jù)視頻轉(zhuǎn)碼的特性，建立流處理模型，將視頻分片數(shù)據(jù)視為流處理中的最小單元，通過調(diào)度算法快速分發(fā)視頻分片數(shù)據(jù)，節(jié)省Hadoop切片與Mapper之間的等待時(shí)間，從而達(dá)到提高視頻轉(zhuǎn)碼效率的目的。要建立視頻轉(zhuǎn)碼的流處理模型，首先要考慮視頻文件的特性，其次基于Spark Streaming框架，分別建立數(shù)據(jù)源、RDD、視頻合并服務(wù)器。其中，RDD是研究的關(guān)建。

3.1 Spark Streaming數(shù)據(jù)源設(shè)計(jì)

Spark Streaming運(yùn)行時(shí)，需要持續(xù)不斷地獲得輸入數(shù)據(jù)。一般視頻文件都會(huì)有較大體積，視頻文件在集群網(wǎng)絡(luò)中傳輸，會(huì)加重網(wǎng)絡(luò)開銷，降低系統(tǒng)效率，因此通過將完整的視頻文件進(jìn)行切片處理，把切分的視頻分片路徑作為文本輸入數(shù)據(jù)，減輕了集群網(wǎng)絡(luò)傳輸負(fù)擔(dān)。要設(shè)計(jì)持續(xù)穩(wěn)定的數(shù)據(jù)源，同時(shí)視頻分片粒度的大小保持一致，需要穩(wěn)定性良好的硬件環(huán)境和程序設(shè)計(jì)。

完整的源視頻文件需要切分為眾多小視頻文件，并滿足:

(1)

視頻文件V的總時(shí)長tsum應(yīng)與各分片S的時(shí)長tn之和相同。分片模塊調(diào)用SplitApp.Split()，在該函數(shù)中，調(diào)用FFmpeg進(jìn)行具體切片工作。同時(shí)，數(shù)據(jù)源需要持續(xù)不斷地產(chǎn)生視頻分片數(shù)據(jù)；因此，需要持續(xù)運(yùn)行SplitApp.Split()并調(diào)用FFmpeg命令，使用Java實(shí)現(xiàn)循環(huán)邏輯，直到視頻切片完成為止。分片節(jié)點(diǎn)的處理流程為：獲得視頻文件→調(diào)用Split→保存至HDFS目錄/slices。該功能偽代碼如算法1所示。

算法1 視頻文件分片模塊。

輸入 視頻文件；

輸出 視頻分片統(tǒng)一資源定位符(Uniform Resource Locator, URL)。

BEGIN

raw_video←源視頻目錄;t←分片時(shí)長;output←視頻輸出文件URL

WHILE(true)

vList=從raw_video目錄獲取視頻列表

FOR(f:vList)

SumTime←獲取視頻總時(shí)長;

start←0;leftTime←0;

FOR(s=start;leftTime>T;)

//ffmpeg視頻切片命令

ffmpeg -ss s -i f -c copy -t t output;

leftTime←leftTime-T;

s+=T;

start=s;

END FOR

END FOR

END WHILE

通過監(jiān)控上傳目錄raw_video，當(dāng)有視頻文件上傳完成，對該視頻文件進(jìn)行分片,并將分片文件URL作為數(shù)據(jù)源。

數(shù)據(jù)源的輸出為文本文檔，文本中包含視頻文件名稱和視頻分片的URL,格式為：

x.avi [空格] /目錄1/目錄2/x1.avi

建立StreamingContext對象，有以下步驟：

1)創(chuàng)建配置文件。

StreamingContext配置代碼格式如下：

SparkConf().setMaster(url).setAppName(String).

set(String,String)

其中set(String,String)函數(shù)可設(shè)置多個(gè)不同的參數(shù)，常用配置參數(shù)如表2所示。

表2 StreamingContext 配置參數(shù)Tab. 2 StreamingContext configuration parameters

2)參數(shù)傳遞。

根據(jù)集群硬件配置，合理的設(shè)置參數(shù)值，可以讓系統(tǒng)更穩(wěn)定高效地運(yùn)行，提升流處理作業(yè)效率。將配置文件作為參數(shù)傳遞給StreamingContext():

val conf=new SparkConf()

.setMaster(url)

.setAppName(String)

.set(String,String

val ssc=new StreamingContext(conf,Seconds(x))

StreamingContext產(chǎn)生DStream，即一段連續(xù)的流數(shù)據(jù)；除了通過接收數(shù)據(jù)源的數(shù)據(jù)產(chǎn)生DStream，也可通過調(diào)用DStream算子，產(chǎn)生新的DStream。產(chǎn)生DStream的時(shí)間間隔通過參數(shù)Seconds(x)指定，x值越大，產(chǎn)生的DStream的時(shí)間就越長，實(shí)時(shí)性越低。通常在實(shí)時(shí)性要求比較高的流處理模型中，x取較小值。

對DStream的操作，可調(diào)用相關(guān)操作算子，常用算子如表3所示。

DStream中包含從數(shù)據(jù)源獲得的數(shù)據(jù)，并封裝為一系列RDD，foreachRDD()函數(shù)可對每個(gè)RDD進(jìn)行操作，格式為：

foreachRDD(func)=>RDD(func)

該算子將DStream內(nèi)部的RDD取出，可存放在文件系統(tǒng)中、或傳送至網(wǎng)絡(luò)、存入數(shù)據(jù)庫。

3.2 依賴分析

通常在進(jìn)行數(shù)據(jù)處理時(shí)，不同的數(shù)據(jù)之間有一定的依賴關(guān)系，這種依賴關(guān)系在Spark里稱為Lineage，也即RDD的依賴關(guān)系，使用有向無環(huán)圖(Directed Acyclic Graph, DAG)來表示。因此，在Spark中，按照Lineage生成DAG,要根據(jù)具體的數(shù)據(jù)處理流程來確定。

RDD有兩種類型的操作算子：Transformation和Action。Transformation類型的操作算子不會(huì)立即執(zhí)行，Action型操作算子會(huì)立即觸發(fā)作業(yè)(Job)。DAG Scheduler將作業(yè)劃分為階段(Stage)，階段包含要執(zhí)行的任務(wù)集合，任務(wù)集合由TaskScheduler分配到節(jié)點(diǎn)上執(zhí)行。劃分階段的依據(jù)是RDD的依賴性，分別如下。

寬依賴(Wide Dependency)：寬依賴指當(dāng)前階段的執(zhí)行，依賴于多個(gè)前一階段的任務(wù)完成。寬依賴如圖2所示。

表3 DStream操作算子Tab. 3 DStream operators

圖2 寬依賴示意圖Fig. 2 Schematic diagram of wide dependency

窄依賴(Narrow Dependency)：當(dāng)前階段任務(wù)的執(zhí)行，只與當(dāng)前任務(wù)的前一階段任務(wù)有關(guān)。窄依賴示意圖如圖3所示。

圖3 窄依賴示意圖Fig. 3 Schematic diagram of narrow dependence

如果當(dāng)前階段要執(zhí)行，需要多個(gè)前階段執(zhí)行完畢；因此，寬依賴是劃分階段的依據(jù)。結(jié)合本文的研究內(nèi)容，分布式視頻轉(zhuǎn)碼流程有以下7個(gè)步驟：1)讀取視頻文件。2)將視頻文件切分為多個(gè)視頻分片。3)保存視頻分片URL至txt文檔。4)txt文檔作為輸入源。5)解析txt文檔中的視頻分片URL。6)合并已轉(zhuǎn)碼視頻分片為視頻文件。7)調(diào)度URL數(shù)據(jù)至Executor執(zhí)行轉(zhuǎn)碼。

分析以上步驟的依賴關(guān)系，按照寬依賴和窄依賴概念劃分階段，可以得到面向流處理的視頻轉(zhuǎn)碼模型依賴關(guān)系圖如圖4所示。

階段1和階段2之間通過GroupByKey將視頻分片合并，有Shuffle過程，該過程有較大網(wǎng)絡(luò)開銷。

3.3 構(gòu)建RDD模型

RDD是Spark分布式處理的關(guān)鍵，也是Spark Streaming的重要環(huán)節(jié)，結(jié)合分布式流處理的視頻轉(zhuǎn)碼特性，合理劃分Partition、Stage、Task，將源視頻文件名稱和視頻分片文件URL組成的〈K，V〉作為要處理的原始數(shù)據(jù)，能有效避免視頻文件因調(diào)度帶來的網(wǎng)絡(luò)開銷和存儲(chǔ)的高I/O。

圖4 面向分布式視頻轉(zhuǎn)碼的DAGFig. 4 DAG for distributed video transcoding

構(gòu)建RDD模型，首先要確定在Spark Streaming中的RDD產(chǎn)生和數(shù)據(jù)原理，通過3.2節(jié)針對視頻轉(zhuǎn)碼的依賴劃分階段，構(gòu)建良好的RDD模型。Spark Streaming的核心是操作RDD，DStream最終要分解為一個(gè)或多個(gè)RDD，即數(shù)據(jù)流的分布式。任務(wù)調(diào)度器(Task Scheduler)是并行化的重要環(huán)節(jié)。在Spark中，從細(xì)粒度到粗粒度劃分，處理單元可分為如下：1)工作線程(Executor)。處理數(shù)據(jù)的最小執(zhí)行單位。2)工作節(jié)點(diǎn)(Worker)。一個(gè)工作節(jié)點(diǎn)為一臺(tái)物理機(jī)器，在一個(gè)工作節(jié)點(diǎn)上，可以運(yùn)行多個(gè)工作線程。

工作線程是執(zhí)行處理工作的最小單位，從細(xì)粒度到粗粒度劃分，要處理的業(yè)務(wù)對象可分為如下：1)任務(wù)(Task)。工作線程要處理的最小工作單位，包含一系列處理方法和數(shù)據(jù)分區(qū)(Partition)。2)階段(Stage)。一個(gè)任務(wù)集，階段按照寬依賴和窄依賴劃分；包含一系列寬窄依賴關(guān)系的RDD，如圖5所示。

圖5 RDD業(yè)務(wù)分層調(diào)度模型Fig. 5 Hierarchical scheduling model for RDD business

結(jié)合本文的研究工作，按照數(shù)據(jù)粒度從細(xì)到粗劃分，有以下數(shù)據(jù)對象：

1)分區(qū)(Partition)：最小的數(shù)據(jù)單位。結(jié)合本文研究內(nèi)容，將分區(qū)定義為一條〈視頻名 分片名〉文本記錄。

2)RDD(彈性分布式數(shù)據(jù)集)：RDD中定義了多種數(shù)據(jù)處理方式，即操作算子。結(jié)合本文研究內(nèi)容，將RDD定義為包含多個(gè)〈視頻名 分片名〉記錄，以及對這些記錄的處理方法。

3)DStream(離散數(shù)據(jù)流)：DStream包含多個(gè)RDD，按照設(shè)定的單位時(shí)間不斷產(chǎn)生。在本文中，產(chǎn)生DStream的數(shù)據(jù)源是包含〈視頻名 分片URL〉記錄的txt文檔。

以上分別對處理單元、業(yè)務(wù)對象、數(shù)據(jù)對象按照粒度由小到大進(jìn)行區(qū)分，并結(jié)合本文研究內(nèi)容，將包含視頻分片信息的文本文檔作為數(shù)據(jù)源，〈視頻名 分片URL〉為最小數(shù)據(jù)單元。將以上內(nèi)容結(jié)合3.2節(jié)的依賴分析，可得基于視頻分片的RDD數(shù)據(jù)流圖，如圖6所示。

圖6 RDD數(shù)據(jù)流圖Fig. 6 RDD data stream diagram

根據(jù)數(shù)據(jù)流圖，可建立RDD編程模型，偽代碼如算法2所示。

算法2 RDD編程模型。

輸入 DStream；

輸出 視頻分片URL。

BEGIN

DStream.foreachRDD

rdd←從DStream中取得一個(gè)RDD

IF(RDD不為空)

rdd1←rdd.map(x=>x.split("")(1))

item←從rdd中取得一個(gè)元素

rdd1.foreach

url←從rdd1中取得一個(gè)元素

調(diào)用轉(zhuǎn)碼命令:ffmpeg -i url -c:v libvpx-vp9 output.webm

將output.webm移動(dòng)至HDFS分片目錄中

END foreach

END IF

END foreach RDD

數(shù)據(jù)源輸出的是一條文本記錄，該記錄則為RDD中的一個(gè)基本元素，格式為：

視頻文件名[空格]視頻分片文件URL

RDD調(diào)用map算子進(jìn)行轉(zhuǎn)換生成RDD1，通過對RDD1進(jìn)行foreach()運(yùn)算，得到RDD1中的記錄是一條視頻分片文件URL。

3.4 視頻分片文件合并模型

根據(jù)流處理的特性，數(shù)據(jù)持續(xù)地產(chǎn)生和處理，因此要對舊的文件和緩存進(jìn)行清理，防止因空間不足而導(dǎo)致系統(tǒng)不穩(wěn)定。視頻的合并要按照視頻分片的先后次序進(jìn)行，在分布式轉(zhuǎn)碼過程中，無法保證視頻按照先后順序依次轉(zhuǎn)碼；因此，需要等待視頻文件的所有分片都轉(zhuǎn)碼完成后，再進(jìn)行合并。視頻合并偽代碼如算法3所示。

算法3 流處理視頻合并。

輸入 視頻名稱，分片URL列表；

輸出 完整視頻文件。

BEGIN

key←視頻名稱;values←分片URL列表;output←完整視頻輸出文件

新建文本concatFile←對values進(jìn)行排序

//運(yùn)行合并命令

ffmpeg -f concat -safe 0 -i concatFile -c copy output

上傳output到HDFS

END

concatFile文本文件中的分片在時(shí)間上是有序的，否則會(huì)導(dǎo)致視頻內(nèi)容錯(cuò)亂。

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

4.1 系統(tǒng)部署

基于本文所提出的快速視頻轉(zhuǎn)碼方法，設(shè)計(jì)和實(shí)現(xiàn)了快速視頻轉(zhuǎn)碼原型系統(tǒng)。該原型系統(tǒng)部署在四川師范大學(xué)云計(jì)算實(shí)驗(yàn)室私有云平臺(tái)，該云平臺(tái)提供了友好的彈性虛擬機(jī)管理界面，通過管理界面可以對目標(biāo)虛擬機(jī)進(jìn)行復(fù)制創(chuàng)建，可短時(shí)間按需創(chuàng)建包含一定數(shù)量節(jié)點(diǎn)的同構(gòu)集群環(huán)境；同時(shí)，根據(jù)不同的需求，可彈性擴(kuò)展虛擬機(jī)硬件配置，這極大地方便了實(shí)驗(yàn)的開展。

4.2 運(yùn)行環(huán)境

4.2.1 硬件環(huán)境

Master節(jié)點(diǎn)需要運(yùn)行HDFS的NameNode進(jìn)程、Spark的Master進(jìn)程。該節(jié)點(diǎn)出現(xiàn)故障會(huì)對集群造成災(zāi)難性影響，因此該節(jié)點(diǎn)配置較大內(nèi)存和較多核CPU。

SplitServer節(jié)點(diǎn)的主要工作是將視頻切分，切分工作實(shí)際上是將音視頻數(shù)據(jù)按照輸入?yún)?shù)復(fù)制并保存為音視頻數(shù)據(jù)塊。復(fù)制為多個(gè)小塊的過程比轉(zhuǎn)碼所需要的CPU運(yùn)算力要低得多；因此，切分過程由一個(gè)節(jié)點(diǎn)完成即可，為了應(yīng)對較大的視頻文件存儲(chǔ)問題，切分節(jié)點(diǎn)SplitServer除了配置與Master節(jié)點(diǎn)相同的CPU和內(nèi)存外，磁盤容量提升至100 GB。在實(shí)驗(yàn)中將SplitServer也視為數(shù)據(jù)源。

MergeServer工作與SplitServer相反，把轉(zhuǎn)碼后的視頻切片，有序合并成一個(gè)視頻文件，再上傳至HDFS保存。MergeServer的輸入數(shù)據(jù)是有序的、完整的、已經(jīng)轉(zhuǎn)碼的視頻分片。

Slave節(jié)點(diǎn)，即運(yùn)行HDFS的Datanode節(jié)點(diǎn)、Spark Streaming的Work節(jié)點(diǎn)，是分布式存儲(chǔ)、分布式轉(zhuǎn)碼工作的主要執(zhí)行節(jié)點(diǎn)。Slave節(jié)點(diǎn)初始配置4核心CPU、8 GB內(nèi)存、40 GB存儲(chǔ)；初始數(shù)量20個(gè)，可根據(jù)實(shí)驗(yàn)要求，在云管理后臺(tái)進(jìn)行彈性配置。詳細(xì)配置如表4所示。

表4 系統(tǒng)部署硬件配置Tab. 4 System deployment hardware configuration

4.2.2 軟件環(huán)境

本文系統(tǒng)所有軟件運(yùn)行在Linux平臺(tái)，私有云提供了64位CentOS 6.1操作系統(tǒng)，經(jīng)測試，本文系統(tǒng)所需要的軟件都能正常穩(wěn)定地運(yùn)行在64位CentOS 6.1系統(tǒng)中。軟件詳細(xì)參數(shù)如表5所示。

表5 系統(tǒng)部署軟件環(huán)境Tab. 5 System deployment software environment

根據(jù)節(jié)點(diǎn)信息，繪制節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)鋱D，如圖7所示。

圖7 節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)銯ig. 7 Node network topology

Master節(jié)點(diǎn)與Slave節(jié)點(diǎn)配置文件基本一致。通過配置一個(gè)初始節(jié)點(diǎn)，再通過私有云Web管理后臺(tái)對該節(jié)點(diǎn)進(jìn)行復(fù)制、重新分配網(wǎng)卡MAC、重新分配IP的方式快速創(chuàng)建其他節(jié)點(diǎn)。

Hadoop配置目錄中的slaves文件指定集群由哪些節(jié)點(diǎn)組成，每行分別填寫節(jié)點(diǎn)名“slave1”至“slave20”，由20個(gè)節(jié)點(diǎn)組成slaves集群。

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

本節(jié)實(shí)驗(yàn)對象選取3個(gè)不同編碼的視頻文件。根據(jù)具體實(shí)驗(yàn)，選取相應(yīng)視頻文件進(jìn)行實(shí)驗(yàn)分析，因視頻文件通常帶有較多參數(shù)信息，不同的參數(shù)會(huì)在解碼和編碼過程中，對視頻文件產(chǎn)生不同的損益。視頻文件的主要參數(shù)如表6所示。

表6 實(shí)驗(yàn)視頻對象信息表Tab. 6 Experimental video object informationTable

4.3.1 視頻分片大小實(shí)驗(yàn)與分析

SplitServer切分的視頻分片保存在HDFS中，切分依據(jù)為時(shí)間長度(單位為ms)；通過不同的時(shí)長產(chǎn)生不同大小的視頻分片文件。HDFS默認(rèn)塊大小128 MB，視頻分片大小根據(jù)視頻文件的格式、碼率、分辨率的不同而有差異。本實(shí)驗(yàn)分別設(shè)置不同時(shí)長，分析不同大小的視頻分片的轉(zhuǎn)碼效率。視頻分片大小對轉(zhuǎn)碼效率的影響如圖8所示。

圖8 視頻分片大小對轉(zhuǎn)碼效率的影響Fig. 8 Effect of video fragment size on transcoding efficiency

由圖8可知，在視頻分片大小為128 MB時(shí)，可得到最高轉(zhuǎn)碼效率，即當(dāng)文件越來越接近HDFS塊文件時(shí)，網(wǎng)絡(luò)開銷越??；當(dāng)文件大于HDFS塊大小時(shí)，需要從多個(gè)節(jié)點(diǎn)的多個(gè)塊中讀取數(shù)據(jù)，網(wǎng)絡(luò)開銷增大，任務(wù)處理時(shí)間變長。

4.3.2 流處理產(chǎn)生DStream時(shí)長實(shí)驗(yàn)與分析

Spark Streaming依據(jù)StreamContext()設(shè)置的參數(shù)產(chǎn)生DStream，本實(shí)驗(yàn)分別設(shè)置不同時(shí)長，分析相應(yīng)的轉(zhuǎn)碼效率。DStream產(chǎn)生間隔對轉(zhuǎn)碼效率的影響如圖9所示。

圖9 DStream產(chǎn)生間隔對轉(zhuǎn)碼效率的影響Fig. 9 Effect of DStream production interval on transcoding efficiency

由圖9可知，隨著時(shí)間間隔的增大，轉(zhuǎn)碼效率逐漸提高，在時(shí)間間隔為5 s時(shí)，可得最高轉(zhuǎn)碼效率，然后隨著時(shí)間間隔增大，效率逐漸變低，并且逐漸穩(wěn)定在20 min。太短的時(shí)間間隔會(huì)產(chǎn)生冗余的空作業(yè)，減少空作業(yè)是優(yōu)化的一個(gè)方向；時(shí)間間隔增長時(shí)，因硬件配置的限制，集群性能無法應(yīng)對短時(shí)間的大量轉(zhuǎn)碼作業(yè)，造成作業(yè)積壓，根據(jù)調(diào)度算法，將處理作業(yè)加入隊(duì)列，流處理的實(shí)時(shí)性降低。

4.3.3 視頻不同編碼互轉(zhuǎn)實(shí)驗(yàn)與分析

本實(shí)驗(yàn)對常見的視頻編碼之間的相互轉(zhuǎn)換進(jìn)行分析，封裝格式為MKV。實(shí)驗(yàn)對象如表6中A.mkv所示。

本實(shí)驗(yàn)選取3種常見的視頻編碼進(jìn)行互轉(zhuǎn)碼實(shí)驗(yàn)，為了結(jié)果的準(zhǔn)確有效，使用控制變量法，對A.mkv進(jìn)行轉(zhuǎn)碼時(shí)，除編碼方法外，其他參數(shù)不作調(diào)整,如表7所示。

表7 編碼相互轉(zhuǎn)換設(shè)計(jì)Tab. 7 Coding mutual conversion design

因?yàn)橄嗤幋a的視頻轉(zhuǎn)碼實(shí)際上是將原來的數(shù)據(jù)進(jìn)行復(fù)制，沒有進(jìn)行解碼、重編碼工作；所以對相同視頻轉(zhuǎn)碼的轉(zhuǎn)換時(shí)間開銷設(shè)置為“1”。對表6中的視頻文件進(jìn)行不同編碼的轉(zhuǎn)制，不同視頻編碼的轉(zhuǎn)碼效率如圖10所示。

圖10 不同視頻編碼的轉(zhuǎn)碼效率Fig. 10 Transcoding efficiency of different video encoding

實(shí)驗(yàn)結(jié)果表明，不同的編碼之間進(jìn)行轉(zhuǎn)換效率差異很大。不同的視頻編碼，有不同的編碼算法。設(shè)有A、B視頻文件分別用A1、B1編碼算法進(jìn)行編碼。視頻轉(zhuǎn)碼的流程如圖1，原理是首先將A視頻按照A1算法進(jìn)行解碼，得到視頻幀，將視頻幀按照B2進(jìn)行編碼，得到B視頻。因此，不同的視頻編碼因?yàn)樗惴ǖ牟煌?，效率也不同?/p>

4.3.4 源視頻與切片時(shí)長關(guān)系實(shí)驗(yàn)

通常碼率越大、分辨率越高的視頻占用的空間也會(huì)越大。通過對不同大小的源視頻進(jìn)行不同方式的切片實(shí)驗(yàn)，有助于發(fā)現(xiàn)最高效的切分方法。本實(shí)驗(yàn)對源視頻大小/切片大小進(jìn)行實(shí)驗(yàn)，為了避免相同視頻編碼方法的相互轉(zhuǎn)換，本實(shí)驗(yàn)的目標(biāo)視頻編碼為MPEG-4，封裝格式為avi。不同時(shí)間長度的視頻文件轉(zhuǎn)碼效率如圖11所示。

圖11 不同時(shí)間長度的視頻文件轉(zhuǎn)碼效率Fig. 11 Video file transcoding efficiency with different time lengths

由圖11分析可知，源視頻的參數(shù)不同，切分的視頻分片大小不同，轉(zhuǎn)碼效率也不同。

4.3.5 節(jié)點(diǎn)/CPU核心數(shù)量對轉(zhuǎn)碼效率的影響

1)節(jié)點(diǎn)數(shù)量-轉(zhuǎn)碼效率。

通過對集群節(jié)點(diǎn)數(shù)量進(jìn)行調(diào)整，發(fā)現(xiàn)節(jié)點(diǎn)數(shù)量與轉(zhuǎn)碼效率的關(guān)系。本實(shí)驗(yàn)共啟用20個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)分配1個(gè)CPU核心。起始節(jié)點(diǎn)數(shù)量從2開始，依次遞增1。實(shí)驗(yàn)對象為A.mkv、B.avi、C.mp4，三個(gè)視頻文件不分次序轉(zhuǎn)碼為flv格式，編碼為H.264，10次實(shí)驗(yàn)后取均值，結(jié)果如圖12所示。

圖12 集群節(jié)點(diǎn)數(shù)量對轉(zhuǎn)碼效率的影響Fig. 12 Effect of number of cluster nodes on transcoding efficiency

由圖12可以看出，隨著節(jié)點(diǎn)的增加、集群計(jì)算能力的增強(qiáng)，視頻轉(zhuǎn)碼消耗的時(shí)間不斷減少。在分布式系統(tǒng)中，節(jié)點(diǎn)的增加也意味著分布率的提升。在Spark Streaming中，同一個(gè)節(jié)點(diǎn)，可能同時(shí)運(yùn)行著多個(gè)CPU核心。在節(jié)點(diǎn)數(shù)量為11時(shí)，轉(zhuǎn)碼效率沒有進(jìn)一步提升，隨著節(jié)點(diǎn)數(shù)量的增加，三個(gè)視頻文件的轉(zhuǎn)碼總時(shí)間在27 min左右。該實(shí)驗(yàn)結(jié)果表明，當(dāng)集群節(jié)點(diǎn)達(dá)到一定規(guī)模、轉(zhuǎn)碼任務(wù)不變的情況下，隨著集群節(jié)點(diǎn)的增加，并不能帶來效率的繼續(xù)提升。通過查看日志發(fā)現(xiàn)，部分節(jié)點(diǎn)并沒有執(zhí)行轉(zhuǎn)碼任務(wù)，處于空置狀態(tài)。

2)CPU核心數(shù)量-轉(zhuǎn)碼效率。

本實(shí)驗(yàn)通過更改Spark Shell程序提交參數(shù)，完成對CPU核心數(shù)量的關(guān)閉/啟用，命令格式如下：

spark-submit --master spark:master:7 077 --spark.cores.maxNa.jar

將N取1～10。實(shí)驗(yàn)對象為A.mkv、B.avi、C.mp4，三個(gè)視頻文件不分次序轉(zhuǎn)碼為flv格式，編碼為H.264，10次實(shí)驗(yàn)后取均值，得到運(yùn)行結(jié)果如圖13所示。

圖13 集群CPU核心總數(shù)量對轉(zhuǎn)碼效率的影響Fig. 13 Effect of total number of cluster CPU cores on transcoding efficiency

集群使用的CPU總核心數(shù)量越多，視頻轉(zhuǎn)碼消耗的時(shí)間越小，轉(zhuǎn)碼效率越高，至18個(gè)時(shí)，效率沒有隨著核心數(shù)的增多而提升，這與增加集群節(jié)點(diǎn)數(shù)量的趨勢大致相同。進(jìn)一步研究節(jié)點(diǎn)數(shù)量與集群CPU總核心數(shù)量之間的轉(zhuǎn)碼差異，結(jié)果如圖14所示。

圖14 不同集群總CPU/核心數(shù)量的轉(zhuǎn)碼效率對比Fig. 14 Transcoding efficiency comparison of of different cluster total CPUs/cores

從圖14中可以看出，隨著集群節(jié)點(diǎn)數(shù)量與集群CPU總核心數(shù)量的增多，視頻轉(zhuǎn)碼效率在不斷地提升；但當(dāng)集群總節(jié)點(diǎn)數(shù)與CPU總核心數(shù)為8個(gè)時(shí)，兩者轉(zhuǎn)碼用時(shí)相同；繼續(xù)增加CPU核心數(shù)量和節(jié)點(diǎn)數(shù)量，CPU核心數(shù)量的增加能帶來更高的效率。集群節(jié)點(diǎn)數(shù)在12個(gè)時(shí)，達(dá)到最大轉(zhuǎn)碼效率；CPU總核心在集群節(jié)點(diǎn)數(shù)為18個(gè)時(shí)達(dá)到最大轉(zhuǎn)碼效率。結(jié)合Spark調(diào)度原理，可進(jìn)一步分析出現(xiàn)這種差異是因?yàn)檎{(diào)度管理器會(huì)優(yōu)先將作業(yè)交給已經(jīng)存儲(chǔ)有視頻分片的節(jié)點(diǎn)進(jìn)行處理，從而降低數(shù)據(jù)在集群中傳輸帶來的網(wǎng)絡(luò)開銷。

4.3.6 不同平臺(tái)實(shí)現(xiàn)的視頻轉(zhuǎn)碼系統(tǒng)對照實(shí)驗(yàn)

目前使用Hadoop實(shí)現(xiàn)的分布式視頻轉(zhuǎn)碼方法很多，相關(guān)學(xué)術(shù)研究資料豐富，視頻轉(zhuǎn)碼方案也很成熟。本文對文獻(xiàn)[15]、文獻(xiàn)[19]、文獻(xiàn)[20]的Hadoop的分布式轉(zhuǎn)碼方案進(jìn)行了研究；改進(jìn)了需要手工進(jìn)行視頻分片的問題，進(jìn)一步實(shí)現(xiàn)了一套基于Hadoop的分布式視頻轉(zhuǎn)碼系統(tǒng)。因?yàn)镾park Streaming與Hadoop有良好的兼容性，所以兩者可在相同的硬件環(huán)境中運(yùn)行，因此，可認(rèn)為基于Hadoop分布式的視頻轉(zhuǎn)碼方案與基于Spark Streaming的分布式流處理視頻轉(zhuǎn)碼方案有相同的硬件和軟件環(huán)境。通過對三個(gè)不同的視頻文件進(jìn)行轉(zhuǎn)碼，探索基于Spark Streaming實(shí)現(xiàn)的轉(zhuǎn)碼系統(tǒng)與基于Hadoop實(shí)現(xiàn)的視頻轉(zhuǎn)碼系統(tǒng)中的效率問題。實(shí)驗(yàn)對象信息如表6所示。

分別使用基于Hadoop實(shí)現(xiàn)的分布式轉(zhuǎn)碼系統(tǒng)和基于Spark Streaming實(shí)現(xiàn)的分布式流處理轉(zhuǎn)碼系統(tǒng)對A.mkv、B.avi、C.mp4進(jìn)行目標(biāo)編碼方法為MPEG-4的轉(zhuǎn)碼。通過10次實(shí)驗(yàn)，每項(xiàng)結(jié)果取平均值，結(jié)果如圖15所示。

圖15 Hadoop與Spark Streaming分布式轉(zhuǎn)碼系統(tǒng)效率對比Fig. 15 Efficiency comparison between Hadoop and Spark Streaming distributed transcoding systems

通過圖15可以得出，基于Spark Streaming實(shí)現(xiàn)的分布式流處理視頻轉(zhuǎn)碼系統(tǒng)比基于Hadoop實(shí)現(xiàn)的分布式轉(zhuǎn)碼系統(tǒng)的轉(zhuǎn)碼效率提升了26.7%。理論分析結(jié)果表明，在視頻文件切分到視頻分片轉(zhuǎn)碼環(huán)節(jié)，不需要視頻文件全部切分完成即可進(jìn)行轉(zhuǎn)碼工作，通過Spark構(gòu)建的DAG任務(wù)模型節(jié)省了這部分的時(shí)間開銷，提升了轉(zhuǎn)碼效率。

4.3.7 與文獻(xiàn)[19]的視頻轉(zhuǎn)碼方法對照實(shí)驗(yàn)

本文按照文獻(xiàn)[19]提出的基于Hadoop平臺(tái)的視頻并行轉(zhuǎn)碼方法，實(shí)現(xiàn)了一種基于Hadoop的視頻轉(zhuǎn)碼系統(tǒng)，與基于本文所提出視頻轉(zhuǎn)碼方法實(shí)現(xiàn)的原型系統(tǒng)進(jìn)行對比實(shí)驗(yàn)。實(shí)驗(yàn)硬件配置為4個(gè)節(jié)點(diǎn)(CPU為雙核1 GHz、內(nèi)存為16 GB)，通過四川師范大學(xué)私有云快速創(chuàng)建與該硬件參數(shù)相近的節(jié)點(diǎn)。實(shí)驗(yàn)選取了三個(gè)視頻文件作為實(shí)驗(yàn)對象[19]，參數(shù)如表8所示。

表8 視頻文件信息Tab. 8 Video file information

表8中的實(shí)驗(yàn)對象通過FFmpeg對一段視頻進(jìn)行處理生成,實(shí)驗(yàn)規(guī)定了視頻轉(zhuǎn)碼后的目標(biāo)參數(shù)[19]，如表9所示。

表9 視頻轉(zhuǎn)碼參數(shù)Tab. 9 Video transcoding parameters

針對同一視頻進(jìn)行了10次實(shí)驗(yàn)，取平均轉(zhuǎn)碼時(shí)間,實(shí)驗(yàn)結(jié)果對比如圖16所示。

圖16 不同方案的轉(zhuǎn)碼效率對比Fig. 16 Transcoding efficiency comparison of different schemes

和文獻(xiàn)[19]的方法相比，本文方法對Video1的轉(zhuǎn)碼效率提升21%，對Video2的轉(zhuǎn)碼效率提升了19.7%，對Video3的轉(zhuǎn)碼效率提升了19.6%；三個(gè)視頻的平均效率提升了20.1%。對比實(shí)驗(yàn)結(jié)果表明，本文提出的視頻轉(zhuǎn)碼方法較文獻(xiàn)[19]方法效率顯著提高。

5 結(jié) 語

現(xiàn)有的單機(jī)視頻轉(zhuǎn)碼方法存在的轉(zhuǎn)碼速度較慢、瓶頸等問題給用戶帶來較差體驗(yàn)；現(xiàn)有的基于Hadoop的并行轉(zhuǎn)碼方法比傳統(tǒng)單機(jī)轉(zhuǎn)碼在轉(zhuǎn)碼速度上有較大提升，但其面向批處理的特點(diǎn)決定了轉(zhuǎn)碼過程存在較多等待時(shí)間，使得轉(zhuǎn)碼效率提升不夠充分。為此，將Spark Streaming引入到視頻轉(zhuǎn)碼的設(shè)計(jì)之中，提出了一種面向流處理的基于并行計(jì)算的快速視頻轉(zhuǎn)碼方法。實(shí)驗(yàn)表明，所提出的基于Spark Streaming的視頻轉(zhuǎn)碼方法在轉(zhuǎn)碼效率上有顯著提升。本文所提方法也有不足，即當(dāng)任務(wù)量太大時(shí)，集群超負(fù)荷工作，也會(huì)形成隊(duì)列工作。同時(shí)，本文采用Fair調(diào)度算法，沒有針對視頻流的特點(diǎn)進(jìn)行算法上的改進(jìn)。因此在使用分布式流處理技術(shù)進(jìn)行的視頻轉(zhuǎn)碼工作，仍有很大的改進(jìn)空間。