基于眾核平臺的多路超高清視頻編碼系統設計

姚　佳，高志勇，張小云

(上海交通大學 圖像通信與網絡工程研究所， 上海 200240)

基于眾核平臺的多路超高清視頻編碼系統設計

姚佳，高志勇，張小云

(上海交通大學 圖像通信與網絡工程研究所， 上海 200240)

摘要:首次展示一套基于低功耗眾核TILE-36處理器平臺的多路超高清實時系統。該系統可以同時編碼4路HEVC超高清視頻，并經過TS復用后以常碼率的形式發送到解碼端。為了保證編碼系統穩定運行，采取了基于非線性R-Q模型的閉環碼率控制來調整編碼器的輸出碼率，同時引入緩存控制機制來確保系統總延時恒定，最后加入了基于幀數統計的時鐘同步機制來同步系統中各模塊的時鐘。實驗顯示該系統能夠長時間穩定運行，并具有同時編碼4路HEVC超高清視頻的能力。

關鍵詞:多路超高清；眾核；碼率控制；實時系統

為了滿足用戶對更高質量的視頻服務的需求，設備制造商對視頻采集設備和播放設備的性能進行了大幅提升。然而當今主流的視頻編碼器H.264并不能高效地對超高清視頻進行壓縮。視頻編碼聯合組制定了新一代的視頻壓縮標準HEVC。相比于H.264/AVC和HEVC在相同的視頻質量下可以大大提高視頻的壓縮率，但實現復雜度更高[1]。

HEVC繼承了H.264/AVC基于塊的混合編碼架構，并引入了更加靈活的編碼樹塊，自適應樣點補償以及Tile等新特征。在這些新特征中更加靈活的編碼樹塊對HEVC編碼性能提升最大，但這也引入了更多的運算復雜度，從而限制了HEVC編碼器在實時系統中的應用。眾核處理器在一個處理器中集成了幾十甚至上百個完整的可獨立運行程序指令的處理內核，其并行計算能力相比單核處理器有大幅提升。眾核處理器為HEVC并行編碼器提供了一個很好的實現平臺。

本文在實現多路超高清HEVC視頻實時編碼系統過程中，主要解決了幾個關鍵問題。首先，由于更復雜的幀間編碼，HEVC編碼器的輸出碼率相比于上一代標準H.264波動更大。而多路碼流復用后輸出碼率的疊加會使碼率波動加劇。針對這一問題，本文提出了一種閉環碼率控制算法，實現了編碼器的恒定碼率輸出。

其次是系統的端到端延時的問題。端到端延時是直播應用中影響消費者觀看體驗的一個關鍵因素。

閉環碼率控制中引入的緩沖器會增加系統總延時。為了降低總延時，需要盡量減小編碼器輸出緩沖器的大小。這需要對編碼器的碼率控制進行優化，盡量降低編碼器輸出碼率的波動幅度，從而減小緩沖器的大小。

最后是系統中各個模塊時鐘同步的問題。本文提出的多路超高清實時系統由3個模塊構成，包括視頻源、編碼器和解碼器。每個模塊有獨立的本地時鐘。各個模塊之間本地時鐘誤差的累積會造成總延時的偏移，從而影響到系統的穩定運行。MPEG2-TS標準規定編碼器必須周期性地發送本地的節目時鐘參考(PCR)[2]到解碼端，用來同步編碼端和解碼端的時鐘。在此基礎上，本文提出一種時鐘同步機制來同步視頻源和解碼器的本地時鐘。

1實時系統架構

本文基于Tilera公司提供的搭載有4片眾核處理器TILE-Gx36[3]的低功耗平臺，實現了多路超高清視頻實時編碼系統。該平臺配備帶HDMI輸入的FPGA視頻采集卡，用于實時視頻的采集。每片TILE-Gx36處理器上集成了36個獨立的核，單核頻率可達1.2 GHz。每片TILE-Gx36處理器負責編碼一路超高清視頻。為了實現各個處理器之間高效安全可靠的數據傳輸，TILE-Gx36集成了高性能眾核可編程智能包引擎(mPIPE)模塊。

整個系統架構如圖1所示。4路視頻輸入源為1路4K超高清攝像機和3路超高清播放器。首先，FPGA采集卡對輸入的原始視頻進行預處理并轉儲至DDR3內存中。隨后，運行在4片TILE-Gx36處理器的4個HEVC編碼器J265分別對內存中的4路視頻序列進行編碼。然后，編碼器1，2，3通過mPIPE輸出3路TS流到編碼器4。最后，4路TS流打包復用成1路TS流，并通過編碼器4的發送線程，以RTP流方式發送到解碼端。解碼端通過4個解碼器同時解碼4路超高清碼流并顯示。圖2展示了1個編碼器中主要的線程分配。

圖1　多路超高清系統框圖

圖2　線程分配框架

每片TILE-Gx36處理器中的兩個核分別綁定到采集線程和發送線程。采集線程負責獲取4K 原始視頻序列并將原始序列轉存到在內存里開辟的緩沖器中。剩下的34個核用來進行HEVC并行編碼，其中每個核負責編碼一個Tile。當一幀圖像的所有Tile都編碼完成后，編碼器將該幀圖像以ES流的形式輸出到編碼器的碼流緩沖器 (ES buffer) 中。編碼開始后，發送線程開始從ES buffer中讀出數據并完成打包發送工作。該系統中，編碼器輸出碼率不穩以及各模塊時鐘不同步等問題會導致ES buffer上下溢的現象，相應的解決方案在下文詳細描述。

2關鍵機制

2.1碼率控制

該實時系統的碼率控制需要實現兩個目標，一是控制編碼器的輸出碼率，保證輸出緩沖器不發生上下溢；二是在此基礎上盡量不損失視頻質量。本文采用的碼率控制算法在緩存控制的配合下使編碼器達到設定的輸出碼率，畫面質量良好，其流程圖如圖3所示。

圖3　碼率控制流程圖

在編碼一幀原始圖像之前需要對其進行場景檢測。當檢測到某一幀圖像為場景切換幀時，對其采用幀內編碼。由于一個GOP中幀內編碼幀(I幀)的復雜度無法確定，所以每個I幀的量化參數是由之前每個I幀的QP取平均得到。幀間編碼幀(P幀)以及P幀中Tile的量化參數(QP)由非線性R-Q模型[4]計算得到。R-Q模型是基于模糊復雜度來實現的，根據總的模糊復雜度與總的目標比特來計算P幀的QP，計算公式如下

(1)

式中：qscale基于模糊復雜度得到，在一定程度上可以反應編碼單元編碼后的比特數。P幀以及每幀的各Tile的QP通過式(1)得到。qscale的計算過程為

(2)

cplxrSumi=cplxrSumi-1+tilebit

式中：cplxrSumi表示第i個編碼單元的預測復雜度。對于人眼不敏感的高細節復雜度或者高運動場景，可以增加QP而不會損失太多的視覺質量。因此，對于cplxrSum越大的編碼單元，經計算得到的QP也越大，編碼后生成的比特數相應也越少，反之亦然。wantedBitsi是累計的總目標比特數，qscaleinit為根據經驗得到的一個初始值。tilebit為編碼一個tile的實際比特數，cplxrSumi-1為前一個編碼單元的復雜度。tile_num為一幀劃分的tile個數，wantedBitsi-1為前面所有編碼單元的預測復雜度，framerate為編碼幀率，Bitrate為設定的編碼器輸出碼率。考慮到圖像質量的平滑，一幀圖像中每個Tile的QP必須限制在[frame_QP-2，frame_QP+2]之間。為了保證畫面質量的連續性[5]，相鄰兩幀圖像之間的QP差值限制在[-2，2]區間內。

本文根據已編碼比特和緩沖區狀態動態的調整碼率控制中求得的QP值，實現了閉環碼率控制。作為閉環碼率的一部分，本文在緩存控制中設置了兩個上溢閾值overflow1和overflow2以及下溢閾值underflow來協助碼率控制，如圖4所示。

圖4　編碼器輸出緩沖器功能框圖

當ES buffer的占有量達到overflow2時，編碼單元QP加2。當ES buffer的占有量上升到overflow1時，編碼單元的QP加3，從而減小編碼器的輸出比特數。設置兩個上溢閾值是為了防止ES buffer的緩存出現較大波動，引起圖像QP波動，從而導致視頻質量不穩定。ES buffer的占有量降低到underflow時，QP減2。當ES buffer出現下溢的時候，通過插入TS填充包來保證ES buffer的輸出碼率恒定。

2.2延時控制

在不考慮編碼和解碼時間的前提下，常碼率系統的端到端延時主要是由編碼器輸出緩沖器和解碼緩沖器帶來的。常碼率系統的初始延時delay為

delay=ES_init_delay+DTS0-PCR0

(3)

式中：ES_init_delay為設定的ES buffer的初始緩存時間；DTS為一幀圖像的解碼時間戳，用來指示解碼器在規定的時刻解碼該幀；PCR為每路節目的節目時鐘參考，用來將解碼器的本地時鐘同步到編碼器的本地時鐘[2]；DTS0為視頻流中第一幀的解碼時間戳；PCR0為發送給解碼器的第一個PCR。因為PCR0將解碼器的本地時鐘校正到PCR0，而DTS0指定解碼器要等到DTS0時刻才能開始解碼第一幀，所以當二者同時到達解碼器時，二者的差值代表了解碼緩沖器的初始緩存量。當某一幀的DTS小于當前解碼器的系統時間時，解碼器會丟棄該幀。此時由于沒有可供解碼的圖像，解碼緩存器處于下溢狀態。

實時系統端到端的總延時計算如下

(4)

式中：ES_occupancy為當前編碼器輸出緩沖器中緩存的數據量。DTS-PCR表示當前幀在解碼緩沖器中需要等待的時間，即解碼緩沖器的緩存大小。當實時系統運行過程中延時恒定時，式(6)中的delay等于式(5)的delay，即系統總延時始終等于初始延時。同時為了防止解碼緩沖器出現下溢，PCR須小于DTS，故由式(6)可知

ES_occupancy≤delay×bitrate

(5)

在保證ES buffer不出現上溢的前提下，只要滿足式(8)，式(7)則一定成立

ES_buffer_size=bitrate×delay

(6)

將式(8)代入式(6)可以得到

ES_buffer_size=ES_occupancy+(DTS-PCR)×

bitrate

(7)

由式(5)和(9)可知，當設置ES_init_delay與(DTS0-PCR0)×bitrate之和等于ES buffer的大小時，系統運行過程中只要保證ES buffer不發生上溢，解碼緩沖器就不會發生下溢。因此兩個buffer的緩存量之和始終等于ES buffer的大小，實時系統運行過程中可以保持延時恒定。

由式(8)可知，減小ES buffer的大小是降低系統端到端延時的關鍵。故本文采取閉環碼率控制方案，通過向碼率控制實時反饋ES buffer的緩存量來達到減小輸出碼率波動的目的，從而使ES buffer盡可能小，系統延時也更低。

2.3系統時鐘同步

假設視頻源的輸出幀率為F。編碼器按照本地時鐘接收到的實際幀率F′可以表示為

(8)

式中：camera_clock和encoder_clock分別代表攝像機(視頻源)和編碼器的本地時鐘頻率；F為攝像機的輸出幀率即編碼器默認的視頻幀率。由式(10)可知，camera_clock低于encoder_clock會導致F′高于F。比如視頻源的輸出幀率為30 f/s(幀/秒)，但由于時鐘頻率的差異，編碼器實際接收到的幀率為30.03 f/s。此時因為碼率控制中每幀圖像的目標比特數等于目標碼率除以幀率F，所以每幀圖像編碼出來的實際比特數偏大，從而導致編碼器的實際輸出碼率始終高于目標碼率。這樣會使ES buffer一直處于上溢狀態。在這種情況下，閉環碼率控制會調整編碼圖像的QP，使其一直處于最大值，圖像質量因此不斷惡化。

為了同步編碼器和視頻源的時鐘，需要得到二者之間的比例關系。本文通過統計編碼器每接收100×F幀的時間作為視頻源的一百秒，得到二者時鐘之間的差值，見步驟1)和步驟2)，然后利用這個統計時間調整PCR，從而使解碼器的時鐘同步到視頻源上。相應的PCR校正機制如下：

1)編碼器連續獲取100×F幀圖像，統計編碼器該時段的系統時間t。

2)計算Δt=|t-100|，Δt大于PCR校正閾值轉到步驟3)，小于則轉到步驟4)。

3)PCR的校正值PCR_adjust_step=Δt/(20×count)。其中count為發送線程每秒的發送PCR次數。每100 s累積的誤差在后續20 s內校正，所以再除以20。然后轉至步驟1。

4)將Δt累加到下100 s的Δt中，然后轉至步驟1)。

因為編碼器的輸出碼率等于數據流中相鄰兩個PCR之間的比特數除以兩個PCR的差值，所以為了匹配編碼器實際的輸出速率，輸出緩沖器每次輸出的數據量也要根據PCR的調整幅度作相應的調整。ES buffer每次輸出的數據長度應為

(9)

實驗結果證明該時鐘同步方案能有效防止編碼器輸出緩沖器的上下溢從而使系統穩定運行。

3實驗結果

3.1實驗條件

視頻源為1臺4K超高清攝像機和1臺多路超高清播放器，通過4根HDMI1.4線連接到眾核平臺上。每路編碼器的配置參數如表1所示。

表1單路編碼器配置參數

參數參數值或說明比特率/(Mbit·s-1)6幀率/(f·s-1)15GOP結構IPPPESBuffer初始緩存/Mbit3DTS-PCR初始值/s0.5ESBuffer大小/Mbit6

3.2實驗結果

解碼器能夠實時播放四路超高清節目，播放過程中沒有發生卡頓或者卡死的現象，圖像質量良好。實驗結果顯示單路節目的端到端延時約為1～2 s，4路節目總的輸出碼率為24 Mbit/s，同時本文提出的碼率控制和時鐘同步機制能有效避免ES buffer發生上下溢。整個系統能夠長時間穩定運行。

圖5為演示實物圖。其中1臺4K攝像機和1臺多路超高清視頻碼流儀作為眾核TILE-Gx36處理器平臺的輸入。眾核平臺通過1根網線連接到解碼器。解碼器通過4路HDMI1.4將解碼后的視頻輸出到顯示器上進行播放。

圖5　演示實物圖

4小結

本文基于TILE-Gx36眾核平臺實現了一個多路超高清實時系統，并針對HEVC編碼器輸出碼率波動較大提出了一個有效的應用于實時系統中的碼率控制方案。同時，本文還提出了相應的延時控制機制和時鐘同步機制，使系統在常碼率信道中能穩定運行并保證端到端延時恒定。實驗結果顯示本文提出的系統擁有同時實時編碼4路4K HEVC視頻的能力，即該系統擁有編碼8K視頻的能力。

參考文獻：

[1]POURAZAD M T， DOUTRE C， AZIMI M， et al. HEVC： the new gold standard for video compression：how does HEVC compare with H. 264/AVC?[J]. IEEE transations on consumer electronics magazine，2012， 1(3)：36-46.

[2]IEC I S O. 13818-1, Information technology generic coding of moving pictures and associated audio information： systems[S].1996.

[3]Tilera.[EB/OL].[2015-11-13]. http：//www.tilera.com/.

[4]LIU Y， LI Z G， SOH Y C. A novel rate control scheme for low delay video communication of H.264/AVC standard[J]. IEEE transations on circuits and systems for video technology， 2007， 17(1)：68-78.

[5]WU J， CAI J. Quality-smoothed encoding for real-time video streaming applications[C]//Proc. the Ninth International Symposium on Consumer Electronics， 2005(ISCE 2005). [S.l.]：IEEE，2005：445-449.

姚佳，碩士生，主要研究視頻編解碼傳輸；

高志勇，博士生導師，主要研究高速圖像與視頻處理、數字電視等；

張小云，碩士生導師，主要研究方向為視頻編解碼、高速視頻處理等。

責任編輯：時雯

Multi-channel UHD video encoding system based on many-core platform

YAO Jia，GAO Zhiyong，ZHANG Xiaoyun

(ImageCommunicationandNetworkEngineeringInstitute，ElectronicEngineering，ShanghaiJiaoTongUniversity，Shanghai200240，China)

Abstract:In this paper， a multi-channel ultra-high definition (UHD) encoding real-time system is presented for the first time， which is based on the many-core TILE-Gx36 processors platform with low-power consumption. This system can simultaneously encode four UHD video inputs in HEVC， and transmit the encoded streams to the decoder after the MPEG transport stream (TS) multiplexing in constant bitrate (CBR). To ensure the system running stable， a closed-loop rate-control mechanism based on nonlinear R-Q model to adjust the output bitrate of encoder is proposed， and a buffer-control mechanism is used to make the system latency constant， in the end a clock synchronization mechanism based on the statistics of frame number is proposed to synchronize the clocks in the real-time system. Experiments show that the proposed system can keep stable running for a long time， and has the capacity of encoding 4-channel UHD video simultaneously.

Key words:HEVC； multi-channel UHD； many-core； rate control； real-time system

中圖分類號：TN949.292

文獻標志碼:B

DOI：10.16280/j.videoe.2016.04.002

基金項目：國家自然科學基金項目(61301116)

作者簡介：

收稿日期：2015-11-16

文獻引用格式：姚佳，高志勇，張小云. 基于眾核平臺的多路超高清視頻編碼系統設計[J].電視技術，2016，40(4)：7-11.

YAO J，GAO Z Y，ZHANG X Y. Multi-channel UHD video encoding system based on many-core platform [J].Video engineering，2016，40(4)：7-11.