關鍵詞： 3B , 解碼器 , 龍芯 , 向量化

當今社會已經步入信息時代，傳統的信息載體和通信方式已經無法滿足人們對信息的需求。而實驗表明：相比較語音和抽象數據，人類接受的信息更多是以圖片和視頻方式為載體的。其中視頻信息具有直觀、具體和高效的特點，這也就決定了視頻通信技術將成為信息時代的重要技術之一。

由于視頻的數據量巨大，而存儲視頻的資源通常是非常有限的，因而對視頻進行壓縮編碼，以減少存儲資源的消耗，非常必要。然而，通常情況下，使用的壓縮算法的復雜度越高，壓縮比率越高，視頻播放時的解碼速度就會越低。因而在提高編碼壓縮率的同時，也需要對解碼器進行相應的優化，以提高視頻解碼器在目標平臺上的性能。本文就實現了ffmpeg解碼器在龍芯3B上的移植與向量化，提高了該解碼器在龍芯3B上的性能。

1 視頻編／解碼與龍芯3B

1．1 視頻編／解碼

目前，成熟的壓縮編／解碼方法有很多。其中H．261、MPEG-1、MPEG-3和H．263采用了第一代壓縮編碼方法，如預測編碼、變換編碼、熵編碼以及運動補償；而MPEG-4和H．264采用了第二代的壓縮編碼方法，如分段編碼和基于模型或對象的編碼等。

視頻壓縮編碼的主要目的是減少存儲視頻所占用的資源，而解碼技術的目標則是提高解碼的速度，從而提高視頻播放的流暢性。常見的基于H．264編碼方法的軟解碼器包括CoreAVC、ffmpeg和JM等。其中JM是H．264官方網站提供的編／解碼器，集合了各種編／解碼算法，而且代碼的結構清晰，很適合應用于對視頻編／解碼技術的研究。而CoreAVC解碼器則主要用于商用，其解碼速率比ffmpeg快50％以上。ffmpeg是開源的解碼器，而且性能相對較好，很多開源項目都直接或間接地使用了ffmpeg，如mplayer播放器等。通過對性能以及開源特性的綜合考慮，本文選擇ffmlpeg作為移植和向量化對象。

1．2 龍芯3B體系結構

龍芯3B處理器在兼容了MIPS64指令集的同時，實現了針對多媒體應用的向量擴展指令，這對視頻編／解碼應用性能的提升有很大的幫助。

龍芯3B提供了256位的向量寄存器并實現包括256位向量訪存在內的向量擴展指令。使用向量指令可以一次完成32個字節寬度數據的操作。而這樣的結構和指令集設計，使得龍芯3B非常適合于實現大規模相同類型數據的相同運算，比如矩陣乘法運算和FFT運算，以及視頻編／解碼運算等。

不過由于ffmpeg并未實現對龍芯3B平臺的支持，因而需要完成ffmpeg到龍芯3B的移植工作。本文之前也有一些ffmpeg到其他平臺的移植工作和針對龍芯平臺的移植與優化工作，都取得了不錯效果。

2 基于龍芯3B的ffmpeg移植

2．1 ffmpeg的移植

ffmpeg解碼器提供了對不同目標平臺的支持，而與這些平臺相關的文件都保存在以該目標平臺命名的目錄下。例如，ffmpeg解碼器實現了對arm和sparc平臺，以及x86平臺的支持。

對于實現ffmpeg解碼器對龍芯3B的支持，主要完成以下5個步驟：

(1)修改configure配置文件，增加與龍芯體系結構相關的配置選項；

(2)新建龍芯專用文件夾godson，將龍芯體系結構相關的文件都存放于該文件夾中；

(3)將godson文件夾下新增的需要編譯的文件添加到Makefile中；

(4)增加與dsputil_init類似的新的初始化函數dsputil_init_godson；

(5)在頭文件中添加新增函數的聲明。

針對龍芯3B的ffmpeg移植工作相對比較簡單，因而本文重點介紹針對龍芯3B的向量化工作。

2．2 移植后的ffmpeg的性能比較

本節對移植后的ffmpeg解碼器進行了性能測試，對使用龍芯3B向量擴展指令和不使用龍芯3B擴展指令兩種情況下的性能進行了比較。測試時使用支持龍芯3B擴展指令集的GCC編譯器進行編譯，并且開啟-ftree-vectorize和-march=godson3b編譯選項來支持龍芯 3B擴展指令。使用的測試用例為視頻“walk_vag_640x480_qp26．264”，測試結果如表1所示。

從表1的測試結果中可以看出，使用龍芯3B的向量擴展指令可以提高ffmpeg解碼器在龍芯3B上的性能，用來測試的視頻的解碼時間減少了約466s。盡管如此，由于GCC編譯器本身自動向量化能力的限制，ffmpeg解碼器的性能提升還是比較有限的，因而針對龍芯3B的指令集對移植后的ffmpeg解碼器進行向量化，就成為了進一步提高性能的重要工作。

3 ffmpeg的向量化

3．1 ffmpeg的oprofile測試

使用oprofile對ffmpeg解碼視頻“問道武當002．mkv”的過程進行測試，測試結果如表2所示。表2列出了各個函數的調用過程以及運行時間所占的比重。而針對ffmpeg解碼器進行的向量化工作，則主要是針對oprofile測試結果中執行時間較長、運行比重較大的幾個函數的向量化。

上述函數的執行時間幾乎占據了ffmpeg解碼器執行時間的60％，因而針對上述幾個函數進行向量化，就完全可以達到提升ffmpeg整體解碼速度的目的。

3．2 針對龍芯3B的ffmpeg向量化

3．2．1 向量化方法

實現ffmpeg解碼器在龍芯3B上的向量化主要是使用龍芯3B擴展的向量指令來改進3．1節中oprofile測試結果中執行時間比重較大的幾個函數。而且在向量化的同時，同樣可以使用一些優化策略，來提高向量化后的函數的性能。主要使用到的優化方法包括：

(1)循環展開。循環展開是一種循環變換技術，將循環體中的指令復制多份，增加循環體中的代碼量，減少循環的重復次數。需要說明的是，循環展開本身并不能直接提升程序的性能。

使用循環展開的主要目的是充分挖掘指令或者數據間的并行性。其中向量擴展指令的使用就是利用了展開后的循環體內數據的并行性；而在展開后的循環內使用指令調度和軟件流水技術則是為了充分利用指令間的并行性。

(2)指令調度。循環展開后的循環體內的指令數目增多，因而可以進行指令調度，將不存在操作數相關性和不存在運算部件相關性的指令調度到一起，這樣可以充分發揮龍芯3B的流水線性能，從而提高代碼在龍芯3B上的執行速度。

除了使用龍芯3B的向量擴展指令和使用上述兩種優化方法以外，同樣還可以根據具體函數的特點，使用其他一些優化方法進行優化，比如使用邏輯運算和移位運算來代替乘法運算等。針對每個函數的向量化優化在3．2．2小節中介紹。

3．2．2 針對具體函數的向量化

3．2．1小節概述了向量化時用到的一些優化方法，本節則針對oprofile測試中比重較大的幾個函數進行有針對性的優化。

對于表2中的函數，我們可以根據函數名將其分類，函數命名類似的函數基本上都可以使用類似的優化方法。

(1)簡單向量化。對于1號和2號函數的優化，本文都采用了使用移位運算來代替乘法運算的策略，并且針對循環內部運算的有界特性，使用飽和向量運算來改進。不過對于2號函數的訪存操作，由于存在著數據非對齊的情況，因而使用額外的向量指令對數據進行打包和回寫。而3號函數則是1號和2號函數的混合，因而對1號和2號函數的優化間接提升了3號函數的性能。

而對于4號、5號和6號函數，本文僅對其內層循環使用了循環展開和指令調度策略，就能夠取得不錯的運算效果。

同樣，對于11和12號函數也可以比較直觀的進行向量化，在此就不做詳述了。

(2)間接向量化。而對于比較難于向量化的7號和8號函數，本文分別采用了使用掩碼和使用矩陣轉置運算的策略來間接實現向量化。

其中針對函數h264 v loop filter luma的C語言實現中有很多判斷語句的問題，本文使用構建掩碼的方式來消除這些判斷語句。

以圖1(a)中的循環為例介紹掩碼的構建。而圖1(b)所示為代替該循環的向量指令。具體的運算結果如圖1(c)所示：將p向量(數組)和q向量做飽和減法(結果為負的都置為0)，得到的結果向量如Vsub所示。使用Vsub與零向量進行比較來設置掩碼：結果為真，掩碼值為0xFF；反之，結果為假，掩碼為0。最后將掩碼值與p向量進行與操作，就可以得到該循環的運算結果。

使用構建掩碼的方法來消除判斷語句，不但減少了由判斷引起的時間開銷，而且重要的是間接將循環進行了向量化，提高了函數性能。而對于9號和10號函數，可以使用同樣的方法來改進。

而對于8號函數，由于運算處理的是連續的數據，因而無法進行向量化。使用矩陣轉置的方式，將數據重新打包后，就可以進行相應的向量運算。

對于圖2(a)中的運算，原始計算是P向量內部的運算，因而無法向量化，我們用向量指令將p向量轉置為q，其中q0存放p中標號為1的數據，q1存放P中標號為2的數據，依此類推。轉置得到的q向量就可以用圖2(b)中的向量指令運算，得到的運算結果與原來的運算相同。　

對于13～15號函數的優化，同樣使用到了上面的轉置方法。而4．1節的測試結果則說明了各個函數的優化效果。

4 實驗結果

4．1 ffmpeg各函數加速比

本文分別對向量化后的各個函數進行了測試，并且與未向量化之前的函數進行了比較，各個函數向量化優化后的加速比如圖3所示。其中圖中橫坐標所示函數序號與表2中的各個函數一一對應。

圖3中的函數的加速比所跨越的范圍較大，比如6號函數的加速比約有23．9左右，而最后一個函數的加速比只有1．2左右。之所以會出現上述情況，除了與改進后的函數所使用的向量指令的數量和修改代碼的比重有關以外，也與運算所使用的操作數的類型有關。對于6號函數，其循環內的運算所使用的操作數的類型為字節類型，因而僅僅使用向量指令進行優化，理論加速比就可以達到32，不過本文僅僅對該函數的內層循環進行了向量化，而向量化后的內層循環一次僅僅處理了 16個字節類型的數據，即并未充分使用256位的向量寄存器。因而理論的加速比應該為16，但是由于結合了循環展開和指令調度等其他優化策略，因而實際的加速比可以達到23．9左右。同樣，對4號、5號和6號這三個同類型的函數進行分析，我們也可以發現：后一個函數的加速比均約為前一個函數加速比的兩倍。這是因為對于4號函數，內層循環向量化后一次可以同時計算4個字節類型的數據，而5號函數可以同時計算8個字節類型的數據，因而理論上的加速比也應該是兩倍的等比數列形式，而實際結果與理論分析是一致的。

對于3．3．2小節中重點介紹的7號函數和8號函數，其原函數無法進行簡單向量化，而本文使用了掩碼以及矩陣轉置等優化方法，使其能夠使用龍芯3B的向量擴展指令，因而盡管性能提升不大，但是加速比也分別有3．2和5．5。

4．2 不同平臺上的向量化比較

本文同樣將ffmpeg解碼器分別在不同的平臺上進行了測試，使用的兩個測試視頻分別為是“問道武當002．mkv”(視頻A)和“walk_vag_ 640x480_qp26．264”(視頻B)。其中視頻A是問道武當視頻(720p)中截取的片段，而后者是通過x264對walk_vag．yuv(480p)編碼生成的，編碼時選用的qp值為26。而測試平臺則分別選擇了AMD和Intel處理器平臺。

從表3的測試結果可以看出對于視頻A，在龍芯3B上的性能提升比其他兩個平臺上都高很多；而對于視頻B，在龍芯3B上的性能提升也與其它兩個平臺接近。實驗結果表明：在龍芯3B上實現ffmpeg解碼器的向量化，對性能提升有很大幫助，而且解碼某些視頻時，性能的提升甚至高于性能優越的商用處理器。而通過與表1中使用GCC向量化編譯的結果進行比較，也可以看出：手工對ffmpeg解碼器進行向量化比使用GCC進行向量化，性能有更大的提升。

5 總結和展望

本文實現了ffmpeg解碼器到龍芯3B的移植，并針對龍芯3B實現了對向量擴展指令支持的特點，對ffmpeg解碼器進行了手工向量化。實驗結果表明：手工向量化后的ffmpeg解碼器的性能比使用GCC向量化編譯后的ffmpeg解碼器性能要好很多，而且性能的提升也比Intel和 AMD平臺更多。

本文僅僅從代碼級實現了針對龍芯3B的ffmpeg解碼器的向量化移植，為了進一步提高性能，還需要從整個算法層面上進行優化。另外，由于龍芯3B的多核特性，還可以考慮使用多核進行解碼。