基于Hadoop的分布式視頻轉碼系統研究

邢艷芳，周舒琪

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

0 引 言

隨著各類音視頻平臺的發展升級，產生了多種音視頻封裝格式和音視頻編碼格式。用戶相應的轉碼需求日趨多樣化且高清轉碼請求也日益增多。目前普遍采用的單機版視頻轉碼技術的處理時間過長，占用服務器資源高，受制于單節點計算量和轉碼算法的并發能力[1]。在此基礎上進行的技術革新仍會受到基本物理條件的影響，無法實現大幅度的轉碼速度提升。

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

Hadoop系統通過底層的分布式存儲系統HDFS優化存儲方式，擴大存儲容量，提高讀寫速度[3]。應用其突出的技術優勢，該文提出一種基于Hadoop的分布式視頻轉碼系統。依托Hadoop云計算平臺，采用開源項目FFmpeg實現音視頻編解碼及格式轉換等功能。

1 系統應用技術概述

1.1 Hadoop云平臺概述

Hadoop由Apache基金會開發，是一種穩定的開源分布式結構框架，為當前常用的云計算存儲平臺之一，被國內外企業如Facebook、Amazon、網易、中國移動等廣泛應用[4]。Hadoop的任務實現主要靠Client機器、主節點和從節點三部分。由主節點負責HDFS和MapReduce兩大Hadoop關鍵任務模塊的監督。

Hadoop由HDFS、MapReduce、HBase、Pig等成員組成，其中最基礎的組成成分為底層數據存儲系統HDFS和執行編程程序的MapReduce模型。采用開源項目FFmpeg實現音視頻編解碼及格式轉換等項目。

1.2 HDFS分布式文件系統

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

1.3 MapReduce計算模型概述

MapReduce編程框架是適合應用于超大型數據集處理的編程模型。將數據運算分成了Map和Reduce兩部分實現，互相獨立又相互協同工作[5]。在Map階段將完整數據分片發送至多節點上進行并行計算，完成后在Reduce階段將其合并成為最終計算結果?？梢院喕跀祿幚碇猩婕暗降娜蝿辗峙洹⑷蒎e處理、負載均衡量等問題。適合應用MapReduce計算方式的數據集必須要滿足兩大前提條件，首先元數據文件可以被分解為多個小型數據集，其次分成的每一個小的數據集都可以滿足并行處理方式。

2 系統分析及方案設計

2.1 系統功能概要

視頻文件常以幀形式存儲，對于存儲方式的選擇具有很大的要求，視頻的畫面大小，拍攝質量，幀率編碼的不同會導致存儲容量發生變化。由于視頻文件本身的特殊性，存儲數據庫需要滿足連續讀寫以及數據流量大等特點。為實現多種編碼格式之間的相互轉換，則需要進行大量的數據分析運算。現有傳統系統主要應用以下三種轉碼模式，很難高效完成如此體量的實時并發轉碼請求。

(1)單機模式：最基礎也是最簡單的服務方式。由用戶和轉碼服務器直接交換數據實現。僅適合用于低轉碼量的目標文件，并且受單一轉碼服務器的性能限制，轉碼時間很難得到大幅度提升，轉碼質量也無法應對高數據量的轉碼任務。

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

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

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

2.2 系統的架構設計

2.2.1 系統架構模型

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

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

2.2.2 系統運行流程

本系統處理完成一個用戶轉碼請求的步驟如下：

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

圖1 系統整體架構模型

②發送轉碼命令：由WebServer服務器對用戶請求進行接收處理，并將其發送給承載的Hadoop集群中的NameNode節點上。

③進行分布式轉碼：由NameNode節點負責調用集群中的DataNodes節點，多節點進行轉碼任務的并行計算。

④完成視頻轉碼任務：分布式轉碼進程結束后，文件會暫存在DataNode節點中。由NameNode向WebServer返回轉碼完成后的視頻文件所在地DataNodeX。

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

⑥讀取視頻：用戶從DataNodeX節點上獲取轉碼完成后的新視頻文件。

3 系統模塊設計

3.1 視頻數據在HDFS上的存儲模塊

通常采用的視頻分段思想主要分為以下兩種：獨立視頻獨立成段、單一視頻多個分段方式。由于音視頻文件本身數據為非結構化數據，不可直接采用傳統壓縮編碼方式進行存儲。HDFS中所有的文件都以數據塊形式進行存儲，每個數據塊的大小都可以根據需求進行調整[9]。在執行集群處理時，由NameNode進行HDFS文件存儲系統的監督調度，由從節點負責運行系統大部分功能，實行數據分析和計算，并需要對自身與主節點的通信進程進行監督守護[10]。

在文件寫入HDFS文件管理系統的過程中，首先需要Client節點向NameNode名稱節點獲取文件寫入許可；NameNode啟動工作，此節點是整個文件系統中數據目錄和元數據存放地點，負責獲取和管理其下管理的各數據節點的運行信息，將文件存儲的地址位置信息發送返回給Client；Client接收后，將各數據片段文件按順序寫入到對應的DataNode中。在文件讀取的過程中，由Client向NameNode節點發起文件讀取請求，NameNode節點對其回復文件存儲的DataNode節點信息，以使Client獲取完整文件數據。

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

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

表1 視頻分割方式

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

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

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

在系統分片存儲完成后，在分段分發的過程中應注意在NameNode節點上使用Hadoop balancer的命令，保證數據量均衡分布在各DataNode節點上，在后續MapReduce的工作過程中減少網絡數據傳輸誤差。

3.2 基于FFmpeg的分布式轉碼模塊

FFmpeg[13]是一種適用于多種編譯環境的跨平臺開源多媒體架構，遵循LGPL/GPL許可協議?？梢詫崿F編解碼在內的多種功能。包含了先進音視頻編解碼庫libavcodes，因此在視頻格式不斷推陳出新的今天，它仍然可以支持最古老的視頻格式。

在Map端實現轉碼時，需要對任務視頻的多個分段部分分別進行轉碼，因此需要確保原視頻文件的分段均勻發送給多個負責視頻處理的DataNode節點，從而實現節點的最大化利用，將數據并行化處理的優勢發揮到極致。在數據節點上，啟動安裝的FFmpeg設定轉碼參數，按照用戶需求，對視頻文件進行轉碼業務。在Reduce端進行視頻分段的合并，和多節點轉碼不同，視頻合并通常采用單一Reduce進行，負責將來自多個Map端的轉碼完成后的輸出視頻文件進行合并。

在功能上MapReduce實現將一個任務視頻文件劃分為多個Key/Value形式對的子任務文件。采用單個Map數值對應單個視頻分段文件的方式進行文件輸入，以保證單獨視頻段的完整性。依據特定的Map數值在HDFS存儲系統中找到對應的視頻分段文件，將其作為對應Key的value值返回，以Key/value函數對的形式寫入Map函數，由Map()函數調度啟用轉碼程序。

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

圖3 JNI調用C/C++接口

視頻轉碼系統的基本步驟是先解碼后編碼。在整個視頻轉碼過程中，首先使用函數av_read_frame( )的調用實現視頻碼流中的單幀讀??；隨后通過向終端窗口輸入avcodec_decode_video0( )視頻文件格式解碼命令和avcodec_encode_video0( )編碼命令分別實現單幀視頻的解碼和重編碼，最后寫入文件[15]。

4 系統測試與數據分析

4.1 實驗環境部署

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

4.2 實驗視頻輸入條件

該實驗視頻文件按照FFmpeg模塊設計的m值范圍進行分片切割。分割后的視頻片段數如表2所示。

4.3 實驗結果與分析

實驗從兩種變量方式進行了設計，分別探究了不同條件影響下的轉碼能力差距。

表2 視頻分段大小與分段個數

(1)按以上實驗視頻的選取標準，將1.2 G的目標視頻進行轉碼實現，實驗目的是將MKV的視頻格式轉化為MP4的視頻格式。轉碼方案都采用本課題設計的基于Hadoop的分布式視頻轉碼系統。實驗變量為目標視頻不同大小的分段量，通過比較不同變量條件下對應使用的轉碼時間，得出最優分片大小。其結果如圖4所示。

圖4 分段式轉碼時間對比

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

(2)在實驗一的基礎上，選取最優的32 MB視頻分段。分別使用單臺DataNode模擬的單機轉碼方式和多臺DataNodes組成的分布式集群方式進行視頻轉碼。利用本實驗探究本課題設計系統相對于傳統單機轉碼的優勢，其實驗結果如圖5所示。

圖5 32 MB分段下不同轉碼方式的轉碼時間

從圖中可以看出，對于相同的目標視頻，轉碼時間由單機方式轉碼消耗的952秒縮短至分布式視頻轉碼方式的475秒。由此得出結論：使用分布式集群方式進行數據轉碼，可大幅度降低轉碼時間，提高轉碼效率。

5 結束語

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