面向在線制作的集群轉碼系統設計*

孫思慧，孫 軍，王興東

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

1 引言

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

2 集群轉碼系統設計

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

2.1 集群轉碼系統的構成

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

圖1 集群轉碼系統整體架構

2.2 Condor調度系統

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

Condor系統利用一種稱為ClassAd的機制來提供一個極端靈活的架構，從而實現任務與資源之間的匹配。在用戶提交任務時可以標明需要滿足的要求和一些參數，同樣，在配置Condor系統中的設備資源時也可以指明該設備對希望執行的任務的要求和參數。通過這兩組要求和參數，系統會為任務尋找網絡中的可用計算資源，然后在那里執行任務。

另外，Condor系統中提供了一種名為有向非循環圖（Directed Acyclic Graph，DAG）的任務提交機制。利用 DAG可以表示一組有依賴關系的任務，用DAG描述文件可以將一個或一組任務設置為另外一個或一組任務的子任務。

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

圖2 DAG機制示例

3 集群轉碼系統的實現

集群轉碼系統按照上一章所述的架構完成硬件環境搭建，而軟件部分的實現則包括任務生成、轉碼程序、結果生成等幾個部分。

3.1 任務生成

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

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

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

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

圖3 典型的GoP幀結構圖

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

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

圖4 視頻切割示意圖

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

圖5是本文所設計的集群轉碼系統中針對視頻分割的代碼流程框圖。這里所實現的視頻分割均是基于MPEG-2的TS流所設計的。

圖5 視頻切割代碼流程圖

3.2 結果生成

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

3.3 轉碼程序

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

圖6 視頻轉碼程序流程

MPEG-2解碼和H.264編碼均采用了調用函數庫的形式，其中MPEG-2解碼開始采用的是ffmpeg；H.264編碼則采用的是X264開源工具庫。后處理部分主要是指對H.264碼流的幀順序的調整，以及調用函數庫時所分配的數據結構的內存釋放。

4 系統測試分析

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

圖7 condor_status命令顯示設備池信息

表1 集群轉碼設備配置信息

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

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

根據上述分割片段大小的分析可以發現，有一條重要的切割依據是集群設備的數量。

從圖8中可以明顯地看到轉碼時間隨終端個數而減少的趨勢。這樣的減少是有一定前提的，即轉碼的目標數據大小相同，且分割的子視頻個數也是相同的。根據以上數據，可以得到的結論是：轉碼時間在轉碼源數據一定時隨集群終端個數的增加而減少。圖8中的黑色虛線是根據現有數據所擬和的二次曲線，并作了適當的延展，可以明顯地看到曲線逐漸隨終端數目的增大而趨于飽和。

圖8 計算節點數目與轉碼效率的關系

圖8中的數據表明，當集群數量達到一定規模之后，完全可以超過單機軟件轉碼的效率。之所以在集群數量較少的情況下多機轉碼反而比單機的時間更長，是因為集群調度系統在任務調度上的時間消耗延長了任務執行時間。這些時間損耗包括：DAG機制的初始化時間和數據的網絡傳輸時間。

當然，轉碼時間肯定不會隨終端個數的增加而不斷減小，在終端數目增加到一定程度時，必然對本地網絡傳輸產生相當的壓力，并由此產生了瓶頸，導致轉碼時間趨于飽和，甚至反向增加。

5 結論

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

[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]趙堅勇.電視原理與接收技術[M].北京：國防工業出版社，2007.

[5]孫景琪，孫京.數字視頻技術及應用[M].北京：北京工業大學出版社，2006.