基于Spark Streaming的快速視頻轉碼方法

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

(1.四川師范大學 計算機科學學院,成都 610101； 2.可視化計算與虛擬現實四川省重點實驗室(四川師范大學),成都 610101； 3.四川師大科技園發展有限公司,成都 610066)(*通信作者電子郵箱fymen@naver.com)

0 引言

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

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

本文根據視頻轉碼特點，采用分布式流處理技術，提出一種基于Spark Streaming的快速視頻轉碼方法。本文分析了傳統的單機轉碼方法和基于Hadoop的視頻轉碼方法，改進了視頻切割的流程；并減少了批處理轉碼方式中大量等待時間。實驗結果表明，本文提出的轉碼方法顯著提升了轉碼效率。

1 相關工作

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

不同的視頻編碼方法有不同的使用場景，根據需要將視頻編碼進行轉換是不可或缺的工作。傳統視頻轉碼方法是使用單機進行轉碼工作，但在處理大量視頻資源時會有三種情況產生：1)多個視頻文件進行轉碼時，通常會按序進入轉碼隊列；單機在處理長隊列視頻轉碼工作十分耗時。2)某個視頻轉碼工作出現問題，后續工作停止，需要人工值守。3)不具備并發視頻轉碼能力。

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

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

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

2 關鍵技術

2.1 FFmpeg多媒體框架

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

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

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

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

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

2.2 Spark Streaming流處理框架

Spark是目前流行的分布式框架之一，其核心由一組功能強大的擴展庫組成。目前這些庫包括SparkSQL、Spark Streaming、MLlib以及GraphX，其他一些Spark庫和擴展也在陸續開發中。Spark Streaming是Spark的組件之一，主要功能是實現流處理。

3 構建視頻轉碼模型

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

3.1 Spark Streaming數據源設計

Spark Streaming運行時，需要持續不斷地獲得輸入數據。一般視頻文件都會有較大體積，視頻文件在集群網絡中傳輸，會加重網絡開銷，降低系統效率，因此通過將完整的視頻文件進行切片處理，把切分的視頻分片路徑作為文本輸入數據，減輕了集群網絡傳輸負擔。要設計持續穩定的數據源，同時視頻分片粒度的大小保持一致，需要穩定性良好的硬件環境和程序設計。

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

(1)

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

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

輸入 視頻文件；

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

BEGIN

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

WHILE(true)

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

FOR(f:vList)

SumTime←獲取視頻總時長;

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

通過監控上傳目錄raw_video，當有視頻文件上傳完成，對該視頻文件進行分片,并將分片文件URL作為數據源。

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

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

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

1)創建配置文件。

StreamingContext配置代碼格式如下：

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

set(String,String)

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

表2 StreamingContext 配置參數Tab. 2 StreamingContext configuration parameters

2)參數傳遞。

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

val conf=new SparkConf()

.setMaster(url)

.setAppName(String)

.set(String,String

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

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

對DStream的操作，可調用相關操作算子，常用算子如表3所示。

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

foreachRDD(func)=>RDD(func)

該算子將DStream內部的RDD取出，可存放在文件系統中、或傳送至網絡、存入數據庫。

3.2 依賴分析

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

RDD有兩種類型的操作算子：Transformation和Action。Transformation類型的操作算子不會立即執行，Action型操作算子會立即觸發作業(Job)。DAG Scheduler將作業劃分為階段(Stage)，階段包含要執行的任務集合，任務集合由TaskScheduler分配到節點上執行。劃分階段的依據是RDD的依賴性，分別如下。

寬依賴(Wide Dependency)：寬依賴指當前階段的執行，依賴于多個前一階段的任務完成。寬依賴如圖2所示。

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

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

窄依賴(Narrow Dependency)：當前階段任務的執行，只與當前任務的前一階段任務有關。窄依賴示意圖如圖3所示。

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

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

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

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

3.3 構建RDD模型

RDD是Spark分布式處理的關鍵，也是Spark Streaming的重要環節，結合分布式流處理的視頻轉碼特性，合理劃分Partition、Stage、Task，將源視頻文件名稱和視頻分片文件URL組成的〈K，V〉作為要處理的原始數據，能有效避免視頻文件因調度帶來的網絡開銷和存儲的高I/O。

圖4 面向分布式視頻轉碼的DAGFig. 4 DAG for distributed video transcoding

構建RDD模型，首先要確定在Spark Streaming中的RDD產生和數據原理，通過3.2節針對視頻轉碼的依賴劃分階段，構建良好的RDD模型。Spark Streaming的核心是操作RDD，DStream最終要分解為一個或多個RDD，即數據流的分布式。任務調度器(Task Scheduler)是并行化的重要環節。在Spark中，從細粒度到粗粒度劃分，處理單元可分為如下：1)工作線程(Executor)。處理數據的最小執行單位。2)工作節點(Worker)。一個工作節點為一臺物理機器，在一個工作節點上，可以運行多個工作線程。

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

圖5 RDD業務分層調度模型Fig. 5 Hierarchical scheduling model for RDD business

結合本文的研究工作，按照數據粒度從細到粗劃分，有以下數據對象：

1)分區(Partition)：最小的數據單位。結合本文研究內容，將分區定義為一條〈視頻名 分片名〉文本記錄。

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

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

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

圖6 RDD數據流圖Fig. 6 RDD data stream diagram

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

算法2 RDD編程模型。

輸入 DStream；

輸出 視頻分片URL。

BEGIN

DStream.foreachRDD

rdd←從DStream中取得一個RDD

IF(RDD不為空)

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

item←從rdd中取得一個元素

rdd1.foreach

url←從rdd1中取得一個元素

調用轉碼命令:ffmpeg -i url -c:v libvpx-vp9 output.webm

將output.webm移動至HDFS分片目錄中

END foreach

END IF

END foreach RDD

數據源輸出的是一條文本記錄，該記錄則為RDD中的一個基本元素，格式為：

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

RDD調用map算子進行轉換生成RDD1，通過對RDD1進行foreach()運算，得到RDD1中的記錄是一條視頻分片文件URL。

3.4 視頻分片文件合并模型

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

算法3 流處理視頻合并。

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

輸出 完整視頻文件。

BEGIN

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

新建文本concatFile←對values進行排序

//運行合并命令

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

上傳output到HDFS

END

concatFile文本文件中的分片在時間上是有序的，否則會導致視頻內容錯亂。

4 實驗結果與分析

4.1 系統部署

基于本文所提出的快速視頻轉碼方法，設計和實現了快速視頻轉碼原型系統。該原型系統部署在四川師范大學云計算實驗室私有云平臺，該云平臺提供了友好的彈性虛擬機管理界面，通過管理界面可以對目標虛擬機進行復制創建，可短時間按需創建包含一定數量節點的同構集群環境；同時，根據不同的需求，可彈性擴展虛擬機硬件配置，這極大地方便了實驗的開展。

4.2 運行環境

4.2.1 硬件環境

Master節點需要運行HDFS的NameNode進程、Spark的Master進程。該節點出現故障會對集群造成災難性影響，因此該節點配置較大內存和較多核CPU。

SplitServer節點的主要工作是將視頻切分，切分工作實際上是將音視頻數據按照輸入參數復制并保存為音視頻數據塊。復制為多個小塊的過程比轉碼所需要的CPU運算力要低得多；因此，切分過程由一個節點完成即可，為了應對較大的視頻文件存儲問題，切分節點SplitServer除了配置與Master節點相同的CPU和內存外，磁盤容量提升至100 GB。在實驗中將SplitServer也視為數據源。

MergeServer工作與SplitServer相反，把轉碼后的視頻切片，有序合并成一個視頻文件，再上傳至HDFS保存。MergeServer的輸入數據是有序的、完整的、已經轉碼的視頻分片。

Slave節點，即運行HDFS的Datanode節點、Spark Streaming的Work節點，是分布式存儲、分布式轉碼工作的主要執行節點。Slave節點初始配置4核心CPU、8 GB內存、40 GB存儲；初始數量20個，可根據實驗要求，在云管理后臺進行彈性配置。詳細配置如表4所示。

表4 系統部署硬件配置Tab. 4 System deployment hardware configuration

4.2.2 軟件環境

本文系統所有軟件運行在Linux平臺，私有云提供了64位CentOS 6.1操作系統，經測試，本文系統所需要的軟件都能正常穩定地運行在64位CentOS 6.1系統中。軟件詳細參數如表5所示。

表5 系統部署軟件環境Tab. 5 System deployment software environment

根據節點信息，繪制節點網絡拓撲圖，如圖7所示。

圖7 節點網絡拓撲Fig. 7 Node network topology

Master節點與Slave節點配置文件基本一致。通過配置一個初始節點，再通過私有云Web管理后臺對該節點進行復制、重新分配網卡MAC、重新分配IP的方式快速創建其他節點。

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

4.3 實驗結果與分析

本節實驗對象選取3個不同編碼的視頻文件。根據具體實驗，選取相應視頻文件進行實驗分析，因視頻文件通常帶有較多參數信息，不同的參數會在解碼和編碼過程中，對視頻文件產生不同的損益。視頻文件的主要參數如表6所示。

表6 實驗視頻對象信息表Tab. 6 Experimental video object informationTable

4.3.1 視頻分片大小實驗與分析

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

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

由圖8可知，在視頻分片大小為128 MB時，可得到最高轉碼效率，即當文件越來越接近HDFS塊文件時，網絡開銷越??；當文件大于HDFS塊大小時，需要從多個節點的多個塊中讀取數據，網絡開銷增大，任務處理時間變長。

4.3.2 流處理產生DStream時長實驗與分析

Spark Streaming依據StreamContext()設置的參數產生DStream，本實驗分別設置不同時長，分析相應的轉碼效率。DStream產生間隔對轉碼效率的影響如圖9所示。

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

由圖9可知，隨著時間間隔的增大，轉碼效率逐漸提高，在時間間隔為5 s時，可得最高轉碼效率，然后隨著時間間隔增大，效率逐漸變低，并且逐漸穩定在20 min。太短的時間間隔會產生冗余的空作業，減少空作業是優化的一個方向；時間間隔增長時，因硬件配置的限制，集群性能無法應對短時間的大量轉碼作業，造成作業積壓，根據調度算法，將處理作業加入隊列，流處理的實時性降低。

4.3.3 視頻不同編碼互轉實驗與分析

本實驗對常見的視頻編碼之間的相互轉換進行分析，封裝格式為MKV。實驗對象如表6中A.mkv所示。

本實驗選取3種常見的視頻編碼進行互轉碼實驗，為了結果的準確有效，使用控制變量法，對A.mkv進行轉碼時，除編碼方法外，其他參數不作調整,如表7所示。

表7 編碼相互轉換設計Tab. 7 Coding mutual conversion design

因為相同編碼的視頻轉碼實際上是將原來的數據進行復制，沒有進行解碼、重編碼工作；所以對相同視頻轉碼的轉換時間開銷設置為“1”。對表6中的視頻文件進行不同編碼的轉制，不同視頻編碼的轉碼效率如圖10所示。

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

實驗結果表明，不同的編碼之間進行轉換效率差異很大。不同的視頻編碼，有不同的編碼算法。設有A、B視頻文件分別用A1、B1編碼算法進行編碼。視頻轉碼的流程如圖1，原理是首先將A視頻按照A1算法進行解碼，得到視頻幀，將視頻幀按照B2進行編碼，得到B視頻。因此，不同的視頻編碼因為算法的不同，效率也不同。

4.3.4 源視頻與切片時長關系實驗

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

圖11 不同時間長度的視頻文件轉碼效率Fig. 11 Video file transcoding efficiency with different time lengths

由圖11分析可知，源視頻的參數不同，切分的視頻分片大小不同，轉碼效率也不同。

4.3.5 節點/CPU核心數量對轉碼效率的影響

1)節點數量-轉碼效率。

通過對集群節點數量進行調整，發現節點數量與轉碼效率的關系。本實驗共啟用20個節點，每個節點分配1個CPU核心。起始節點數量從2開始，依次遞增1。實驗對象為A.mkv、B.avi、C.mp4，三個視頻文件不分次序轉碼為flv格式，編碼為H.264，10次實驗后取均值，結果如圖12所示。

圖12 集群節點數量對轉碼效率的影響Fig. 12 Effect of number of cluster nodes on transcoding efficiency

由圖12可以看出，隨著節點的增加、集群計算能力的增強，視頻轉碼消耗的時間不斷減少。在分布式系統中，節點的增加也意味著分布率的提升。在Spark Streaming中，同一個節點，可能同時運行著多個CPU核心。在節點數量為11時，轉碼效率沒有進一步提升，隨著節點數量的增加，三個視頻文件的轉碼總時間在27 min左右。該實驗結果表明，當集群節點達到一定規模、轉碼任務不變的情況下，隨著集群節點的增加，并不能帶來效率的繼續提升。通過查看日志發現，部分節點并沒有執行轉碼任務，處于空置狀態。

2)CPU核心數量-轉碼效率。

本實驗通過更改Spark Shell程序提交參數，完成對CPU核心數量的關閉/啟用，命令格式如下：

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

將N取1～10。實驗對象為A.mkv、B.avi、C.mp4，三個視頻文件不分次序轉碼為flv格式，編碼為H.264，10次實驗后取均值，得到運行結果如圖13所示。

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

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

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

從圖14中可以看出，隨著集群節點數量與集群CPU總核心數量的增多，視頻轉碼效率在不斷地提升；但當集群總節點數與CPU總核心數為8個時，兩者轉碼用時相同；繼續增加CPU核心數量和節點數量，CPU核心數量的增加能帶來更高的效率。集群節點數在12個時，達到最大轉碼效率；CPU總核心在集群節點數為18個時達到最大轉碼效率。結合Spark調度原理，可進一步分析出現這種差異是因為調度管理器會優先將作業交給已經存儲有視頻分片的節點進行處理，從而降低數據在集群中傳輸帶來的網絡開銷。

4.3.6 不同平臺實現的視頻轉碼系統對照實驗

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

分別使用基于Hadoop實現的分布式轉碼系統和基于Spark Streaming實現的分布式流處理轉碼系統對A.mkv、B.avi、C.mp4進行目標編碼方法為MPEG-4的轉碼。通過10次實驗，每項結果取平均值，結果如圖15所示。

圖15 Hadoop與Spark Streaming分布式轉碼系統效率對比Fig. 15 Efficiency comparison between Hadoop and Spark Streaming distributed transcoding systems

通過圖15可以得出，基于Spark Streaming實現的分布式流處理視頻轉碼系統比基于Hadoop實現的分布式轉碼系統的轉碼效率提升了26.7%。理論分析結果表明，在視頻文件切分到視頻分片轉碼環節，不需要視頻文件全部切分完成即可進行轉碼工作，通過Spark構建的DAG任務模型節省了這部分的時間開銷，提升了轉碼效率。

4.3.7 與文獻[19]的視頻轉碼方法對照實驗

本文按照文獻[19]提出的基于Hadoop平臺的視頻并行轉碼方法，實現了一種基于Hadoop的視頻轉碼系統，與基于本文所提出視頻轉碼方法實現的原型系統進行對比實驗。實驗硬件配置為4個節點(CPU為雙核1 GHz、內存為16 GB)，通過四川師范大學私有云快速創建與該硬件參數相近的節點。實驗選取了三個視頻文件作為實驗對象[19]，參數如表8所示。

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

表8中的實驗對象通過FFmpeg對一段視頻進行處理生成,實驗規定了視頻轉碼后的目標參數[19]，如表9所示。

表9 視頻轉碼參數Tab. 9 Video transcoding parameters

針對同一視頻進行了10次實驗，取平均轉碼時間,實驗結果對比如圖16所示。

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

和文獻[19]的方法相比，本文方法對Video1的轉碼效率提升21%，對Video2的轉碼效率提升了19.7%，對Video3的轉碼效率提升了19.6%；三個視頻的平均效率提升了20.1%。對比實驗結果表明，本文提出的視頻轉碼方法較文獻[19]方法效率顯著提高。

5 結 語

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