葉朝敏，陳穎琪，高志勇

（上海交通大學電子工程系圖像通信與信息處理研究所，上海 200240）

隨著網(wǎng)絡(luò)與個人通信終端的發(fā)展，人們對于視頻的要求已經(jīng)越來越強烈。H.264視頻壓縮標準在提供了優(yōu)異的壓縮比的同時，保證了出色的解碼視頻質(zhì)量，是窄帶視頻傳輸?shù)睦硐脒x擇，已經(jīng)越來越廣泛地應用于在線視頻中。與此同時，目前已有的視頻數(shù)據(jù)源，包括電影、電視等依舊采用MPEG－2編碼。如果可以將MPEG－2視頻源轉(zhuǎn)化成為H.264，則可以極大地擴充H.264的節(jié)目來源，進一步豐富人民群眾的精神文化生活。

H.264的出色性能是建立在龐大的運算量的基礎(chǔ)上的，H.264雖然比MPEG－2節(jié)約了約50%的碼率，但是付出的代價卻是MPEG－2 3倍以上的編碼計算復雜度。對于高清（本文特指分辨率為1 920×1 080的視頻）實時的MPEG－2至H.264轉(zhuǎn)碼器，目前尚未有快速高效且效果顯著的快速轉(zhuǎn)碼算法，采用全解全編的轉(zhuǎn)碼器又面臨著龐大的計算復雜度的問題。

并行計算為實時實現(xiàn)高清MPEG－2至H.264轉(zhuǎn)碼器提供了切實可行的解決方案。良好設(shè)計的并行轉(zhuǎn)碼器可以提供接近線性的加速比，即便對于計算量最大的全解全編轉(zhuǎn)碼器，利用目前常見的四核處理器也能在原先1/4的時間內(nèi)完成轉(zhuǎn)碼，對于核數(shù)更多的處理器，則能更進一步實現(xiàn)多路高清實時轉(zhuǎn)碼。

本文針對以往研究中存在的問題，提出并實現(xiàn)了1種采用了幀級、片級與數(shù)據(jù)級混合并行的多粒度高清實時全解全編轉(zhuǎn)碼方案，并在Tilera［1］公司Tile Pro64同構(gòu)多核平臺上成功應用。

1 研究現(xiàn)狀

在并行程序設(shè)計中，功能分解與數(shù)據(jù)分解是常用的2種方法。具體到編解碼器設(shè)計中，1幀數(shù)據(jù)通常由若干個宏塊行組成，因此具有天然的數(shù)據(jù)可分解性。編解碼器采用了模塊化設(shè)計，每個功能模塊任務明確，具有較好的功能可分解性。

在MPEG－2解碼器設(shè)計中，最常用的并行設(shè)計方法是幀內(nèi)數(shù)據(jù)分解。由于MPEG－2碼流中1幀內(nèi)各個宏塊行（片）的解碼互不相關(guān)，因此可以將不同宏塊行的解碼任務放在不同的核上進行［2］。

采用幀間并行的MPEG－2解碼設(shè)計則相對復雜。解碼器設(shè)計中，由于運動向量搜索范圍可以包含一整幀數(shù)據(jù)，P幀的解碼有可能需要用到I幀的完整數(shù)據(jù)，因此I幀與P幀之間很難實現(xiàn)并行。然而對于IBBPBBP的碼流結(jié)構(gòu)，可以在所有B幀的參考幀均解碼完畢之后，對所有B幀進行幀級的并行解碼［3］。對于非實時碼流，采用GoP分組也是1種可行的幀間并行方案［4］。

除此之外，并行MPEG－2解碼器還可以采用基于功能分解的設(shè)計方案，即采用流水線設(shè)計，將解碼過程的不同模塊分配到不同的核上以實現(xiàn)并行。然而功能分解的可擴展性較差［5］，因此基于功能分解的編解碼器研究并不多。

并行H.264編碼器的研究主要突破點同樣在于數(shù)據(jù)分解。數(shù)據(jù)分解重點在于設(shè)計并行的顆粒度:顆粒度過大，則容易出現(xiàn)空閑核等待狀況;顆粒度過小，則會出現(xiàn)通信量過大，影響CPU真正執(zhí)行編解碼核心任務。

早期的研究主要集中于單一顆粒度的并行。從顆粒度最大的GoP級幀間并行［4］，到顆粒度降低的幀級并行與片級并行［6－7］，一直到顆粒度更低的宏塊或者宏塊組級并行［3，8－9］，甚至于為加速編解碼而引入的指令集（本文中也稱為數(shù)據(jù)級）并行［10］，均有相關(guān)文獻發(fā)表。單一顆粒度的并行一定程度上提高了編碼速度，然而很遺憾的是此種并行引入的并行加速比均較為有限。

相比較單顆粒度并行，采用多顆粒度的并行編碼器則展現(xiàn)出了優(yōu)異的性能?；旌喜捎肂幀并行、片級并行、宏塊級并行以及數(shù)據(jù)級并行的設(shè)計在碼率增長4%的基礎(chǔ)上獲得了34倍左右的性能提升［3］。事實上，各級并行雖然較為獨立，但是在編碼過程中可以完美地融合在一起。幀級并行調(diào)用幀內(nèi)并行，幀內(nèi)并行調(diào)用宏塊級并行，宏塊級并行調(diào)用數(shù)據(jù)級并行，各級并行完成各自任務，最終完成編碼。多顆粒度并行編碼器中，可以通過良好的任務分配，保證適中的顆粒度，避免出現(xiàn)過久的空閑和等待，并且也不會出現(xiàn)通信量過大的情況。

本文實現(xiàn)了1種全解全編的實時并行MPEG－2至H.264轉(zhuǎn)碼器。在解碼端，可以對任何符合MPEG－2標準的碼流進行解碼;在編碼端，目前僅支持Baseline的H.264編碼。本文的MPEG－2并行解碼器采用了常見的片（1個宏塊行）級并行與數(shù)據(jù)級并行混合并行算法，H.264編碼器則采用了獨特的幀級并行、片（若干個宏塊行）級并行、數(shù)據(jù)級并行的多粒度混合并行模型。

2 并行轉(zhuǎn)碼器設(shè)計方案［11－12］

本設(shè)計由主線程與包含若干個線程的線程池以及包含若干個任務的任務池組成。其中主線程負責初始化線程池以及創(chuàng)建幀級并行任務等，任務池負責完成具體的編解碼任務。為了管理好任務池，本設(shè)計中實現(xiàn)了1個用戶態(tài)的調(diào)度器。調(diào)度器遍歷任務池查找依賴性滿足的，即可以被執(zhí)行并行任務并分配給空閑的線程執(zhí)行，對應線程完成該任務之后便會將該任務移除出任務池。

2.1 并行MPEG－2解碼器設(shè)計

在MPEG－2碼流中，1個宏塊行為1個片（Slice），碼流start_code中包含了片的序號，其變化范圍由slice_min_start_code，slice_max_start_code確定。由于各個片之間不具有任何相關(guān)性，因此MPEG－2碼流具有天然的幀內(nèi)可并行性。

在解碼分辨力為1 920×1 080的高清碼流時，共有［1 080/16］≈68個片，如果以每個片的解碼作為1個基本的并行任務，每1個基本并行任務顆粒度較小，總計有68個并行基本任務，對于核數(shù)少于8的處理器而言，任務數(shù)已經(jīng)足夠，因此不再引入幀間并行。當處理器核數(shù)更多時，可以引入基于B幀的幀間并行［3］，進一步提升基本并行任務個數(shù)，以便進一步提高加速比。

單獨的并行MPEG－2解碼器流程圖如圖1所示。

圖1 并行MPEG－2編碼流程圖

主線程首先從輸入碼流中通過搜索截出解碼1幀所需的碼流數(shù)據(jù)，隨后對截出的碼流進行解析，在解析到slice_header的時候開始創(chuàng)建片級并行任務，各個片級任務經(jīng)調(diào)度器管理在不同的線程上獨立完成，主線程在等待1幀的所有片均解碼完并輸出1幀之后開始解碼下1幀，如此往復，直至碼流解碼完畢。

2.2 并行H.264編碼器設(shè)計

2.2.1 幀級并行

運動搜索引入的幀間依賴性阻礙了幀級并行的實現(xiàn)。為了解決此問題，可以將1幀數(shù)據(jù)進行分片編碼，人為規(guī)定運動向量搜索范圍為其參考幀對應的片的高度。假設(shè)1幀的每1個片由numMbr個宏塊行組成，為了保證數(shù)據(jù)的依賴性得到滿足，第N幀開始編碼后，第N+1幀可以在第N幀的［numMbr/2］宏塊行編碼完成之后才開始編碼。在第N+1幀編碼到某一個Slice時，會檢測第N幀對應的Slice是否已經(jīng)編碼完成（此處只考慮Baseline不包含B幀的情形，如果包含B幀，則需要檢測第N+1幀所依賴的參考幀對應的Slice編碼完成情況），只有在第N幀對應的Slice已經(jīng)編碼完成后才會真正開始對第N+1幀進行編碼。

本文實驗所用的多核平臺為同構(gòu)多核，各核處理速度可認為一致，第N+1幀由于落后第N幀［numMbr/2］個宏塊行，因此第N+1幀的某個Slice需要等待第N幀對應Slice編碼完成的可能性比較小，幀間并行性非常高。另一方面，由于每1幀相對于前1幀編碼都要落后［num-Mbr/2］個宏塊行的處理時間，因此無限增加幀間并行以提高速度意義不大。實際實現(xiàn)時需要根據(jù)核的個數(shù)調(diào)整可以并行的幀數(shù)。

2.2.2 片級并行

如前所述，本設(shè)計將1幀數(shù)據(jù)分成若干個片進行獨立編碼。1個幀級編碼任務僅僅是接收來自上層的參數(shù)并根據(jù)對應的參數(shù)創(chuàng)建多個片級編碼任務。調(diào)度器隨后將片級的編碼任務分發(fā)到各個核上同時執(zhí)行，各個片編碼完成之后再將各個片的碼流重組在一起進行輸出（例如寫入文件或者封包成RTP數(shù)據(jù)包）。

產(chǎn)生了片級的并行任務之后，可以根據(jù)核的個數(shù)決定是否采用更小粒度的并行。如果并行幀數(shù)為4，幀內(nèi)片數(shù)為14（即5個宏塊行為1個片），則理論上最多同時有4×14=56個顆粒度較小的并行任務，對于10個核以下的處理器，任務數(shù)已經(jīng)足夠。此外，引入分片之后，由于幀內(nèi)相關(guān)性降低［3，9］，會導致編碼之后碼率增大，因此雖然分片可以增大并行加速比，但是不可能為了提高編碼速度無限提高分片數(shù)。實現(xiàn)時分片數(shù)可以根據(jù)具體性能予以調(diào)整。

對于本設(shè)計，并行任務細化到片級并行任務時任務數(shù)已經(jīng)足夠，因后不再進行粒度更小的宏塊級并行。此時1個片級并行任務包含了如下功能:

1）接收來自上層的參數(shù)并存取。由于采用了并行設(shè)計，很多參數(shù)都會隨著并行的出現(xiàn)發(fā)生改變，因此在進行真正的片級編碼之前，需要首先備份來自上層的有關(guān)參數(shù)。

2）幀內(nèi)數(shù)據(jù)從變換量化預測補償?shù)届鼐幋a的一整套編碼流程。每片的編碼任務僅僅會在該片所需數(shù)據(jù)已經(jīng)準備就緒的時候才開始，因此一旦并行任務開始執(zhí)行時，該片編碼已經(jīng)不用考慮依賴性問題，保證了高效并行。

3）各片已編碼碼流整合。分片編碼之后需要按照各片順序?qū)⒋a流重組最后有序輸出。

2.2.3 數(shù)據(jù)級并行（指令級并行）

數(shù)據(jù)級并行，或者指令級并行，是指利用處理器提供的多媒體處理指令集（例如Intel SSE/SSE2指令集、Tilera［1］公司的SIMD指令集等）中提供的SIMD（Single Instruction Multiple Data）指令對編碼過程中的一些核心計算模塊進行優(yōu)化所引入的并行。

采用數(shù)據(jù)并行不需對編碼器并行框架進行任何修改，使用方便，但是所引入的并行加速比卻非?？捎^。本設(shè)計采用Tilera公司SIMD指令優(yōu)化離散余弦變換、運動補償、去塊濾波、量化等模塊之后，可以引入5倍以上的并行加速比提升。然而由于指令集并行涉及模塊多，且數(shù)據(jù)并行的加速比提升受限于上層編碼器設(shè)計，因此很難事先估計單純引入指令集所帶來的并行加速比。

2.3 并行轉(zhuǎn)碼器設(shè)計

并行轉(zhuǎn)碼器設(shè)計流程圖如圖2所示，圖中粗箭頭是指在線程任務池中完成的任務。

解碼函數(shù)并行框架類似于圖1中所示的單獨解碼器，解碼函數(shù)與編碼函數(shù)之間的聯(lián)系除了用于緩存解碼器輸出的YUV緩沖區(qū)以及YUV緩沖區(qū)對應的可讀可寫標志之外，再沒有別的聯(lián)系。此外，具體的并行解碼任務與并行編碼任務都被放置在線程任務池中，由調(diào)度器統(tǒng)一管理。具體流程描述如下:

1）主線程首先初始化MPEG－2解碼器與H.264編碼器，創(chuàng)建YUV緩沖區(qū)隊列并設(shè)置所有緩沖區(qū)可寫標志，隨后讀入MPEG－2碼流。

2）主線程檢查YUV緩沖區(qū)隊列對應YUV緩沖區(qū)是否可寫。若可寫，則調(diào)用并行解碼函數(shù)解析碼流并創(chuàng)建并行解碼基本任務（在主線程中）。若不可寫，即代表該緩沖區(qū)正在被編碼器使用，解碼器暫停直至該緩沖區(qū)可寫標志重新被設(shè)置。

3a）主線程等待一幀數(shù)據(jù)解碼完畢。

3b）調(diào)度器調(diào)度各線程執(zhí)行具體的解碼任務。

4a）1幀數(shù)據(jù)解碼完畢之后主線程輸出解碼產(chǎn)生的YUV數(shù)據(jù)至YUV緩沖區(qū)中并清空該緩沖區(qū)對應的可寫標志。之后主線程調(diào)用編碼函數(shù)創(chuàng)建幀間并行任務。主線程隨后繼續(xù)解碼下1幀。

4b）調(diào)度器調(diào)度線程執(zhí)行幀間并行任務以及其后的片級并行任務。1幀YUV數(shù)據(jù)編碼完畢之后輸出該幀碼流并設(shè)置緩沖區(qū)可寫標志。

上述流程中，包含3b）的任務是計算量最大的任務，由調(diào)度器管理，由各工作線程完成，其余任務由主線程完成。上述流程除了4a）依賴于3b）之外（不包括由于緩沖

圖2 轉(zhuǎn)碼器流程圖

區(qū)引入的等待），主函數(shù)與線程任務池之間沒有依賴。從而保證了二者都可以各自執(zhí)行自己的任務，提高了效率從而保證了較高的并行性。實際實現(xiàn)時，YUV緩沖區(qū)隊列的長度可以根據(jù)具體性能以及可用的內(nèi)存資源確定一個較為合理的值:當緩沖區(qū)隊列長度較小時，容易造成編碼器與解碼器過多的等待，影響轉(zhuǎn)碼器性能;而隊列過長，并不能帶來太多性能的提升，反而造成內(nèi)存資源的浪費。

3 Tilera平臺并行轉(zhuǎn)碼器實現(xiàn)

3.1 Tilera平臺簡介

本設(shè)計的實現(xiàn)平臺即采用Tilera公司Tile Pro64處理器的計算服務器。該處理器由64個同構(gòu)的核構(gòu)成，單核頻率最高為866 MHz。核間通信通過Tilera公司獨特的核間互聯(lián)技術(shù)實現(xiàn)，保證了極高的吞吐率與極小的時延，是實現(xiàn)多核設(shè)計或者眾核設(shè)計的出色的實驗平臺。此外，服務器共有4個DDR2 667控制器，每個控制器控制2 Gbyte內(nèi)存，共8 Gbyte內(nèi)存。

3.2 Tilera平臺并行轉(zhuǎn)碼器性能

本設(shè)計測試了3個 MPEG碼流，即:CrowdRun（25 Mbit/s），Tractor（25 Mbit/s）以及 Life（25 Mbit/s），轉(zhuǎn)換之后的H.264碼流碼率為6 Mbit/s。

通過比較YUV緩沖隊列長度對于轉(zhuǎn)碼性能的影響，最終確定的YUV緩沖區(qū)隊列長度為4。

3.2.1 并行線性

并行線性是指并行設(shè)計的加速比隨著核數(shù)的增多而線性增長的性質(zhì)。對于一個并行設(shè)計的轉(zhuǎn)碼器而言，線性無疑是最重要的性質(zhì)。對相同碼率不同碼流轉(zhuǎn)碼速度的測試結(jié)果如圖3所示。

圖3 相同碼率不同碼流轉(zhuǎn)碼結(jié)果

可以看到，在核數(shù)較少的時候（10個核以下），本設(shè)計有著接近線性的并行加速比:10個核時加速比達到了9.8。隨著核數(shù)的增多，核間通信以及不同任務之間同步隨之增多，處理器進行真正編解碼工作的時間減少，并行加速比提升逐漸放緩，16個核時，并行加速比為12.8?？梢韵胂?，隨著核數(shù)的增多，并行加速比增加的趨勢會逐漸趨緩直至最后緩慢下降。本設(shè)計在16個核時即可滿足實時高清轉(zhuǎn)碼的需求，為了充分利用處理器資源，可以使用處理器進行多路并行轉(zhuǎn)碼。

3.2.2 轉(zhuǎn)碼實用性

轉(zhuǎn)碼器實用性取決于轉(zhuǎn)碼器的速度以及轉(zhuǎn)碼的有效性，即轉(zhuǎn)碼前后視頻的質(zhì)量差。前者取決于并行設(shè)計的線性，后者則主要取決于MPEG－2與H.264標準本身。

使用16個核對3個高清MPEG－2碼流進行轉(zhuǎn)碼測試，所得結(jié)果如表1所示。

表1 16個核轉(zhuǎn)碼速度

從表1可以看出，對于運動較復雜的Crowdrun序列，本設(shè)計平均轉(zhuǎn)碼速度依然達到了30 f/s以上。實驗顯示，采用18個核時便可使該序列的每1幀都在1/30 s的時間內(nèi)完成轉(zhuǎn)碼，從而滿足實時性要求。

為了進一步驗證轉(zhuǎn)碼有效性，圖4列出了轉(zhuǎn)碼前后圖像的對比，該圖像來自于碼流中的第10幀圖像。

圖4 轉(zhuǎn)碼前后圖像對比圖

4 總結(jié)

本文設(shè)計并在TilePro64平臺上實現(xiàn)了1種MPEG－2至H.264的全解全編并行轉(zhuǎn)碼器。其中MPEG－2解碼采用了片級并行與數(shù)據(jù)級并行，H.264編碼采用了幀級、片級以及數(shù)據(jù)級混合并行。實驗表明，本設(shè)計有著出色的并行加速比，并且在只占用TilePro64處理器中1/4數(shù)量的核的時候，即可實現(xiàn)1路高清實時轉(zhuǎn)碼。

：

［1］Tilera［EB/OL］.［2012－03－20］.http://www.tilera.com/.

［2］許潔斌，韋崗，布禮文.多處理器MPEG2并行解碼系統(tǒng)的設(shè)計［J］.數(shù)據(jù)采集與處理，1998，13（4）:367－373.

［3］于海清，李江，魏海濤.基于同構(gòu)多核處理器的H.264多粒度并行編碼器［J］.計算機學報，2009，32（6）:1100－1109.

［4］蔣興昌，周軍，羅傳飛.H.264并行編碼算法的研究［J］.電視技術(shù)，2008，32（2）:33－35.

［5］LIN C，SNYDER L.Principles of parallel programming［M］.陸鑫達，林新華，譯.北京:機械工業(yè)出版社，2009.

［6］GE S，TIAN X，CHEN Y K.Efficient multithreading implementation of H.264 encoder on Intel hyper－threading architectures［C］//Proc.the 2003 Joint Conference of the Fourth International Conference.［S.l.］:IEEE Press，2003:469－473.

［7］CHEN Y K，TIAN X，GE S，et al.Towards efficient multi－level threading of H.264 encoder on Intel hyper－threading architectures［C］//Proc.the 18th InternationalParalleland Distributed Processing Symposium.［S.l.］:IEEE Press:63－72.

［8］孫書為，陳書明.高效的H.264并行編碼算法［J］.電子學報，2009（2）:357－362.

［9］馮飛龍，陳耀武.基于H.264實時編碼的多核并行算法［J］.計算機工程，2010（24）:226－227.

［10］ZHOU X，LI E Q，CHEN Y K.Implementation of H.264 decoder on general purpose processors with media instructions［C］//Proc.the SPIE Conference on Image and Video Communications and Processing.Bellingham:SPIE－IS＆T，2003:224－235.

［11］田韜，李鵬，張悠慧.H.264并行解碼的設(shè)計與實現(xiàn)［J］.微計算機信息，2008（14）:114－115.

［12］郭倩，陳耀武.基于功能模塊的H.264并行解碼算法［J］.計算機工程，2010（23）:231－233.