邢艷芳，周舒琪

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

0 引 言

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

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

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

1 系統(tǒng)應用技術概述

1.1 Hadoop云平臺概述

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

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

1.2 HDFS分布式文件系統(tǒng)

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

1.3 MapReduce計算模型概述

MapReduce編程框架是適合應用于超大型數(shù)據(jù)集處理的編程模型。將數(shù)據(jù)運算分成了Map和Reduce兩部分實現(xiàn)，互相獨立又相互協(xié)同工作[5]。在Map階段將完整數(shù)據(jù)分片發(fā)送至多節(jié)點上進行并行計算，完成后在Reduce階段將其合并成為最終計算結果?？梢院喕跀?shù)據(jù)處理中涉及到的任務分配、容錯處理、負載均衡量等問題。適合應用MapReduce計算方式的數(shù)據(jù)集必須要滿足兩大前提條件，首先元數(shù)據(jù)文件可以被分解為多個小型數(shù)據(jù)集，其次分成的每一個小的數(shù)據(jù)集都可以滿足并行處理方式。

2 系統(tǒng)分析及方案設計

2.1 系統(tǒng)功能概要

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

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

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

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

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

2.2 系統(tǒng)的架構設計

2.2.1 系統(tǒng)架構模型

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

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

2.2.2 系統(tǒng)運行流程

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

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

圖1 系統(tǒng)整體架構模型

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

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

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

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

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

3 系統(tǒng)模塊設計

3.1 視頻數(shù)據(jù)在HDFS上的存儲模塊

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

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

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

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

表1 視頻分割方式

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

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

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

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

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

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

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

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

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

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

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

4 系統(tǒng)測試與數(shù)據(jù)分析

4.1 實驗環(huán)境部署

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

4.2 實驗視頻輸入條件

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

4.3 實驗結果與分析

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

表2 視頻分段大小與分段個數(shù)

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

圖4 分段式轉碼時間對比

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

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

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

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

5 結束語

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