面向在線制作的集群轉(zhuǎn)碼系統(tǒng)設(shè)計*

孫思慧，孫 軍，王興東

（上海交通大學(xué) 電子工程系 圖像通信與信息處理研究所，上海 200240；上海市數(shù)字媒體處理與傳輸重點實驗室，上海 200240）

1 引言

在基于廣域網(wǎng)環(huán)境的在線節(jié)目制作系統(tǒng)中，用戶需要在制作過程中大量使用各種多媒體素材，它們往往具有不同的分辨力、制式、音視頻壓縮格式甚至是壓縮參數(shù)，這會對節(jié)目制作系統(tǒng)的兼容性提出很高的要求，因此如何能夠在一個統(tǒng)一的制作平臺上自由使用這些素材是在線制作環(huán)境需要解決的重要問題。在專業(yè)節(jié)目制作領(lǐng)域，節(jié)目素材的導(dǎo)入是后期制作中的重要一環(huán)，通常如蘋果平臺下的Final Cut Pro這類的非線性編輯軟件，會將需要導(dǎo)入的素材轉(zhuǎn)碼為統(tǒng)一的格式，從而滿足后續(xù)編輯工作的需要。但是這種方式需要節(jié)目制作終端具有強大的運算能力，才能盡量降低素材導(dǎo)入所占用的時間。而對于普通的視頻制作愛好者而言，更需要一臺性能強大的計算機作為其素材導(dǎo)入、圖像處理、特效渲染等一系列制作環(huán)節(jié)的重要工具。為了能搭建起一個基于廣域網(wǎng)的在線節(jié)目制作系統(tǒng)，使更多普通用戶能夠參與到節(jié)目制作活動中，需要在網(wǎng)絡(luò)前端建立一組為轉(zhuǎn)碼、特效合成等大運算量的工作提供保障的計算集群，這樣的集群能針對運算任務(wù)進行適當(dāng)?shù)姆纸?，利用多運算節(jié)點并發(fā)的優(yōu)勢，提高任務(wù)執(zhí)行速度，從而滿足多用戶同時工作的需要。

2 集群轉(zhuǎn)碼系統(tǒng)設(shè)計

本文所要實現(xiàn)的集群轉(zhuǎn)碼系統(tǒng)將最常見的MPEG-2視頻壓縮及TS封裝格式轉(zhuǎn)碼為目前最先進的H.264/AVC編碼格式[1]。

2.1 集群轉(zhuǎn)碼系統(tǒng)的構(gòu)成

整個集群轉(zhuǎn)碼系統(tǒng)由一臺核心服務(wù)器和若干臺計算節(jié)點組成，服務(wù)器和計算節(jié)點都配有千兆以太網(wǎng)卡，相互之間采用局域網(wǎng)交換機互聯(lián)。轉(zhuǎn)碼任務(wù)分析和分解、多媒體素材的分割與分發(fā)以及最終的分段回收與合并等功能都由核心服務(wù)器承擔(dān)，此服務(wù)器同時管理所有的計算節(jié)點，并在執(zhí)行轉(zhuǎn)碼任務(wù)過程中對所有節(jié)點以負載均衡的方式進行調(diào)度。計算節(jié)點負責(zé)實際的轉(zhuǎn)碼運算，在預(yù)先配置好一組轉(zhuǎn)碼程序的情況下，由核心服務(wù)器的調(diào)度系統(tǒng)來負責(zé)啟動節(jié)點上的轉(zhuǎn)碼運算。系統(tǒng)整體架構(gòu)如圖1所示。

圖1 集群轉(zhuǎn)碼系統(tǒng)整體架構(gòu)

2.2 Condor調(diào)度系統(tǒng)

Condor[2]是 Wisconsin-Madison大學(xué) Condor研究計劃中的一款開源軟件系統(tǒng)，它能夠提供高吞吐量的計算環(huán)境，有效利用那些通過網(wǎng)絡(luò)互連的工作站的計算能力。同其他分布系統(tǒng)類似，Condor提供任務(wù)排隊、調(diào)度策略、排序策略和資源管理等功能。本系統(tǒng)利用Condor對計算能力的調(diào)度控制來實現(xiàn)集群轉(zhuǎn)碼功能。

Condor系統(tǒng)利用一種稱為ClassAd的機制來提供一個極端靈活的架構(gòu)，從而實現(xiàn)任務(wù)與資源之間的匹配。在用戶提交任務(wù)時可以標(biāo)明需要滿足的要求和一些參數(shù)，同樣，在配置Condor系統(tǒng)中的設(shè)備資源時也可以指明該設(shè)備對希望執(zhí)行的任務(wù)的要求和參數(shù)。通過這兩組要求和參數(shù)，系統(tǒng)會為任務(wù)尋找網(wǎng)絡(luò)中的可用計算資源，然后在那里執(zhí)行任務(wù)。

另外，Condor系統(tǒng)中提供了一種名為有向非循環(huán)圖（Directed Acyclic Graph，DAG）的任務(wù)提交機制。利用 DAG可以表示一組有依賴關(guān)系的任務(wù)，用DAG描述文件可以將一個或一組任務(wù)設(shè)置為另外一個或一組任務(wù)的子任務(wù)。

如圖2所示，任務(wù)A即為B和C的父任務(wù)，反之，B和C為A的子任務(wù)。同樣，B和C均為D的父任務(wù)，而D就是B和C共同的子任務(wù)。Condor會根據(jù)該描述文件，自動在所有的父任務(wù)執(zhí)行完畢的情況下再開始分配執(zhí)行子任務(wù)。這樣的機制，為項目中子視頻轉(zhuǎn)碼后再拼接的形式提供了有效的解決方案。

圖2 DAG機制示例

3 集群轉(zhuǎn)碼系統(tǒng)的實現(xiàn)

集群轉(zhuǎn)碼系統(tǒng)按照上一章所述的架構(gòu)完成硬件環(huán)境搭建，而軟件部分的實現(xiàn)則包括任務(wù)生成、轉(zhuǎn)碼程序、結(jié)果生成等幾個部分。

3.1 任務(wù)生成

在本文所設(shè)計的集群轉(zhuǎn)碼系統(tǒng)中，任務(wù)生成部分包括了多項功能，有素材格式分析及封裝解包、視頻流分割、子任務(wù)提交等步驟。

素材格式分析：根據(jù)用戶運行程序時提供的參數(shù)對素材內(nèi)容進行一定的分析，獲得素材格式的基本信息、包括封裝格式、視音頻的編碼格式、視頻參數(shù)等，對于轉(zhuǎn)碼程序不能適應(yīng)的參數(shù)向用戶返回不能支持的錯誤信息。

封裝解包：將封裝為TS流格式的原始素材進行解包，分別生成相應(yīng)的音頻和視頻基本流。

視頻流分割：視頻數(shù)據(jù)本身的特性決定了它的分割點并不能處在碼流中的任意位置，作為解碼器處理的基本單元，必須保證同一視頻幀的數(shù)據(jù)不能產(chǎn)生斷點，否則將無法正常解碼。另外，由于MPEG-2視頻壓縮編碼采用了幀間預(yù)測技術(shù)，這就決定了視頻碼流中，不同的幀之間存在相互參考，必須將前后相關(guān)的若干幀圖像數(shù)據(jù)同時送入一個解碼器，才能保證解碼的正確性，最典型的問題在于Open GoP和Close GoP之間的區(qū)別[3]，見圖3。

圖3 典型的GoP幀結(jié)構(gòu)圖

下面介紹一種有效的視頻切割的解決方法[4]。由于MPEG-2標(biāo)準(zhǔn)規(guī)定，在GoP頭信息的一個字段中指明了該GoP是Open還是Close，這就給圖像分割帶來了方便，可以根據(jù)切割點處GoP類型的不同設(shè)置不同的切割策略。首先，如果切割點后緊跟的第一個GoP是Close的話，則不用考慮其他策略，即在分割點將視頻分為前后兩段即可，不會使某一段視頻產(chǎn)生無法解碼的情況。若切割點之后緊跟的第一個GoP是Open的話，則需要使后一段視頻前多加一個GoP。以圖3為例，假設(shè)現(xiàn)在切割點正好取在 GoP（k-1）與 GoP（k）之間，當(dāng)發(fā)現(xiàn)GoP（k）為Open GoP時，則第2段子視頻的起始點應(yīng)取在GoP（k-1）的起始位置，而第1段子視頻的結(jié)束點仍然取在2個GoP的中間分界點上（如圖4所示）。

分割之后，第2段視頻中的GoP（k）可以保證每一幀都正常解碼，然后在視頻拼接時采取對應(yīng)的方法，即可以實現(xiàn)連貫的視頻無縫拼接。

圖4 視頻切割示意圖

另外，視頻切割中還有一點需要注意的是，對于解碼器而言，每次對一段視頻進行解碼時，都是先尋找該段視頻中的序列頭信息，即sequence head字段。然而，通常一整段視頻可能僅在開始處包含一個序列頭，也可能在每個GoP前都附帶有相同的序列頭，這要視碼流而定。這時，若碰到前一種情況，則需要在切割之后的每一段子視頻前都添加上序列頭，以保證解碼器的正常運行。而若碰到后一種情況，則需要在切割時將每個序列頭都視為GoP結(jié)構(gòu)的一部分進行整體切割。

圖5是本文所設(shè)計的集群轉(zhuǎn)碼系統(tǒng)中針對視頻分割的代碼流程框圖。這里所實現(xiàn)的視頻分割均是基于MPEG-2的TS流所設(shè)計的。

圖5 視頻切割代碼流程圖

3.2 結(jié)果生成

所有的運算節(jié)點在完成被分配的轉(zhuǎn)碼任務(wù)之后，會將轉(zhuǎn)碼的結(jié)果傳回給核心服務(wù)器，因此需要將這些零散的視頻片段重新組合成完成的視頻，同時還要能夠與音頻文件一起通過格式封裝等手段生成一個新的多媒體素材。由于視頻分割與轉(zhuǎn)碼部分已經(jīng)充分考慮到了無縫拼接的概念，因此兩段子視頻之間的圖像幀是完全首尾相連的。如此，在拼接程序中就無須考慮幀的次序調(diào)整問題。需要指出的是，由于各段子視頻是在不同的設(shè)備上分別進行轉(zhuǎn)碼運算的，因此在生成的碼流中，各自都可以成為一段完整的視頻，包括許多頭部信息等稍顯重復(fù)的內(nèi)容。以實驗中所使用的X264編碼工具庫為例，在生成碼流的開始部分會加入一些特有信息，包括SPS以及編碼器參數(shù)等。在合并碼流的程序中，會減去除第一段外的其他子視頻中的這些附加信息，這樣可以減少最終碼流的文件大小，但又不會影響碼流的正常解碼播放。

3.3 轉(zhuǎn)碼程序

在本課題中，視頻轉(zhuǎn)碼程序的目的就是將原本符合MPEG-2標(biāo)準(zhǔn)的壓縮碼流轉(zhuǎn)碼為符合H.264標(biāo)準(zhǔn)的碼流。由于這兩種標(biāo)準(zhǔn)在壓縮算法上存在較大的差異[5]，因此在使用軟件進行轉(zhuǎn)碼時，最為合適的方案就是先將MPEG-2碼流解碼為原始YUV圖像數(shù)據(jù)，再將其編碼為H.264格式，這也就是所謂的“全解全編”轉(zhuǎn)碼方法。項目要求在H.264的編碼中具有許多可調(diào)參數(shù)，這些參數(shù)的設(shè)置是由轉(zhuǎn)碼用戶所決定的，因此利用這種“全解全編”的方法可以方便地調(diào)整編碼器的參數(shù)。圖6是整個轉(zhuǎn)碼程序的算法流程。

圖6 視頻轉(zhuǎn)碼程序流程

MPEG-2解碼和H.264編碼均采用了調(diào)用函數(shù)庫的形式，其中MPEG-2解碼開始采用的是ffmpeg；H.264編碼則采用的是X264開源工具庫。后處理部分主要是指對H.264碼流的幀順序的調(diào)整，以及調(diào)用函數(shù)庫時所分配的數(shù)據(jù)結(jié)構(gòu)的內(nèi)存釋放。

4 系統(tǒng)測試分析

筆者對本文所設(shè)計的集群轉(zhuǎn)碼系統(tǒng)進行測試。測試環(huán)境如表1所示。圖7是Condor系統(tǒng)對于各個設(shè)備的資源列表。其中，Condor將雙CPU計算機視為2臺設(shè)備。

圖7 condor_status命令顯示設(shè)備池信息

表1 集群轉(zhuǎn)碼設(shè)備配置信息

對于集群轉(zhuǎn)碼設(shè)備的平臺環(huán)境，筆者考慮以Linux為基本的操作系統(tǒng)平臺，主要是由于筆者在對Condor基于Windows和Linux兩種操作系統(tǒng)平臺進行了測試之后發(fā)現(xiàn)，Linux平臺中Condor不會在DAG模式下占用過多起始運行時間，這樣能夠提高整體轉(zhuǎn)碼系統(tǒng)的效率。

對于同一計算機而言，在執(zhí)行相同參數(shù)的視頻轉(zhuǎn)碼任務(wù)時的運算效率基本上是一定的，即視頻轉(zhuǎn)碼的時間與視頻文件的原始大小成正比。因此在對視頻分割的子視頻文件大小進行設(shè)定時就有了依據(jù)，對于同一段視頻，無論其如何分割，在所有執(zhí)行終端的運算速度相當(dāng)?shù)那疤嵯拢兇獾霓D(zhuǎn)碼運算時間是一定的。那么盡量將視頻文件分割為若干等量的小任務(wù)，并且根據(jù)各運算節(jié)點的運行情況靈活分配，這樣能夠最大限度地利用運算節(jié)點的能力。但同時又必須考慮到每次分配任務(wù)的系統(tǒng)開銷，太多的子任務(wù)也必然增大系統(tǒng)中的調(diào)度消耗，因此取得這之間的平衡是分割的關(guān)鍵因素。從筆者的實驗來看，選擇運算節(jié)點數(shù)目整數(shù)倍的分段數(shù)量可以最大限度地同時利用多個運算節(jié)點共同完成轉(zhuǎn)碼任務(wù)，可以想象在相同性能的運算節(jié)點不出現(xiàn)意外死機等現(xiàn)象而能夠保持系統(tǒng)正常運轉(zhuǎn)時，這樣的結(jié)論是合理的。

根據(jù)上述分割片段大小的分析可以發(fā)現(xiàn)，有一條重要的切割依據(jù)是集群設(shè)備的數(shù)量。

從圖8中可以明顯地看到轉(zhuǎn)碼時間隨終端個數(shù)而減少的趨勢。這樣的減少是有一定前提的，即轉(zhuǎn)碼的目標(biāo)數(shù)據(jù)大小相同，且分割的子視頻個數(shù)也是相同的。根據(jù)以上數(shù)據(jù)，可以得到的結(jié)論是：轉(zhuǎn)碼時間在轉(zhuǎn)碼源數(shù)據(jù)一定時隨集群終端個數(shù)的增加而減少。圖8中的黑色虛線是根據(jù)現(xiàn)有數(shù)據(jù)所擬和的二次曲線，并作了適當(dāng)?shù)难诱?，可以明顯地看到曲線逐漸隨終端數(shù)目的增大而趨于飽和。

圖8 計算節(jié)點數(shù)目與轉(zhuǎn)碼效率的關(guān)系

圖8中的數(shù)據(jù)表明，當(dāng)集群數(shù)量達到一定規(guī)模之后，完全可以超過單機軟件轉(zhuǎn)碼的效率。之所以在集群數(shù)量較少的情況下多機轉(zhuǎn)碼反而比單機的時間更長，是因為集群調(diào)度系統(tǒng)在任務(wù)調(diào)度上的時間消耗延長了任務(wù)執(zhí)行時間。這些時間損耗包括：DAG機制的初始化時間和數(shù)據(jù)的網(wǎng)絡(luò)傳輸時間。

當(dāng)然，轉(zhuǎn)碼時間肯定不會隨終端個數(shù)的增加而不斷減小，在終端數(shù)目增加到一定程度時，必然對本地網(wǎng)絡(luò)傳輸產(chǎn)生相當(dāng)?shù)膲毫?，并由此產(chǎn)生了瓶頸，導(dǎo)致轉(zhuǎn)碼時間趨于飽和，甚至反向增加。

5 結(jié)論

本文的集群轉(zhuǎn)碼系統(tǒng)對于廣域網(wǎng)在線制作這樣的由服務(wù)端承擔(dān)主要運算工作的應(yīng)用來講，不但能夠提高系統(tǒng)對單個用戶的響應(yīng)速度，還能夠幫助提高設(shè)備的利用率，減少設(shè)備投入，因此本文所設(shè)計的集群轉(zhuǎn)碼系統(tǒng)將對在線編輯應(yīng)用具有很大的價值。

[1]WIEGAND T，SULLIVAN G J，BJONTEGAARD G，et al.Overview of the H.264/AVC video coding standard[J].IEEE Trans.Circuits and Systems for Video Technology， 2003， 13（17）:560-576.

[2]Condor Team.University of wisconsin-madison,condor version 6.8.3 manual[EB/OL].[2009-05-20].http://www.cl.cam.ac.uk/manuals/condor-V6_8_3-Manual/.

[3]SANBE Y，WATANABE S，YU Dong,et al.High-speed distributed video transcoding for multiple rates and formats[EB/OL].[2009-05-20].http://www.anarg.jp/achievements/web2005/papers/sambe05IEICE-transcoding.pdf.

[4]趙堅勇.電視原理與接收技術(shù)[M].北京：國防工業(yè)出版社，2007.

[5]孫景琪，孫京.數(shù)字視頻技術(shù)及應(yīng)用[M].北京：北京工業(yè)大學(xué)出版社，2006.