（三明學(xué)院 現(xiàn)代教育技術(shù)中心，福建 三明365004）

1、前言

近年來流媒體用戶快速增加，如何以最低的成本來滿足所有用戶的流媒體需求是現(xiàn)今網(wǎng)絡(luò)內(nèi)容服務(wù)業(yè)者關(guān)切的熱點。由于網(wǎng)絡(luò)帶寬的限制以及多樣化的多媒體設(shè)備與視頻格式，網(wǎng)絡(luò)內(nèi)容服務(wù)業(yè)者將視頻傳遞到用戶必須通過視頻轉(zhuǎn)碼，將視頻流媒體轉(zhuǎn)換成相對應(yīng)的視頻格式，視頻轉(zhuǎn)碼的用途主要是將視頻流進行壓縮以減少數(shù)據(jù)量的傳遞[1,2]。分布式視頻轉(zhuǎn)碼是將一視頻切割成許多區(qū)塊，再把這些區(qū)塊分配給多臺服務(wù)器主機進行視頻轉(zhuǎn)碼工作，轉(zhuǎn)碼完成后再將各個區(qū)塊合并成一個視頻文件，此方法可提高視頻編碼的效率，降低用戶觀看視頻的等待時間[3,4]。然而傳統(tǒng)分布式視頻轉(zhuǎn)碼系統(tǒng)，軟硬件設(shè)備的更新維護及擴充，對于網(wǎng)絡(luò)內(nèi)容服務(wù)業(yè)者成本而言是相當大的負擔，網(wǎng)絡(luò)內(nèi)容服務(wù)業(yè)者為了架設(shè)分布式轉(zhuǎn)碼服務(wù)器，必須耗費額外工作量，人力成本也極高[5,6]。為了克服軟硬件擴充的問題，并改善編碼時間，可將分布式轉(zhuǎn)碼計算應(yīng)用在云服務(wù)系統(tǒng)上。云服務(wù)系統(tǒng)可提供可靠且更安全的網(wǎng)絡(luò)資料儲存，在軟硬件設(shè)備更新與擴充都由云服務(wù)支持，使用者只需租用云服務(wù)器即可使用軟硬件設(shè)備；在成本方面，相較于自行架設(shè)服務(wù)器，租用云服務(wù)系統(tǒng)器成本較低。研究基于云服務(wù)使用Hadoop分布式文件系統(tǒng)(HDFS)儲存視頻區(qū)塊，并利用MapReduce框架與FFmpeg視頻編碼軟件進行分布式轉(zhuǎn)碼，可實現(xiàn)云服務(wù)器視頻串流轉(zhuǎn)碼系統(tǒng)，以提高視頻觀看的流暢性。

2、相關(guān)研究

2.1 云計算技術(shù)

云計算架構(gòu)主要可分為以下三層：基礎(chǔ)設(shè)施服務(wù)(Infrastructure as a Service，IaaS)，像是 Amazon 隸屬的Amazon EC2與S3；平臺服務(wù) (Platform as a Service，PaaS)，如 Amazon Web Service 和 Google APP Engine；軟件服務(wù)(Software as a Service，SaaS)，例如Microsoft的網(wǎng)絡(luò)更新服務(wù)與Google Maps等[7]。

基于云計算的Hadoop基礎(chǔ)設(shè)施服務(wù)構(gòu)架，主要分為HDFS與MapReduce兩部分。HDFS采主從式(Master/Slave)架構(gòu)，由一個名稱節(jié)點(name節(jié)點)與多個數(shù)據(jù)節(jié)點(data節(jié)點)這兩種角色組成。一般部署情況下，Master上只運行一個名稱節(jié)點(name節(jié)點)，負責處理文件系統(tǒng)的管理及儲存，并記錄文件的各個數(shù)據(jù)區(qū)塊放置在具體的數(shù)據(jù)節(jié)點(data節(jié)點)上。而在每一個Slave上皆有一個數(shù)據(jù)節(jié)點(data節(jié)點)，負責處理用戶存取數(shù)據(jù)區(qū)塊上的請求，并定時回復(fù)數(shù)據(jù)區(qū)塊的狀態(tài)給名稱節(jié)點(name節(jié)點)。當有任何一個數(shù)據(jù)節(jié)點(data節(jié)點)損壞時，名稱節(jié)點(name節(jié)點)作重做操作[8]。Hadoop MapReduce主要架構(gòu)是由Map與Reduce兩個函數(shù)所組成，Map函數(shù)的輸入為一組key/value序?qū)?，輸出則為多組inter mediate key/value序?qū)M。Reduce函數(shù)則將相同inter mediate key的value做合并動作，最后產(chǎn)生輸出結(jié)果key/value序?qū)?，MapReduce流程如圖一所示。

圖1 MapReduce流程圖

2.2 視頻轉(zhuǎn)碼模式

目前視頻轉(zhuǎn)碼的模式可以分成三大類，分別為：(1)單機模式：使用單一機器或服務(wù)器來進行視頻轉(zhuǎn)碼的工作。這種模式的優(yōu)點就是操作與維護都較簡單，但缺點就是擴展性差，且轉(zhuǎn)碼速度將受限于單一機器的效能。此外，一旦涌入大量的轉(zhuǎn)碼需求時，系統(tǒng)將無法及時地處理這些工作。(2)分布式計算模式：同時使用多臺機器（包括服務(wù)器）進行視頻轉(zhuǎn)碼的工作。在進行視頻轉(zhuǎn)碼工作前，系統(tǒng)會將輸入的視頻文件分割成較小的視頻片段，之后將每個片段傳送到不同的機器上進行轉(zhuǎn)碼，在完成轉(zhuǎn)碼后，再將每個轉(zhuǎn)碼后的視頻片段傳送到特定機器上進行合并。這種模式的優(yōu)點是轉(zhuǎn)碼時間短，且可以應(yīng)付大量的轉(zhuǎn)碼工作需求；但缺點就是實作上較單機模式復(fù)雜，且須考慮單一機器當機以及轉(zhuǎn)碼程序在任一機器上執(zhí)行錯誤時的處理方式。(3)云計算模式：使用現(xiàn)有云服務(wù)提供商，如Amazon的Elastic Compute Cloud(EC2)，來執(zhí)行視頻轉(zhuǎn)碼的工作。其中，EC2提供的一個實例就可以負責處理一個視頻轉(zhuǎn)碼的任務(wù)，這種模式的優(yōu)點就是無需管理系統(tǒng)的硬件，成本控制也更靈活[9,10]。

3、非實時性視頻轉(zhuǎn)碼系統(tǒng)

3.1 視頻轉(zhuǎn)碼需求分析

視頻轉(zhuǎn)碼可以根據(jù)輸入數(shù)據(jù)的特性分成兩大類，其一是針對已存在的視頻數(shù)據(jù)進行轉(zhuǎn)碼的工作；另一類則是針對實時性的視頻數(shù)據(jù)進行轉(zhuǎn)碼的工作。針對第一種類型的數(shù)據(jù)來說，系統(tǒng)設(shè)計的目標就是希望視頻轉(zhuǎn)碼的時間越低越好。然而，針對第二種類型的文件來說，系統(tǒng)設(shè)計的目標就不是盡可能地降低視頻轉(zhuǎn)碼的時間，而是在不高于一指定的時間下，讓系統(tǒng)可以同時處理越多的視頻轉(zhuǎn)碼工作越好。例如，假設(shè)實時性視頻幀率是每秒30幀，則轉(zhuǎn)碼系統(tǒng)就只須在33毫秒處理完一個幀的畫面即可達到即時性的要求。

為了達到上述的目標，可以通過將視頻轉(zhuǎn)碼這項工作平行化來降低轉(zhuǎn)碼的時間或增加系統(tǒng)負載量。平行化指的是將視頻轉(zhuǎn)碼這項工作分割成若干件較小的工作，且這些工作彼此間不存在任何的相依性，也就是任一工作無需等待其他工作執(zhí)行完畢后才能開始執(zhí)行。因此，若這些分割后工作不存在任何相依性時，就可以將這些工作同時分派至分布式計算平臺上不同的節(jié)點來處理，以達到上述的目標。

對于已存在的視頻數(shù)據(jù)來說，平行化的方式就是將輸入的視頻數(shù)據(jù)分割成數(shù)個較小的視頻塊，并把每個分割好的視頻塊傳送到不同的節(jié)點上進行轉(zhuǎn)碼。另一方面，對于實時性的數(shù)據(jù)來說，平行化的方式有兩種，分別為：(1)基于幀率來平行化：這類作法就是將輸入的視頻文件復(fù)制成N份后(N取決于輸出的幀率），將每一份交由分布式計算平臺上的一個節(jié)點來處理。(2)基于圖像群組(Group of pictures，GOP)與幀率來平行化：這類的作法就是先將輸入視頻文件以GOP為單位切成較小的視頻塊，接著根據(jù)輸出的幀率數(shù)復(fù)制數(shù)份視頻塊，并把每個復(fù)制后的視頻塊傳送到不同的節(jié)點上進行轉(zhuǎn)碼[11]。

3.2 非實時性視頻轉(zhuǎn)碼系統(tǒng)設(shè)計

非實時性視頻轉(zhuǎn)碼系統(tǒng)的輸入是需要轉(zhuǎn)碼的視頻文件和使用者的配置文件，輸出則是轉(zhuǎn)換后的視頻文件。在目前的系統(tǒng)中，輸出的文件有兩種不同的形式，一種是單一數(shù)據(jù)，另一種是分割后的數(shù)據(jù)。其中，產(chǎn)生第二種形式的目的是為了便于跟HLS或DASH等標準整合。第二種形式的文件就可以直接輸出至特定的HTTP服務(wù)器來發(fā)布。整個非實時性視頻轉(zhuǎn)碼系統(tǒng)主要包含有視頻封裝格式轉(zhuǎn)換器、視頻數(shù)據(jù)分割器與視頻編解碼器，視頻封裝格式轉(zhuǎn)換器的功能就是將輸入的視頻文件轉(zhuǎn)換成視頻文件分割器可以處理的文件格式。為了減少視頻文件分割器的操作復(fù)雜度，目前視頻數(shù)據(jù)分割器只接受特定的視頻封裝格式。因此，在對視頻文件進行分割前，系統(tǒng)就得對輸入的視頻文件進行格式上的轉(zhuǎn)換。通常，格式轉(zhuǎn)換的速度非常的快，基本上是不會增加太多的轉(zhuǎn)碼時間[12]。

根據(jù)實驗結(jié)果，在CPU4核的配置上，視頻封裝格式轉(zhuǎn)換器的處理速度可以達到約每秒一千多幀(對1080P的視頻）。在格式轉(zhuǎn)換后，第二步就是視頻分割，將格式轉(zhuǎn)換后的視頻分割成較小的視頻塊，對于壓縮后的影片來說，一個GOP就是一個最小的處理單位。在視頻分割時，若影片的某一段GOP邊界恰好不在整數(shù)秒時，影片分割的結(jié)果將可能大于或小于使用者設(shè)定的秒數(shù)，例如，當影片分割的單位被設(shè)為10秒時，視頻文件分割器分割后的結(jié)果可能是8.x秒，也有可能是10多秒，這主要取決于GOP邊界的位置。影片分割的下一步就是對每個視頻塊進行轉(zhuǎn)碼，在對每個視頻塊進行轉(zhuǎn)碼前，先把每個視頻塊上傳到Hadoop平臺上的文件系統(tǒng)，也就是HDFS，之后再調(diào)用FFmpeg轉(zhuǎn)碼程序來進行轉(zhuǎn)碼。在Hadoop平臺上所使用的編程模型是MapReduce。在系統(tǒng)中，Map函數(shù)是轉(zhuǎn)碼程序，每個Map函數(shù)的輸入是一個視頻塊，各個云計算節(jié)點接收視頻塊并進行轉(zhuǎn)碼，轉(zhuǎn)碼完成后，通過Reduce函數(shù)完成視頻的合并，由于在本系統(tǒng)中因為配置文件有記錄了每個視頻編號信息，Reduce函數(shù)只執(zhí)行將轉(zhuǎn)碼的結(jié)果排序并轉(zhuǎn)發(fā)到流媒體服務(wù)器，流媒體服務(wù)器依據(jù)配置信息推送視頻流到用戶設(shè)備上，從而實現(xiàn)非實時性視頻轉(zhuǎn)碼，如圖2。

圖2 基于hadoop系統(tǒng)流媒體轉(zhuǎn)碼結(jié)構(gòu)設(shè)計

4、實驗方法與結(jié)果

4.1 實驗方法

實驗為了測試非實時視頻轉(zhuǎn)碼系統(tǒng)的執(zhí)行效率，通過計時獲取視頻轉(zhuǎn)碼的時間。測試方案如下：(1)在相同節(jié)點數(shù)目下，不同視頻輸出格式所需視頻轉(zhuǎn)碼時間。(2)在不同節(jié)點數(shù)目下，不同視頻輸出格式所需視頻轉(zhuǎn)碼時間。(3)在相同節(jié)點數(shù)目下，不同的視頻塊大小對于視頻轉(zhuǎn)碼時間的影響。

實驗采用Hadoop0.20.203版作為系統(tǒng)的軟件平臺。硬件的部分，每臺節(jié)點配置4核CPU，內(nèi)存8GB。每臺節(jié)點間千兆網(wǎng)絡(luò)連接。在本實驗中，輸入是一段長度為10秒的影片，其中影片是采用H.264的影像壓縮技術(shù)，影片的分辨率為1920x1080(1080P)，幀率為 30fps，碼率為 3500kbps；聲音的部分則是采用AAC的壓縮技術(shù)，聲音的采樣頻率為44kHz，碼率為125Kbps。輸出的部分主要差異是在影像的分辨率與碼率上的不同。表1為本實驗輸入與輸出的視頻文件格式列表。

表1 視頻輸入輸出格式

4.2 實驗結(jié)果

通過測試在相同節(jié)點數(shù)目下，不同視頻輸出格式所需視頻轉(zhuǎn)碼時間，如圖3是在相同節(jié)點數(shù)目下（在這個實驗中，節(jié)點數(shù)目是3臺），不同幀率與分辨率所需的轉(zhuǎn)碼時間，T1、T2、T3代表的是三次實驗的結(jié)果，Avg則是這三次實驗的平均值。從圖3的數(shù)據(jù)中，可以看出：第一，轉(zhuǎn)碼時間的長短主要取決于分辨率而非幀率，這點可以從比對200K與400K以及600K與1200K來看出；第二，對于五種輸出格式，三次實驗所得到的結(jié)果會有所差異。造成這樣差異的主要原因是在于轉(zhuǎn)碼程序執(zhí)行錯誤的比例，以及在不同時間可能存在的不同系統(tǒng)開銷。

圖3 不同分辨率轉(zhuǎn)碼時間比較

根據(jù)經(jīng)驗，在通過Hadoop來執(zhí)行轉(zhuǎn)碼程序時，通常會有約1～2%左右的程序發(fā)生錯誤。此時，Hadoop就會將這些發(fā)生錯誤的程序移除后，再到其他節(jié)點上從新執(zhí)行。由此一來，這將會增加整個轉(zhuǎn)碼時間。因此，若轉(zhuǎn)碼程序執(zhí)行錯誤的比例越低時，則整個轉(zhuǎn)碼時間就會越短。然而，根試驗的經(jīng)驗，轉(zhuǎn)碼程序執(zhí)行錯誤的情況還具有隨機性。

圖4 不同節(jié)點數(shù)量轉(zhuǎn)碼時間比較

通過測試得到了在不同節(jié)點數(shù)目下，不同視頻輸出格式所需視頻轉(zhuǎn)碼時間，如圖4中1節(jié)點表示在單一節(jié)點且無使用Hadoop的情況下所需的轉(zhuǎn)碼時間，2節(jié)點與3節(jié)點則是在使用2與3臺節(jié)點且使用Hadoop的情況下所需的轉(zhuǎn)碼時間。從圖4中不難發(fā)現(xiàn)，當節(jié)點數(shù)目增加時，視頻轉(zhuǎn)碼時間就會隨著下降，相較于單一主機的情況，在一個擁有3個節(jié)點的Hadoop系統(tǒng)上執(zhí)行視頻轉(zhuǎn)碼，平均節(jié)省38.64%轉(zhuǎn)碼時間，如表2所列。

表2 不同節(jié)點數(shù)量轉(zhuǎn)碼時間及效率提高情況比較（單位：S）

圖5 不同數(shù)據(jù)塊長度轉(zhuǎn)碼數(shù)據(jù)比較

通過測試在相同節(jié)點數(shù)目下，不同的視頻塊大小對于視頻轉(zhuǎn)碼時間的影響，如圖5是在相同節(jié)點數(shù)目下，就趨勢上來看，視頻轉(zhuǎn)碼的時間是反比于視頻塊的大小，當視頻塊大小增加時，視頻轉(zhuǎn)碼的時間通常會跟著下降，造成這現(xiàn)象的主因是網(wǎng)絡(luò)傳輸與啟動視頻轉(zhuǎn)碼程序的時間成本。此外，因為目前架構(gòu)的系統(tǒng)只有3臺節(jié)點，而每個節(jié)點上只有4顆CPU核心，也就是最多同時只能執(zhí)行12個轉(zhuǎn)碼程序。因此，當文件切割后的視頻塊個數(shù)大于12時，有些文件就無法平行地被處理。當系統(tǒng)的節(jié)點數(shù)足夠多時，視頻塊越小，則可以平行處理的視頻塊個數(shù)就越多，此時整體的轉(zhuǎn)碼時間就可以縮短。因此，視頻塊的大小應(yīng)該是取決于系統(tǒng)里的節(jié)點個數(shù)。

5、結(jié)論與討論

本文主要針對HLS與DASH等串流標準提出了一套云計算視頻轉(zhuǎn)碼系統(tǒng)，根據(jù)實驗的結(jié)果顯示：（1）在轉(zhuǎn)碼時間上，本實驗設(shè)計的系統(tǒng)有著相當不錯表現(xiàn)，較于單一主機的情況，在一個擁有3個節(jié)點的Hadoop系統(tǒng)上執(zhí)行視頻轉(zhuǎn)碼，平均節(jié)省38.64%轉(zhuǎn)碼時間；(2)不同的視頻塊大小對于視頻轉(zhuǎn)碼時間的影響，就趨勢上來看，視頻轉(zhuǎn)碼的時間是反比于視頻塊的大小，當視頻塊大小增加時，視頻轉(zhuǎn)碼的時間通常會跟著下降，造成這現(xiàn)象的主因是網(wǎng)絡(luò)傳輸與啟動視頻轉(zhuǎn)碼程序的時間成本。

根據(jù)實驗的觀察，如果使用Hadoop平臺作為實時性視頻轉(zhuǎn)碼系統(tǒng)，由于處理延遲的影響，很難滿足實時性視頻的需求，尤其是HLS與DASH等串流標準本身就存在一定的處理延遲。如果針對非實時性與實時性的視頻轉(zhuǎn)碼需求分別各設(shè)計一套專用的視頻轉(zhuǎn)碼系統(tǒng)，在管理上又將造成使用效率不高。因此，最好的方式就是針對HLS與DASH等串流標準開發(fā)一套可以同時支持非實時性與實時性的視頻轉(zhuǎn)碼服務(wù)的通用視頻轉(zhuǎn)碼系統(tǒng)。此外，通過通用圖形處理器（GPGPU)來加速視頻轉(zhuǎn)碼程序在每臺機器上的執(zhí)行效率也是一個值得探究的方向。因此，在后續(xù)的研究，將持續(xù)朝這兩大方向來發(fā)展。