基于Hadoop的流媒體轉(zhuǎn)碼系統(tǒng)設(shè)計(jì)

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

1、前言

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

2、相關(guān)研究

2.1 云計(jì)算技術(shù)

云計(jì)算架構(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]。

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

圖1 MapReduce流程圖

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

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

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

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

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

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

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

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

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

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

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

4、實(shí)驗(yàn)方法與結(jié)果

4.1 實(shí)驗(yàn)方法

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

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

表1 視頻輸入輸出格式

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

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

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

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

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

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

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

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

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

5、結(jié)論與討論

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

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