鄧 剛,高志勇,張小云
(上海交通大學電子工程系圖像通信與網(wǎng)絡工程研究所,上海200240)
視頻是人類娛樂活動的一種主要方式之一。H.264/AVC是目前最通用的一種視頻壓縮標準,在保證視頻高質(zhì)量的同時降低對存儲空間以及傳輸帶寬的需求。隨著社會的進步,人類對視頻質(zhì)量的要求越來越高,高分辨率視頻正是其中的一項重要需求。超高清視頻編碼存在數(shù)據(jù)吞吐量大、計算復雜度高、碼流碼率大的特點和難點。多核處理器處理性能的提升以及通信網(wǎng)絡的發(fā)展使得超高清實時H.264視頻編碼成為可能。
H.264視頻編碼具有很高的計算復雜度,而超高清(本文特指3 840×2 160的視頻)視頻編碼的復雜度至少是是高清(1 920×1 080)視頻編碼的3~4倍。具有強大運算處理能力的多核處理器為視頻并行編碼提供了良好的平臺基礎,通過合理地設計視頻編碼的并行任務劃分與調(diào)度,充分運用多核處理器的并行能力,能夠達到實時的要求。處理器性能的提升解決了視頻編碼計算復雜度高的問題。同時因超高清的巨額數(shù)據(jù)量,編碼過程中像素的存取也是編碼器性能的瓶頸之一。根據(jù)視頻編碼的特點以及操作系統(tǒng)內(nèi)核的內(nèi)存管理機制,本系統(tǒng)設計的高效內(nèi)存管理方案將有利于提升編碼速度與視頻質(zhì)量。
本文以Tilera[1]公司的TILE-Gx36處理器為核心,設計與實現(xiàn)了超高清實時H.264編碼系統(tǒng)。其中攝像機負責采集超高清原始視頻序列,F(xiàn)PGA板卡負責視頻序列預處理,多核處理器負責視頻編碼與RTP[2]格式封裝,實現(xiàn)視頻單播功能。
編碼系統(tǒng)由超高清攝像機采樣得到原始的YUV序列,F(xiàn)PGA采集板對原始的YUV序列進行預處理并存儲至內(nèi)存中,TILE-Gx36處理器對內(nèi)存中的視頻序列編碼并封裝成RTP格式輸出。系統(tǒng)的流程包括3個步驟,如圖1所示。
圖1 超高清編碼系統(tǒng)
1)原始視頻序列采集
超高清攝像機負責采樣原始視頻序列,支持的超高清格式包括24 f/s與60 f/s序列。攝像機輸出包括4路HDMI口,其中每路HDMI支持1.3規(guī)范,可輸出1 920×1 080分辨率的視頻序列。4路HDMI輸出均連接至FPGA采集板的輸入口。
2)視頻序列預處理
FPGA采集板接收攝像機傳輸?shù)?路HDMI視頻序列,將4路高清序列拼接成完整的超高清序列。本設計中的超高清編碼器目前僅支持幀率小于或等于30 f/s時的視頻序列,當攝像機輸出格式為60 f/s時,F(xiàn)PGA采集板負責下采樣將其轉換為30 f/s格式。為減少CPU資源的占用率,F(xiàn)PGA采集板通過基于PCIe接口的DMA方式將視頻序列存儲至內(nèi)存設備中。其中視頻存儲格式符合編碼器的格式要求,編碼時無須進行格式轉換,以降低編碼復雜度。
3)視頻編碼與RTP打包傳輸
TILE-Gx36處理器對內(nèi)存中的原始視頻序列進行并行編碼輸出壓縮后的比特流,再進一步對比特流進行RTP格式封裝并通過網(wǎng)卡控制器輸出至網(wǎng)絡中。接收端使用支持RTP格式的播放器即可解碼回放,實時觀看。
H.264/AVC編碼器計算復雜度高,在程序運行過程對內(nèi)存容量與帶寬需求較大,其中像素的存儲管理占用了較大空間與帶寬。超高清視頻為YUV420(3 840×2 160@30 f/s)格式時,原始像素的吞吐量約為356 Mbyte/s,重建像素也會占用一定的內(nèi)存空間與帶寬。本設計中采用高效的原始像素存儲管理策略,降低內(nèi)存需求。
采集線程負責將經(jīng)過FPGA板卡預處理后的原始像素存儲至RAM,編碼線程對RAM中的原始像素進行編碼。采集線程的采集速度是視頻序列的幀率(30 f/s),編碼線程的編碼平均速度應快于30 f/s才能達到實時編碼。根據(jù)H.264/AVC標準,采用B幀編碼時,編碼序列與顯示序列(即采集序列)不一致,因此采集線程與編碼線程的處理順序不一致,需要同步機制。另一方面,編碼系統(tǒng)是通過庫函數(shù)malloc()/free()調(diào)用實現(xiàn)對內(nèi)存的分配釋放。在編碼過程中,原始視頻序列隨著時間不斷更新,如直接進行內(nèi)存的分配與釋放,則會引入內(nèi)存分配釋放函數(shù)調(diào)用的開銷,同時增加了操作系統(tǒng)內(nèi)存管理的復雜度,降低系統(tǒng)性能。本編碼系統(tǒng)使用固定數(shù)目的幀存空間來存儲原始像素,避免過多的內(nèi)存分配釋放操作。設置原始像素的幀存數(shù)目為15,幀存中的每一幀將處于下述3種狀態(tài)之一:FREE,READY,ENCODING。如圖2所示,編碼初始化15幀狀態(tài)均為FREE狀態(tài),采集線程成功采集完一幀圖像時則設置為READY狀態(tài),編碼線程開始處理原始圖像幀時則設置為ENCODING狀態(tài),編碼完成則設置為FREE,如此循環(huán)往復。其中采集線程與編碼線程對15幀的原始像素幀的管理根據(jù)各自的特點而采取不同的管理策略。

圖2 幀存狀態(tài)轉移圖
采集線程端維護兩個鏈表,空閑幀鏈表(Free_list)與非空閑幀鏈表(Not_Free_list),如圖3所示。空閑幀鏈表是處于FREE狀態(tài)的幀集合,非空閑幀鏈表是處于READY與ENCODIING狀態(tài)的幀集合。當攝像機端的原始圖像數(shù)據(jù)到來時,如果空閑幀鏈表非空,則采集原始像素圖像至空閑幀鏈表頭部,并將其移至非空閑幀鏈表尾部;如果鏈表為空,則說明編碼器不能實時編碼,可以通過丟幀的方式繼續(xù)編碼。當編碼器完成一幀編碼時,將該原始幀移至空閑鏈表尾部。

圖3 采集線程鏈表管理示意圖
編碼線程端維護15幀的狀態(tài)數(shù)組hdcap_frame[15],其中數(shù)組中的元素包括以下信息:幀存儲的邏輯地址,幀索引號frame_index(按顯示順序遞增0,1,2…),以及其他有效的參考信息等。編碼線程負責從采集線程的非空閑幀鏈表獲取處于READY狀態(tài)的原始圖像,存儲規(guī)則為hdcap_frame[frame_index%15]。編碼時直接通過幀索引號進行幀的查找。
H.264編碼器可以采用不同顆粒度[3]的并行加速方式,主要包括有圖像組并行[4]、幀級與條帶級并行[5]、宏塊級并行[3]、基于編碼功能模塊的任務并行[6]、指令級并行[7]等。H.264并行編碼可采取單顆粒度或多顆粒度并行方式,其中多顆粒度并行方式能獲得更好的加速比以及并行擴展性。
圖像組并行以GoP為基本處理單元,GoP間不存在數(shù)據(jù)依賴關系,適合數(shù)據(jù)并行。延時是實時編碼系統(tǒng)的一項重要指標,其中包括編碼延時與傳輸延時。圖像組并行將使得較長的原始視頻序列同時處于編碼狀態(tài),易產(chǎn)生延時。幀級與條帶級并行、宏塊級并行均屬于數(shù)據(jù)并行,基于不同功能模塊的流水線執(zhí)行方式屬于任務并行。指令級并行主要是采用單指令多數(shù)據(jù)指令對編碼計算比較規(guī)整的數(shù)據(jù)操作進行優(yōu)化,包括運動搜索、亞像素插值、變換量化、去塊濾波等。指令級并行主要是單核性能優(yōu)化,可以與其他并行方式嵌套組合。
由于數(shù)據(jù)并行具有良好的可擴展性[8],本設計的編碼器采用幀級與條帶級并行、指令級并行的方案進行編碼。為了達到實時編碼速度、較高的視頻質(zhì)量以及較低的編碼延時,設定編碼器的GoP結構為IPBB,P條帶具有兩幀參考圖像,B條帶具有前后各一幀參考圖像。如圖4所示,在啟動B條帶編碼時,只須滿足如下條件:在B條帶的候選垂直運動向量范圍內(nèi),參考圖像已經(jīng)重建完成。P條帶的啟動規(guī)則與B條帶類同。條帶的編碼啟動規(guī)則充分利用運動向量在垂直范圍的有限性,無須整幅參考圖像重建完成,減小了數(shù)據(jù)依賴性,利于并行。實際應用中,可根據(jù)處理器單核的性能和可使用核的數(shù)目,通過調(diào)整一幀內(nèi)的條帶數(shù)以及可并行編碼的幀數(shù)來產(chǎn)生合適的并行任務。

圖4 幀級與條帶級并行
RTP協(xié)議(Real-time Transport Protocol)是由IETF的音視頻工作組提出,主要用于端到端的實時網(wǎng)絡傳輸應用,工作組對H.264的RTP封裝格式[9]提出了規(guī)范。
由于超高清視頻編碼的碼流比特率大,設計時需要考慮RTP包傳輸?shù)乃矔r吞吐量。編碼器采用了幀級并行進行加速,故需要將比特流按照編碼順序進行碼流重組輸出,從而碼流易出現(xiàn)瞬時的大吞吐量輸出。網(wǎng)絡視頻流的傳輸應盡可能保證單位時間內(nèi)RTP包的吞吐量波動小,能減少丟包的發(fā)生。本設計通過在編碼線程與RTP封裝線程間設置一個碼流FIFO緩沖器,保證RTP包的吞吐量盡可能穩(wěn)定。如圖5所示,編碼線程將壓縮碼流輸出至FIFO中,RTP封裝線程對FIFO中的碼流進行打包封裝并傳輸至網(wǎng)絡。

圖5 碼流FIFO緩沖示意圖
編碼系統(tǒng)初始化時,F(xiàn)IFO緩沖器為空。隨著編碼線程不斷輸出比特流至FIFO中,碼流累積至buf_average=(buf_overflow+2×buf_underflow)/3時,RTP封裝線程開始進行打包。其中RTP封裝線程定期(約20 ms)查詢FIFO中的有效碼流長度(見圖5中的陰影部分),并根據(jù)過去一段時間內(nèi)(約1 s)的RTP包傳輸速度的統(tǒng)計,設置當前的打包速度。采用上述策略以及編碼器自身的碼率控制策略,使比特流的長度處于圖中的buf_underflow與buf_overflow之間,保持RTP包的傳輸速度穩(wěn)定。
整個編碼系統(tǒng)所使用的設備包括:超高清攝像機使用JVC GY-HMQ10U設備,輸出4路1 080p視頻;運算處理器使用Tilera公司的TILE-Gx36多核處理器,該處理器由36個同構核組成,單核支持最高運行頻率1.2 GHz;客戶端使用基于x86平臺的VLC播放器接收RTP碼流實時回放。
編碼系統(tǒng)的核心在于編碼器的并行性能,本次測試輸入為3個超高清YUV視頻序列,設置GoP結構為IPBBPBB,GoP長度為16幀,輸出碼率為25 Mbit/s。
在核數(shù)足夠的前提下,僅采用條帶級并行加速的實驗結果如圖6所示。由于同一幀圖像中的不同條帶編碼速度不完全一致,編碼已完成的條帶需要等待編碼尚未完成的條帶,由此引入了同步等待時間。因此編碼速度相對于條帶數(shù)的增長呈非線性增長。當條帶數(shù)為16時,3個序列的編碼速度為18~23 f/s。
在核數(shù)足夠的前提下,設置一幀的條帶數(shù)為14,在不同并行幀數(shù)下的編碼實驗結果如圖7所示。設GoP格式為 I0P3B1B2P6B4B5,當 I0與 P3編碼完成時,B1、B2、P6這3幀圖像間無數(shù)據(jù)依賴關系,可同時編碼,因此3幀并行時的編碼速度呈線性增長趨勢。

圖6 條帶級并行測試

圖7 幀級并行測試
設置一幀的條帶數(shù)為14,可同時并行的幀數(shù)為4,在不同核數(shù)下的編碼實驗結果如圖8所示。隨著核數(shù)增加,編碼速度隨之增加并趨近飽和。可以看出,當核數(shù)為21時,3個序列的編碼速度大于30 f/s,滿足實時編碼的需求。
本文設計并實現(xiàn)了實時的超高清H.264/AVC視頻編碼系統(tǒng),包括原始視頻序列采集與預處理,并行視頻編碼,比特流RTP封裝傳輸。實驗結果表明,僅使用1片TILE-Gx36處理器就能夠實現(xiàn)實時超高清視頻編碼。
:
[1] Tilera[EB/OL].[2013-10-21].http://www.tilera.com/.
[2] FREDERICK R,JACOBSON V.Rtp:a transport protocol for real-time applications[S].2003.
[3]于俊清,李江,魏海濤.基于同構多核處理器的H.264多粒度并行編碼器[J].計算機學報,2009,32(6):1100-1109.
[4]蔣興昌,周軍,羅傳飛.H.264并行編碼算法的研究[J].電視技術,2008,32(2):33-35.
[5]葉朝敏,陳穎琪,高志勇.基于多核處理器的高清實時MPEG-2—H.264轉碼器設計[J].電視技術,2012,36(21):15-19.
[6]呂明洲,陳耀武.基于異構多核處理器的H.264并行編碼算法[J].Computer Engineering,2012,38(16):35-39.
[7] LEE J,MOON S,SUNG W.H.264 decoder optimization exploiting SIMD instructions[C]//Proc.IEEE Asia-Pacific Conference on Circuits and Systems(APCCAS).[S.l.]:IEEE Press,2004:1149-1152.
[8] LIN C,SNYDER L.Principles of parallel programming[M].陸鑫達,林新華,譯.北京:機械工業(yè)出版社,2009.
[9] WENGER S,STOCKHAMMER T.RTP payload format for H.264 video[S].2005.