孫思慧，孫 軍，王興東

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

1 引言

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

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

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

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

整個(gè)集群轉(zhuǎn)碼系統(tǒng)由一臺(tái)核心服務(wù)器和若干臺(tái)計(jì)算節(jié)點(diǎn)組成，服務(wù)器和計(jì)算節(jié)點(diǎn)都配有千兆以太網(wǎng)卡，相互之間采用局域網(wǎng)交換機(jī)互聯(lián)。轉(zhuǎn)碼任務(wù)分析和分解、多媒體素材的分割與分發(fā)以及最終的分段回收與合并等功能都由核心服務(wù)器承擔(dān)，此服務(wù)器同時(shí)管理所有的計(jì)算節(jié)點(diǎn)，并在執(zhí)行轉(zhuǎn)碼任務(wù)過程中對(duì)所有節(jié)點(diǎn)以負(fù)載均衡的方式進(jìn)行調(diào)度。計(jì)算節(jié)點(diǎn)負(fù)責(zé)實(shí)際的轉(zhuǎn)碼運(yùn)算，在預(yù)先配置好一組轉(zhuǎn)碼程序的情況下，由核心服務(wù)器的調(diào)度系統(tǒng)來負(fù)責(zé)啟動(dòng)節(jié)點(diǎn)上的轉(zhuǎn)碼運(yù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研究計(jì)劃中的一款開源軟件系統(tǒng)，它能夠提供高吞吐量的計(jì)算環(huán)境，有效利用那些通過網(wǎng)絡(luò)互連的工作站的計(jì)算能力。同其他分布系統(tǒng)類似，Condor提供任務(wù)排隊(duì)、調(diào)度策略、排序策略和資源管理等功能。本系統(tǒng)利用Condor對(duì)計(jì)算能力的調(diào)度控制來實(shí)現(xiàn)集群轉(zhuǎn)碼功能。

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

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

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

圖2 DAG機(jī)制示例

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

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

3.1 任務(wù)生成

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

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

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

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

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

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

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

圖4 視頻切割示意圖

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

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

圖5 視頻切割代碼流程圖

3.2 結(jié)果生成

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

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]，因此在使用軟件進(jìn)行轉(zhuǎn)碼時(shí)，最為合適的方案就是先將MPEG-2碼流解碼為原始YUV圖像數(shù)據(jù)，再將其編碼為H.264格式，這也就是所謂的“全解全編”轉(zhuǎn)碼方法。項(xiàng)目要求在H.264的編碼中具有許多可調(diào)參數(shù)，這些參數(shù)的設(shè)置是由轉(zhuǎn)碼用戶所決定的，因此利用這種“全解全編”的方法可以方便地調(diào)整編碼器的參數(shù)。圖6是整個(gè)轉(zhuǎn)碼程序的算法流程。

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

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

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)論

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

[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]趙堅(jiān)勇.電視原理與接收技術(shù)[M].北京：國(guó)防工業(yè)出版社，2007.

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