基于H.264 標(biāo)準(zhǔn)的實(shí)時(shí)視頻壓縮系統(tǒng)設(shè)計(jì)

張宛怡，張 堯，周啟煒

（中國(guó)空間技術(shù)研究院西安分院，西安 710100）

1 引言

近年來(lái)圖像處理是一個(gè)非常熱門的研究領(lǐng)域，而圖像視頻的存儲(chǔ)問(wèn)題更是吸引了許多研究人員的注意。如何實(shí)現(xiàn)圖像視頻的壓縮以便高效存儲(chǔ)，實(shí)時(shí)傳輸是本文的主要研究?jī)?nèi)容。H.264編碼容錯(cuò)性很高，圖像質(zhì)量強(qiáng)，編碼率低等優(yōu)秀特性是傳統(tǒng)編碼所不能比擬的優(yōu)點(diǎn)，基于這些優(yōu)秀的特性，無(wú)論是遠(yuǎn)距離還是近距離的網(wǎng)絡(luò)信號(hào)傳輸，都有著H.264編碼的用武之地。目前，H.264已經(jīng)成為了許多國(guó)家高清TV 或者網(wǎng)絡(luò)電視的視頻壓縮標(biāo)準(zhǔn)，因此了解H.264視頻壓縮標(biāo)準(zhǔn)的基本內(nèi)容，設(shè)計(jì)一套基于此編碼標(biāo)準(zhǔn)的實(shí)時(shí)壓縮視頻系統(tǒng)，是非常具有研究?jī)r(jià)值的[1]。

2 H.2 6 4 壓縮編碼標(biāo)準(zhǔn)

2.1 H.264 編碼的概念與特點(diǎn)

JVT（由ISO/IEC 協(xié)會(huì)聯(lián)合ITU-T 組織形成的視頻媒體機(jī)構(gòu)）制定的H.264編碼是目前功能最強(qiáng)大，特點(diǎn)最突出的視頻壓縮編碼。起初，為了同傳統(tǒng)的編碼制相區(qū)別，H.264的功能模塊實(shí)現(xiàn)被劃分成了三個(gè)不同的檔次，劃分級(jí)別的依據(jù)通常是不同的設(shè)計(jì)需要，比如視頻壓縮的像素塊大小等等其它的功能實(shí)現(xiàn)細(xì)節(jié)。由于實(shí)際工作的不斷深入與細(xì)化，在2007年，JVT 結(jié)構(gòu)又在原有的三個(gè)劃分級(jí)別上重新添加了一個(gè)級(jí)別，自此H.264編碼的檔次多了一個(gè)高級(jí)檔次，該級(jí)別相較于原有的檔次而言，主要優(yōu)點(diǎn)是增加了自適應(yīng)塊變換量化矩陣，同時(shí)增加了4：2：2與4：4：4采樣兩種不同的格式，在此基礎(chǔ)是利用擴(kuò)展像素大小只12bit 的方法追求更高的壓縮率[2]。

H.264編碼的特點(diǎn)還有很多，在具有很高壓縮率的同時(shí)，因?yàn)榻Y(jié)合了多種參考幀模式預(yù)測(cè)、多模式運(yùn)動(dòng)估計(jì)、整數(shù)變換及量化、環(huán)路濾波和先進(jìn)的熵編碼技術(shù)等高新技術(shù)的原因，H.264編碼的效率得到了很大的提升。以整數(shù)變換及量化舉例，編碼中選擇利用預(yù)測(cè)值與實(shí)際值計(jì)算兩者殘差，然后針對(duì)計(jì)算得到的殘差再做進(jìn)一步的整數(shù)變換和量化操作，整理數(shù)據(jù)，使得數(shù)據(jù)最大程度的簡(jiǎn)潔化，并利用熵編碼消掉冗余部分，提高視頻壓縮的效率，節(jié)約儲(chǔ)存空間，減輕硬件成本。

H.264編碼的這些優(yōu)點(diǎn)都主要是英文其H.264編碼器利用的是內(nèi)容較為簡(jiǎn)單的CAVLC 熵編碼，而不是其他復(fù)雜的編碼形式[3]。

2.2 H.26 4 編碼器及過(guò)程介紹

首先給出H.264編碼器的一般性結(jié)構(gòu)框圖，如圖1所示。

圖1 H.264編碼器結(jié)構(gòu)

根據(jù)上圖可以給出H.264編碼器編碼的過(guò)程描述：首先H.264編碼器依照率失真的計(jì)算結(jié)果可以對(duì)正在處理的數(shù)據(jù)包進(jìn)行幀間亦或是幀內(nèi)預(yù)測(cè)，如圖左上角所示，之后等待編碼模塊與預(yù)測(cè)結(jié)果兩者之間的運(yùn)算結(jié)果，一般是兩者相減就能得到中間數(shù)據(jù)Dn，然后對(duì)該中間數(shù)據(jù)進(jìn)行整數(shù)變換與歸一量化等一些列的數(shù)學(xué)處理操作，目的是為了得到一個(gè)由殘差系數(shù)構(gòu)成的矩陣數(shù)據(jù)量，根據(jù)這個(gè)計(jì)算得到矩陣進(jìn)行矩陣運(yùn)算與換維計(jì)算，之后再進(jìn)行熵編碼與反量化，注意要將熵編碼的結(jié)果及時(shí)的存儲(chǔ)到NAL 之中，根據(jù)反運(yùn)算得到的結(jié)果來(lái)與預(yù)測(cè)模塊進(jìn)行相加運(yùn)算并濾波，就可以分別得到幀內(nèi)預(yù)測(cè)與幀間預(yù)測(cè)的判斷參考數(shù)據(jù)。

3 硬件設(shè)計(jì)

本節(jié)介紹實(shí)時(shí)視頻壓縮系統(tǒng)硬件部分，實(shí)際上由于H.264編解碼系統(tǒng)比較直觀明了，大部分過(guò)程都是整數(shù)運(yùn)算，計(jì)算難度低，因此實(shí)際上非常適合用硬件來(lái)承擔(dān)一部分的高效并行計(jì)算過(guò)程，減少整個(gè)計(jì)算過(guò)程的時(shí)間，增加系統(tǒng)的實(shí)時(shí)性。其實(shí)這也是H.264編碼的一個(gè)側(cè)面優(yōu)勢(shì)。

3.1 關(guān)于DM6467 芯片

硬件系統(tǒng)最關(guān)鍵的部分是DM6467芯片，上位機(jī)是以基于Linux 操作系統(tǒng)的軟件開發(fā)平臺(tái)進(jìn)行構(gòu)建的[4][5]。系統(tǒng)的數(shù)據(jù)采集部分，選擇使用CCD 與TVP5150兩者的視頻攝像采集系統(tǒng)，采集完所有的數(shù)據(jù)之后，利用H.264編碼對(duì)視頻數(shù)據(jù)進(jìn)行編碼，并通過(guò)RTP 協(xié)議與上位機(jī)進(jìn)行通信工作，完成數(shù)據(jù)的上傳，視頻數(shù)據(jù)上傳的同時(shí)，上位機(jī)采用視頻播放器就可以完成順利接收與播放工作。

上述的數(shù)據(jù)流傳輸過(guò)程實(shí)際上主要由信號(hào)采集與數(shù)據(jù)上傳兩部分組成。視頻采集過(guò)程中采用的數(shù)據(jù)格式一般選擇BT.656，BT.656是一種常用于模擬信號(hào)采集的信號(hào)傳輸標(biāo)準(zhǔn)，主要是因?yàn)樵摳袷降囊曨l數(shù)據(jù)針對(duì)于高清或標(biāo)清的視頻所設(shè)計(jì)，時(shí)鐘頻率一般為27MHz，采樣頻率灰度與色度分別是12.5MHz 與6.25MHz。另外，整個(gè)采樣過(guò)程的完成者主要包括CCD 攝像頭與解碼器。解碼器的作用是至關(guān)重要的，它負(fù)責(zé)將收集到的數(shù)據(jù)進(jìn)行解碼，并通過(guò)DM6467的VPIF 視頻接口接收，之后將視頻數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)緩存區(qū)，為后續(xù)的進(jìn)一傳輸工作做好準(zhǔn)備。DM6467是一款視頻信號(hào)處理的專用主控芯片，它的功能十分強(qiáng)大，包含多個(gè)不同高主頻頻率的子系統(tǒng)，常見的比如arm968EJ-S 子系統(tǒng)和DSP子系統(tǒng)，具有處理高清數(shù)字媒體數(shù)據(jù)的能力，具有十分高效的傳輸速率。除了這些子系統(tǒng)之外，芯片好包括許多空間大小不同的存儲(chǔ)器，比如DDR2 存儲(chǔ)器、NAND Flash 存儲(chǔ)器、，同時(shí)還包含著前文提到過(guò)的TVP5150解碼器與CCD 攝像頭以及多功能的外圍接口。從功能上來(lái)看，不同的存儲(chǔ)器作用不同，舉例來(lái)說(shuō)，F(xiàn)lash 存儲(chǔ)器的主要功能是啟動(dòng)整個(gè)芯片系統(tǒng)，相當(dāng)于PC 機(jī)中的C 盤，該存儲(chǔ)器里存放的資源種類主要是比較重要的文件以及驅(qū)動(dòng)程序與少數(shù)的應(yīng)用程序。而DDR2存儲(chǔ)器的目的是為整個(gè)系統(tǒng)提供運(yùn)行空間，充當(dāng)視頻數(shù)據(jù)傳輸過(guò)程中的色彩與色度轉(zhuǎn)換的空間。

3.2 碼率控制模塊

談到視頻壓縮編碼硬件結(jié)構(gòu)設(shè)計(jì)，首當(dāng)其沖的就是碼率控制莫魁岸，如何基于軟核Micro Blaze 來(lái)簡(jiǎn)易準(zhǔn)確高效的實(shí)現(xiàn)碼率控制，同時(shí)通過(guò)通信端口與外圍設(shè)備實(shí)現(xiàn)數(shù)據(jù)交流與通信，是這個(gè)模塊主要應(yīng)該實(shí)現(xiàn)與滿足的功能?？紤]到碼率控制模塊可以說(shuō)是前后兩個(gè)編碼圖像之間碼率控制的橋梁，這就從側(cè)面決定的碼率控制模塊在整個(gè)硬件結(jié)構(gòu)中所處的位置以及其春哥徐應(yīng)該具備的被執(zhí)行順序，顯然意見，碼率控制模塊的編碼程序必須在前后兩幀連續(xù)的編碼圖像之中被執(zhí)行，這其實(shí)在一定程度上也是為了保證該模塊高效的運(yùn)行速度，不會(huì)造成程序執(zhí)行阻塞，下面會(huì)具體的介紹碼率控制模塊硬件結(jié)構(gòu)所實(shí)現(xiàn)的控制算法，具體可以分為三個(gè)步驟：

首先，在第一個(gè)步驟里需要參考碼率控制常用算法的類型以及各自的優(yōu)缺點(diǎn)，選擇一塊與本系統(tǒng)的硬件結(jié)構(gòu)設(shè)計(jì)要求最相近的平均比特率模式算法，也就是常說(shuō)的ABR 算法，該算法的主要計(jì)算原理是利用待編碼圖像的復(fù)雜度來(lái)調(diào)整其量化參數(shù)，同時(shí)還需要通過(guò)已編碼圖像的真正比特?cái)?shù)與一整個(gè)視頻圖像序列的目標(biāo)比特?cái)?shù)的比特因子來(lái)調(diào)節(jié)待編碼圖像的量化參數(shù)，使得兩個(gè)值之間的差距盡可能的縮小從而達(dá)到控制的碼率的目的。

其次需要根據(jù)第一步中選擇的算法類型設(shè)計(jì)合適的Micro Blaze 軟核，對(duì)其IP 參數(shù)進(jìn)行取舍，主要依據(jù)的是碼率控制計(jì)算過(guò)程的中計(jì)算類型與復(fù)雜程度以及編碼執(zhí)行的順序。通常而言，碼率控制計(jì)算會(huì)包含很多的浮點(diǎn)型數(shù)據(jù)計(jì)算以及冪指數(shù)計(jì)算，這就需要為該算法專門設(shè)計(jì)一個(gè)適合處理此類計(jì)算的軟核，盡可能的提高計(jì)算速度與運(yùn)行效率，最大程度的優(yōu)化算法編譯環(huán)境。

完成步驟一與步驟二之后，最后需要在SDK 的編譯環(huán)境之下對(duì)算法進(jìn)行結(jié)構(gòu)優(yōu)化與參數(shù)修正，使得算法變得更加簡(jiǎn)潔優(yōu)化，更加健壯。另外還需要注意的是算法程序要具有一定的安全性，注意信息安全的保護(hù)。

上面的步驟是根據(jù)經(jīng)驗(yàn)總結(jié)的一般設(shè)計(jì)流程，具體的碼率控制模塊設(shè)計(jì)細(xì)節(jié)還需要在程序執(zhí)行的過(guò)程中去根據(jù)實(shí)際情況再具體修改，優(yōu)良的硬件系統(tǒng)能夠更好的實(shí)現(xiàn)算法的高效并行計(jì)算特性，極大地加快程序執(zhí)行速度，使得視頻壓縮系統(tǒng)的實(shí)時(shí)性更加高，更加可靠。

3.3 宏塊參考信息加載與更新模塊

除了碼率控制模塊之外，H.264視頻壓縮標(biāo)準(zhǔn)決定了硬件系統(tǒng)的設(shè)計(jì)還應(yīng)該要重點(diǎn)考慮到設(shè)計(jì)一個(gè)存儲(chǔ)空間專門用來(lái)處理前文提到的在宏塊操作前需要提前準(zhǔn)備相鄰宏塊的參考信息，這些參考信息通常都包含著后面預(yù)測(cè)模塊所需要的預(yù)測(cè)參照數(shù)據(jù)，其重要性肯定是不言而喻的。具體來(lái)說(shuō)，其中的參考信息還包含著待編碼宏塊進(jìn)行預(yù)測(cè)時(shí)的參考像素與重建像素，以及兩兩相鄰的宏塊亮度塊數(shù)據(jù)與色度塊的預(yù)測(cè)類型等等。而從系統(tǒng)實(shí)現(xiàn)功能的邏輯層面上來(lái)說(shuō)，采用該宏塊參考信息加載與實(shí)時(shí)更新的模式雖然使得整個(gè)系統(tǒng)運(yùn)行更加高效，邏輯實(shí)現(xiàn)更加的簡(jiǎn)單，這是因?yàn)橄到y(tǒng)僅僅依據(jù)宏塊存儲(chǔ)空間的索引號(hào)就可以輕松的提取到相關(guān)的參數(shù)數(shù)據(jù)信息，但是這無(wú)疑就給硬件結(jié)構(gòu)與硬件資源帶來(lái)了相當(dāng)程度的壓力。為了解決該隱患，適當(dāng)程度上的減輕硬件結(jié)構(gòu)壓力，降低硬件設(shè)計(jì)的成本，如果每個(gè)編碼的宏塊只是需要考慮在它右方和在它下面的宏塊存儲(chǔ)空間，那么理論上來(lái)分析，不會(huì)超過(guò)兩行存儲(chǔ)宏塊的參考信息，這里所指的兩行參考信息其實(shí)際上也就是參考編碼宏塊的宏塊行與其上一宏塊行。綜上所述，考慮到前文中宏塊參考信息的加載方式與消耗的時(shí)間，以及更新實(shí)現(xiàn)方式存在的一些缺點(diǎn)，決定采用只存儲(chǔ)單行零一個(gè)的宏塊參考信息的實(shí)現(xiàn)方式實(shí)現(xiàn)節(jié)約硬件資源的目的。

4 軟件設(shè)計(jì)

4.1 軟件系統(tǒng)設(shè)計(jì)的核心思路

實(shí)時(shí)視頻壓縮系統(tǒng)采集到的數(shù)據(jù)經(jīng)過(guò)信號(hào)傳輸通道傳到PC機(jī)這個(gè)過(guò)程實(shí)際上包括了信號(hào)電路的處理，在一定幀頻下的數(shù)據(jù)壓縮以及一定速率的以太網(wǎng)傳輸過(guò)程。系統(tǒng)核心主控芯片包含ARM 與 DSP 兩個(gè)處理器內(nèi)核，其中兩個(gè)內(nèi)核主要負(fù)責(zé)的功能有一定區(qū)別，概括來(lái)看，DSP 內(nèi)核實(shí)現(xiàn)的功能主要跟信號(hào)處理有關(guān)，比如編解碼器控制、音頻處理以及視頻內(nèi)容分析等等。而反觀ARM 內(nèi)核，其主要負(fù)責(zé)的內(nèi)容主要是運(yùn)行Linux 等操作系統(tǒng)。本文設(shè)計(jì)的軟件系統(tǒng)就是基于Linux 操作系統(tǒng)。

在上位機(jī)中編寫視頻圖像壓縮的程序時(shí)，待處理的彩色圖像數(shù)據(jù)在不同的程序語(yǔ)句要求下進(jìn)行各種不同形式的數(shù)據(jù)轉(zhuǎn)換。常見的一種模式轉(zhuǎn)換是Y 分量的圖像壓縮發(fā)送，該模式下需要從待處理視頻圖像中逐幀提取到Y(jié) 分量，并將其轉(zhuǎn)變成xDM 標(biāo)準(zhǔn)接口的數(shù)據(jù)格式，再創(chuàng)建Codec engine 對(duì)象，調(diào)用恰當(dāng)?shù)乃惴▽?duì)視頻進(jìn)行壓縮；還有一種常見的轉(zhuǎn)換模式就是直接在H.264編碼制的規(guī)定下利用Codec engine 調(diào)用xDM 程序?qū)σ曨l數(shù)據(jù)進(jìn)行壓縮，壓縮完成后對(duì)視頻數(shù)據(jù)進(jìn)行封裝與打包，數(shù)據(jù)被上傳到上位機(jī)制指定空間后進(jìn)行編碼與解壓縮，通過(guò)播放器進(jìn)行視頻播放，完成視頻顯示操作。系統(tǒng)數(shù)據(jù)流程如圖2所示。

圖2 系統(tǒng)數(shù)據(jù)流程圖

4.2 軟件系統(tǒng)設(shè)計(jì)中的關(guān)鍵模塊與編程

H.264編碼的優(yōu)點(diǎn)十分明顯，例如前文所敘述的那些，不過(guò)由于為了追求高效性，其算法以及程序的復(fù)雜性導(dǎo)致開發(fā)設(shè)計(jì)的壓力就很大，必須在算法以及程序流程的設(shè)計(jì)上下一翻功夫，本節(jié)就是從這個(gè)角度出發(fā)，來(lái)對(duì)軟件系統(tǒng)關(guān)鍵部分的設(shè)計(jì)深入研究。

4.2.1 編碼庫(kù)的調(diào)用與通信過(guò)程

H.264編碼庫(kù)源碼被下載解壓打開后需要先調(diào)用指定命令來(lái)對(duì)其進(jìn)行初始化與配置更改，然后用指令語(yǔ)句對(duì)其進(jìn)行編譯的操作，如果不能正常進(jìn)行編譯，需要查看是否是編碼源庫(kù)下載不完整，亦或是編譯程序有問(wèn)題導(dǎo)致過(guò)程沒(méi)有被全部執(zhí)行。如果編譯非常順利的話，就可以下一步操作，即對(duì)圖像數(shù)據(jù)輸入流進(jìn)行幀的編碼工作。在這之中，值得注意的是需要在編譯文件目錄下找到一個(gè).o 文件并將其刪除，此文件的存在極易引起編譯服務(wù)端程序出錯(cuò)，使得程序變編譯不能得到正確的結(jié)果。

服務(wù)器程序的編寫工作并不是十分復(fù)雜，實(shí)際上類似于JAVA SE 中網(wǎng)絡(luò)編程的客戶端與服務(wù)端基本通信的過(guò)程。其中服務(wù)器編程所要調(diào)用類主要就是Socket 類，眾所周知Socket 編程的方式最常用的就是兩種，即TCP 與UDP 兩種，這兩種方式的區(qū)別主要在于套接字的形式不同，這里不做詳細(xì)的說(shuō)明，本文選用的是UDP 網(wǎng)絡(luò)編程來(lái)實(shí)現(xiàn)軟件系統(tǒng)編碼過(guò)程的設(shè)計(jì)與通信功能。

4.2.2 接收?qǐng)D像的播放器設(shè)計(jì)

設(shè)計(jì)接收端媒體播放器的出發(fā)點(diǎn)是要基于Linux 操作系統(tǒng)，并且該播放器最好要能夠支持大多數(shù)的媒體視頻格式，要有很強(qiáng)的實(shí)時(shí)接收數(shù)據(jù)能力，本文擬采用的是Linux 操作系統(tǒng)下的DirectShow 流媒體框架，該該框架與Linux 系統(tǒng)高度契合，功能強(qiáng)大，適合用于作為本軟件系統(tǒng)播放器的開發(fā)框架。

5 系統(tǒng)測(cè)試及結(jié)果分析

系統(tǒng)的硬件系統(tǒng)與軟件系統(tǒng)設(shè)計(jì)完畢后，需要嘗試運(yùn)行整個(gè)視頻壓縮系統(tǒng)。首先檢查所有的硬件部分，查看各設(shè)備是否連接正常，各模塊之間通信是否正常，嚴(yán)格杜絕丟包現(xiàn)象的發(fā)生，硬件部分初步檢查完畢后，需要利用短劍系統(tǒng)在仿真環(huán)境下安裝操作系統(tǒng)，并且燒錄算法與程序文件到主控芯片中去。之后運(yùn)行程序，觀察視頻傳輸與播放是否正確，為了評(píng)估視頻壓縮傳輸?shù)馁|(zhì)量，需要將視頻按幀截圖進(jìn)行分析，與采取H.264編碼壓縮傳輸之前的視頻采集圖像進(jìn)行充分的比較分析。對(duì)比發(fā)現(xiàn)該實(shí)時(shí)視頻壓縮系統(tǒng)實(shí)時(shí)性滿足要求，延時(shí)時(shí)間較低，視頻壓縮的速度與質(zhì)量很強(qiáng)。本次實(shí)驗(yàn)視頻在數(shù)據(jù)采集方面花費(fèi)的時(shí)間為3分鐘，采用的視頻輸入格式選擇的是常見的PAL 格式文件形式，幀率設(shè)置的是25幀/s，視頻圖像分辨率為720×576，記錄未壓縮視頻數(shù)據(jù)率是125Mb/s。編碼實(shí)現(xiàn)后視頻圖像數(shù)據(jù)信號(hào)的碼率設(shè)置成800 kb/s。依據(jù)碼率公式[碼率]（kb/s）=[文件大小]（字節(jié)）X8/[時(shí)間]（s）/1 000，計(jì)算壓縮后視頻數(shù)據(jù)量?jī)H僅只有18Mbyte，綜上所述，視頻壓縮效果非?？煽?，其中壓縮比為156.25，達(dá)到設(shè)計(jì)目標(biāo)。

6 結(jié)束語(yǔ)

本文首先介紹了H.264編碼標(biāo)準(zhǔn)的基本概念以及其相較于其它視頻壓縮標(biāo)準(zhǔn)的優(yōu)點(diǎn)，并以DM6467為硬件核心，Linux 操作系統(tǒng)為軟件開發(fā)平臺(tái)依次從硬件、軟件兩個(gè)角度介紹了視頻壓縮系統(tǒng)平臺(tái)的構(gòu)建及功能的實(shí)現(xiàn)。