白 華，趙旭峰

（天津工業(yè)大學(xué) 電子與信息工程學(xué)院，天津 300387）

地鐵車(chē)載視頻播放系統(tǒng)作為一種媒體服務(wù)平臺(tái)，為乘客提供高效、快捷的服務(wù).隨著多媒體技術(shù)的快速發(fā)展，乘客對(duì)車(chē)載視頻畫(huà)質(zhì)的清晰度、流暢度和分辨率等提出了更高的要求，這就必然給服務(wù)器與傳輸網(wǎng)絡(luò)帶來(lái)巨大的運(yùn)行壓力[1-2].

目前，國(guó)內(nèi)地鐵車(chē)載視頻播放系統(tǒng)雖然可以播放高清視頻，但仍然存在一些問(wèn)題：服務(wù)器普遍采用傳統(tǒng)的H.264作為視頻編碼方案，但是由于H.264編碼標(biāo)準(zhǔn)的算法復(fù)雜度較大，導(dǎo)致視頻壓縮編碼時(shí)間加長(zhǎng)，最終在視頻終端出現(xiàn)了時(shí)間的延遲；網(wǎng)絡(luò)傳輸協(xié)議采用UDP（用戶(hù)數(shù)據(jù)報(bào)協(xié)議），然而UDP自身的非連接性造成網(wǎng)絡(luò)環(huán)境不穩(wěn)定時(shí)數(shù)據(jù)包丟失，造成顯示端出現(xiàn)黑屏、播放不流暢等問(wèn)題；綜上所述，有必要優(yōu)化H.264視頻編碼方案和網(wǎng)絡(luò)傳輸方案以滿(mǎn)足乘客對(duì)畫(huà)面質(zhì)量的要求[3].

基于上述問(wèn)題，本文提出了基于應(yīng)用層優(yōu)化的UDP作為網(wǎng)絡(luò)傳輸協(xié)議，并且對(duì)H.264幀內(nèi)預(yù)測(cè)算法和編碼選項(xiàng)進(jìn)行優(yōu)化，在此基礎(chǔ)上設(shè)計(jì)一種基于ARM+Linux的地鐵車(chē)載高清視頻播放系統(tǒng).本系統(tǒng)實(shí)現(xiàn)基本流程為：服務(wù)器讀取本地存儲(chǔ)器（SD卡）的預(yù)存視頻，采用優(yōu)化H.264編碼標(biāo)準(zhǔn)對(duì)視頻壓縮編碼，使用改進(jìn)的UDP實(shí)現(xiàn)將編碼后數(shù)據(jù)發(fā)送到客戶(hù)端，客戶(hù)端使用FFMPEG對(duì)視頻數(shù)據(jù)解碼且在LCD屏實(shí)時(shí)播放，實(shí)現(xiàn)720 P和1080 P高清視頻的播放功能.該系統(tǒng)可以適應(yīng)由于地鐵車(chē)廂震動(dòng)造成的網(wǎng)絡(luò)突變且能夠有效節(jié)約網(wǎng)絡(luò)帶寬.不僅可以適用于地鐵車(chē)載領(lǐng)域，同樣在公交車(chē)載系統(tǒng)、客戶(hù)服務(wù)大廳等場(chǎng)所也有著較好的適用性，具有良好的應(yīng)用前景.

1 視頻編碼方案的選擇與優(yōu)化

H.264是在混合編碼的框架上引入了新的編碼方式，適用于交互式和非交互式應(yīng)用環(huán)境.與其他編碼標(biāo)準(zhǔn)相比，H.264具有較高的壓縮比和較強(qiáng)網(wǎng)絡(luò)親和能力，可以適應(yīng)地鐵網(wǎng)絡(luò)環(huán)境突變[4]，所以在車(chē)載服務(wù)器視頻編碼方案優(yōu)先選擇了H.264.然而，H.264存在較高的運(yùn)算復(fù)雜度，無(wú)法在有限的硬件平臺(tái)充分的發(fā)揮其優(yōu)秀的編碼性能.H.264運(yùn)算復(fù)雜度主要來(lái)源2個(gè)方面：算法復(fù)雜度和龐大的編碼選項(xiàng)[7].本文針對(duì)H.264幀內(nèi)預(yù)測(cè)算法和編碼選項(xiàng)優(yōu)化，力求在保證編碼精度的同時(shí)降低編碼時(shí)間和減小運(yùn)算復(fù)雜度.

本文選用H.264編碼器為x264.與JM和T264編碼器模型相比，x264編碼器具有較強(qiáng)的實(shí)用性，現(xiàn)已成為應(yīng)用范圍最廣的視頻圖像編碼器[7].幀內(nèi)預(yù)測(cè)算法和編碼器選項(xiàng)研究如下.

1.1 幀內(nèi)預(yù)測(cè)算法優(yōu)化

幀內(nèi)預(yù)測(cè)算法亮度塊預(yù)測(cè)分為4×4塊和16×16塊，亮度塊4×4塊有9種預(yù)測(cè)模式，16×16塊有4種預(yù)測(cè)模式；色度預(yù)測(cè)8×8塊有4種預(yù)測(cè)模式；因此，對(duì)于任一個(gè)宏塊都要 M8×（M4×16+M16）=592次計(jì)算才能找到最佳的預(yù)測(cè)模式，大量的計(jì)算帶來(lái)運(yùn)算復(fù)雜度的進(jìn)一步增加[5].文獻(xiàn)[8-10]提出利用紋理特性來(lái)選擇最佳的預(yù)測(cè)模式，但是沒(méi)有考慮塊之間的聯(lián)系，可能導(dǎo)致圖像清晰度變低.考慮到宏塊本身平坦度特征的關(guān)系，即平坦區(qū)域適合于16×16塊、細(xì)節(jié)區(qū)域適合于4×4亮度塊[4].文獻(xiàn)[11]提出采用宏塊灰度直方圖作為宏塊平坦判1斷標(biāo)準(zhǔn)，但是計(jì)算復(fù)雜且碼率無(wú)法達(dá)到實(shí)際要求.

基于以上問(wèn)題，本文提出了基于SATD（絕對(duì)變換誤差和）和圖像本身特性結(jié)合的一種新型的亮度塊判決算法.算法的基本流程如下：將當(dāng)前宏塊16×16塊劃分為16個(gè)4×4塊.首先，計(jì)算4種16×16塊模式下的代價(jià)函數(shù)，選擇代價(jià)函數(shù)最小值作為最優(yōu)的模式記為Cost16；然后，比較Cost16和T0的關(guān)系（T0為設(shè)定的閾值，T0為采用不同序列測(cè)試后得到16×16塊的平均SATD值為800，故設(shè)定T0=800），若Cost16小于T0，則選16×16為最優(yōu)模式；反之，則分別計(jì)算16個(gè)4×4塊在9種預(yù)測(cè)模式的最小代價(jià)函數(shù)值，選定最小值為最優(yōu)模式并且計(jì)算16個(gè)最小的代價(jià)函數(shù)和記為Scost4.最后，若Scost4＜Cost16，選擇4×4塊為最優(yōu)模式；反之，則選擇16×16塊預(yù)測(cè)模式.圖1為優(yōu)化后亮度塊判決算法的基本流程圖.

圖1 亮度塊預(yù)測(cè)模式判決流程圖Fig.1 Decision flow chart of brightness block prediction mode

1.2 編碼選項(xiàng)優(yōu)化

由于車(chē)載視頻在相鄰幀具有背景固定，前景運(yùn)動(dòng)畫(huà)面較少的特點(diǎn).以視頻壓縮編碼壓縮性能指標(biāo)如PSNR（峰值信噪比）、編碼幀率為依據(jù)優(yōu)化編碼選項(xiàng)，在保證圖像主觀質(zhì)量與碼率、網(wǎng)絡(luò)帶寬相適應(yīng)的前提下，盡可能提高編碼速率[6].

PC機(jī)測(cè)試硬件平臺(tái)采用主頻為1.5 GHz的處理器，型號(hào)為Intel（R）core（TM）i5-6300HQ；軟件平臺(tái)為Ubuntu12.04的操作系統(tǒng)、編碼器版本為x264-snap-20170424-2245.采用不同分辨率的視頻，多次實(shí)驗(yàn)選擇面向地鐵環(huán)境的最佳編碼方案如下：

（1）x264編碼檔次采用不使用熵編碼的基本檔次；

（2）考慮地鐵網(wǎng)絡(luò)環(huán)境突變，選擇輸出幀率為15 fps，選擇碼率 128 kbps；

（3）編碼參考幀使用一個(gè)參考幀；

（4）運(yùn)動(dòng)估計(jì)宏塊搜索模式設(shè)置為 DIA（diamond）、搜索范圍設(shè)置為8.

1.3 性能測(cè)試

分別對(duì)5種不同分辨率的視頻壓縮編碼，其中，缺省為優(yōu)化前的狀態(tài)，為了分別衡量峰值信噪比和幀率在缺省狀態(tài)和優(yōu)化后的變化關(guān)系.本文采用信噪比損失率和幀率提高率兩個(gè)指標(biāo)來(lái)衡量，測(cè)得編碼方案優(yōu)化前后不同分辨率視頻的PSNR和編碼幀率信息如表1和表2所示.

表1 編碼方案優(yōu)化前后測(cè)試序列PSNR比較Tab.1 Comparison of PSNR of test sequence before and after coding scheme optimization

表2 編碼方案優(yōu)化前后測(cè)試序列編碼幀率比較Tab.2 Comparison of frame rate before and after coding scheme optimization

由表1、表2可以看出，峰值信噪比在缺省狀態(tài)和優(yōu)化后相差很小，編碼方案優(yōu)化后峰值信噪比損失都很小，說(shuō)明編碼方案優(yōu)化對(duì)于視頻失真較??；然而編碼幀率在優(yōu)化后幾乎為缺省狀態(tài)的2倍，編碼方案優(yōu)化后幀率提高均在1倍左右，在保證視頻編碼質(zhì)量的同時(shí)縮短編碼時(shí)間，達(dá)到了預(yù)期的目的.

2 傳輸網(wǎng)絡(luò)協(xié)議的選擇與改進(jìn)

TCP和UDP作為提供通信服務(wù)的重要的協(xié)議，在數(shù)據(jù)傳輸過(guò)程中扮演著重要的角色.TCP是面向連接在傳輸層最為廣泛應(yīng)用的可靠協(xié)議，但是TCP由于重傳機(jī)制和流量擁塞機(jī)制引入的抖動(dòng)使其無(wú)法有效的應(yīng)用于音/視頻數(shù)據(jù)的傳輸[12].UDP主要用于海量數(shù)據(jù)的傳輸，具有較高的傳輸效率，然而由于UDP傳輸?shù)姆沁B接性，在地鐵網(wǎng)絡(luò)環(huán)境不穩(wěn)定時(shí)容易出現(xiàn)丟包和錯(cuò)包的現(xiàn)象，導(dǎo)致視頻終端出現(xiàn)長(zhǎng)時(shí)間的花屏甚至黑屏[13].

2.1 協(xié)議優(yōu)化

針對(duì)UDP在視頻傳輸?shù)牟蛔?，文獻(xiàn)[14]提出的可靠UDP雖然可以明顯降低丟包率，但是其實(shí)現(xiàn)在網(wǎng)絡(luò)層且靈活性較差，無(wú)法應(yīng)用于地鐵突變的網(wǎng)絡(luò)環(huán)境.文獻(xiàn)[15]提出優(yōu)化UDP的方案在應(yīng)用層加入了視頻緩沖區(qū)、流量控制和確認(rèn)機(jī)制等，雖然可以保證可靠傳輸，但是復(fù)雜度較高，無(wú)法保證有效傳輸.

本文在此基礎(chǔ)上提出基于應(yīng)用層的優(yōu)化UDP的方案：在TCP/IP協(xié)議簇的應(yīng)用層加入優(yōu)化的UDP控制機(jī)制，除了具有發(fā)送和接收功能以外，還加入了重發(fā)和補(bǔ)發(fā)等機(jī)制，其具體實(shí)現(xiàn)在應(yīng)用層，具有靈活性強(qiáng)、算法簡(jiǎn)單等優(yōu)點(diǎn)，在地鐵網(wǎng)絡(luò)傳輸具有較高的應(yīng)用價(jià)值.

首先，發(fā)送端建立等待隊(duì)列和重發(fā)隊(duì)列[15]，等待隊(duì)列用來(lái)存放已經(jīng)發(fā)送的數(shù)據(jù)，重發(fā)隊(duì)列存放需要重新發(fā)送的數(shù)據(jù)包.之后當(dāng)服務(wù)器收到來(lái)自客戶(hù)端發(fā)來(lái)的重發(fā)控制包時(shí)，根據(jù)重發(fā)控制報(bào)文的內(nèi)容，在等待隊(duì)列中找到需要重新發(fā)送的數(shù)據(jù)包放入重發(fā)隊(duì)列，同時(shí)在等待隊(duì)列中將客戶(hù)端已經(jīng)收到的數(shù)據(jù)包進(jìn)行釋放，若某一個(gè)數(shù)據(jù)包發(fā)送5次以上客戶(hù)端都沒(méi)有收到，則可以將該數(shù)據(jù)包丟掉；最后發(fā)送重發(fā)隊(duì)列中的數(shù)據(jù)包，依次循環(huán)完成數(shù)據(jù)包的發(fā)送.圖2為服務(wù)器采用優(yōu)化UDP發(fā)送數(shù)據(jù)包流程圖.

圖2 優(yōu)化UDP發(fā)送數(shù)據(jù)包程序流程圖Fig.2 Flow chart of transmission packet using optimized UDP

2.2 協(xié)議測(cè)試

分別對(duì)優(yōu)化后UDP和UDP傳輸協(xié)議測(cè)試比較：服務(wù)器將已編碼的H264文件（240幀1280×720的高清序列）分別使用UDP和優(yōu)化UDP采用socket編程將數(shù)據(jù)通過(guò)以太網(wǎng)發(fā)送至客戶(hù)端，客戶(hù)端統(tǒng)計(jì)收到數(shù)據(jù)包的具體情況.實(shí)驗(yàn)室測(cè)試時(shí)，通過(guò)將網(wǎng)線內(nèi)部的一組輸入和輸出的導(dǎo)線短接，以模擬地鐵突變且不穩(wěn)定的網(wǎng)絡(luò)環(huán)境.分別在相同的網(wǎng)絡(luò)環(huán)境下，重復(fù)10次實(shí)驗(yàn)得到如圖3所示.

圖3 不同協(xié)議客戶(hù)端接收數(shù)據(jù)包情況Fig.3 Client receive data packets using different protocol

從圖3可以得出，當(dāng)網(wǎng)絡(luò)環(huán)境較差時(shí)使用優(yōu)化的UDP協(xié)議，客戶(hù)端收到視頻平均幀數(shù)為221.2幀，平均丟包率為7.83%；使用UDP協(xié)議，平均幀數(shù)為190.1幀，平均丟包率為20.79%，優(yōu)化后丟包率減少62.33%.由于地鐵大部分時(shí)間處于穩(wěn)定的網(wǎng)絡(luò)狀態(tài)，只有在經(jīng)過(guò)隧道時(shí)網(wǎng)絡(luò)才會(huì)發(fā)生突變.實(shí)驗(yàn)室模擬在網(wǎng)絡(luò)較差的情況下，客戶(hù)端可以接收到大約93%的數(shù)據(jù)包且畫(huà)面顯示流暢.然而地鐵實(shí)際網(wǎng)絡(luò)環(huán)境要遠(yuǎn)優(yōu)于實(shí)驗(yàn)室模擬的情況，所以?xún)?yōu)化的UDP可以在地鐵視頻傳輸網(wǎng)絡(luò)得到廣泛的應(yīng)用.

3 系統(tǒng)方案設(shè)計(jì)與平臺(tái)搭建

3.1 系統(tǒng)整體方案設(shè)計(jì)

本系統(tǒng)主要由服務(wù)器、視頻傳輸網(wǎng)絡(luò)和客戶(hù)端3個(gè)模塊組成，其中服務(wù)器、客戶(hù)端是運(yùn)行在A20硬件平臺(tái)嵌入式Linux系統(tǒng)，視頻傳輸網(wǎng)絡(luò)采用基于應(yīng)用層的UDP協(xié)議，3個(gè)模塊協(xié)調(diào)配合完成高清視頻播放的功能[16].

服務(wù)器的主要功能是讀取本地SD卡的視頻數(shù)據(jù)，將讀取的數(shù)據(jù)放入緩沖區(qū)后，以數(shù)據(jù)幀的形式對(duì)緩沖區(qū)的視頻數(shù)據(jù)編碼，然后將編碼后的數(shù)據(jù)封裝、打包發(fā)送至以太網(wǎng).以?xún)?yōu)化后H.264編碼算法對(duì)高清視頻的壓縮編碼，該算法可以在保證編碼壓縮比的同時(shí)，有效的縮短編碼時(shí)間，減小了地鐵高清視頻播放系統(tǒng)因?yàn)榫幋a時(shí)間帶來(lái)的局部時(shí)延.

視頻傳輸網(wǎng)絡(luò)主要是通過(guò)以太網(wǎng)將數(shù)據(jù)由服務(wù)器發(fā)送到客戶(hù)端.傳輸協(xié)議采用基于應(yīng)用層的UDP協(xié)議，減少了由于網(wǎng)絡(luò)環(huán)境不穩(wěn)定而造成的視頻數(shù)據(jù)丟包和錯(cuò)包等現(xiàn)象.

客戶(hù)端主要接收由以太網(wǎng)傳輸?shù)臄?shù)據(jù)流，解封裝后調(diào)用FFMPEG對(duì)視頻流解碼，使其還原為未經(jīng)壓縮處理過(guò)的數(shù)據(jù)流，然后將數(shù)據(jù)輸出到終端在LCD實(shí)時(shí)流暢的播放.圖4為系統(tǒng)整體設(shè)計(jì)流程圖.

圖4 系統(tǒng)整體流程圖Fig.4 Flow chart of system

3.2 系統(tǒng)平臺(tái)搭建

本系統(tǒng)服務(wù)器和客戶(hù)端采用CPU主頻為1.6 GHz的ARM Cortex-A7雙核處理器，圖像處理器采用了ARM Mail40MP2的雙核GPU，支持2160 P視頻解碼和1080 P視頻編碼的全志A20芯片.該芯片是基于“CPU+多媒體協(xié)處理器”雙核處理器，具有成本低、功耗低、功能靈活、便于升級(jí)等特點(diǎn)，因此在本系統(tǒng)硬件設(shè)計(jì)過(guò)程中優(yōu)先選擇A20芯片[14].

該系統(tǒng)硬件電路采用核心板+底板的架構(gòu).核心板主要由處理器、存儲(chǔ)器和AXP電源管理電路等組成，作為整個(gè)系統(tǒng)的控制和處理單元.底板主要由外圍電路和擴(kuò)展接口組成，主要包括供電電路、高清視頻顯示接口、USB、以太網(wǎng)和SD卡接口等[17].

軟件平臺(tái)采用Linux操作系統(tǒng).系統(tǒng)開(kāi)發(fā)模式采用“宿主機(jī)+目標(biāo)機(jī)”，分別在宿主機(jī)和目標(biāo)機(jī)搭建軟件平臺(tái).宿主機(jī)（PC）軟件平臺(tái)搭建主要包括建立交叉編譯環(huán)境、安裝SSH服務(wù)器和Samba服務(wù)器等，主要保證宿主機(jī)和目標(biāo)機(jī)正常通信；目標(biāo)機(jī)軟件平臺(tái)主要包括Bootloader（引導(dǎo)加載程序）的移植，Linux內(nèi)核移植、構(gòu)建根文件系統(tǒng)等[18].

本文采用U-Boot的版本號(hào)為u-boot-2011.09-rc1，內(nèi)核版本號(hào)為L(zhǎng)inux-3.4.根據(jù)實(shí)際需求，裁剪和修改源碼，然后將宿主機(jī)交叉編譯后得到u-boot.bin、內(nèi)核鏡像文件移植到目標(biāo)機(jī)即刻完成軟件平臺(tái)的搭建.為了實(shí)現(xiàn)視頻編解碼功能，分別在服務(wù)器和客戶(hù)端移植優(yōu)化后x264編碼器、FFMPEG解碼器[18].

4 系統(tǒng)測(cè)試

4.1 系統(tǒng)測(cè)試平臺(tái)

本系統(tǒng)測(cè)試平臺(tái)采用2套A20目標(biāo)板，分別模擬服務(wù)器和客戶(hù)端，二者通過(guò)網(wǎng)線相連.目標(biāo)板采用內(nèi)核版本號(hào)為3.4.39的Linux系統(tǒng)，高清視頻編碼器版本x264-snap-20170424-2245，解碼器版本為FFmpeg-3.3.1；宿主機(jī)交叉編譯版本為arm-linux-gcc-4.4.3.系統(tǒng)上電后，首先將服務(wù)器和客戶(hù)端的IP設(shè)置為同一網(wǎng)段；其次，啟動(dòng)應(yīng)用程序可以得到如圖5所示的高清視頻1920×1080播放的效果圖.

圖5 測(cè)試效果圖Fig.5 Results of testing

4.2 測(cè)試結(jié)果與分析

本文采用PSNR和SSIM（結(jié)構(gòu)相似比）作為視頻質(zhì)量的評(píng)判標(biāo)準(zhǔn).首先在Linux系統(tǒng)采用FFMPEG工具分別將SD卡和解碼后視頻轉(zhuǎn)換為幀圖像；之后采用MATLAB編程計(jì)算2個(gè)視頻對(duì)應(yīng)幀圖像之間PSNR和SSIM；最后取平均值作為視頻相似度的標(biāo)準(zhǔn).表3列出不同分辨率視頻相似度和平均幀率信息.

表3 不同分辨率視頻的PSNR和SSIMTab.3 PSNR and SSIM for different resolution video

針對(duì)高清視頻而言，由表3可以得出如下結(jié)論：根據(jù)結(jié)構(gòu)相似度信息可知，解碼后和未壓縮前視頻的相似度近似為0.98，可見(jiàn)視頻在傳輸過(guò)程中丟包較少，滿(mǎn)足丟包率小的要求；由峰值信噪比信息可知，PSNR的平均值都在33 dB以上，說(shuō)明了視頻失真較??；由幀率平均值在27 fps以上，可以看出視頻終端畫(huà)面顯示流暢，解決了畫(huà)面卡頓的問(wèn)題.

綜上所述，該系統(tǒng)在播放過(guò)程中畫(huà)面流暢、清晰，實(shí)現(xiàn)了系統(tǒng)播放高清視頻的功能.

5 結(jié)論

本系統(tǒng)采用全志高清視頻處理器A20為主控芯片，設(shè)計(jì)了一種基于嵌入式的地鐵車(chē)載高清視頻播放系統(tǒng)，實(shí)現(xiàn)了高清視頻流暢播放的功能.實(shí)驗(yàn)結(jié)果表明：

（1）服務(wù)器采用優(yōu)化后的H.264編碼方案，算法優(yōu)化后編碼時(shí)間平均縮短50%，縮短了由于視頻數(shù)據(jù)量增大而帶來(lái)較長(zhǎng)的編碼時(shí)間；

（2）網(wǎng)絡(luò)傳輸協(xié)議采用基于應(yīng)用層的UDP，當(dāng)網(wǎng)絡(luò)環(huán)境較差時(shí)，視頻數(shù)據(jù)丟包率平均減少62.33%，實(shí)現(xiàn)了在突變網(wǎng)絡(luò)環(huán)境下的低誤碼率傳輸；

（3）客戶(hù)端移植FFMPEG高清視頻解碼器，客戶(hù)端畫(huà)面幀率平均值在27 fps以上，視頻終端畫(huà)面顯示流暢；解碼后和未壓縮前視頻相似度近似為0.98，視頻失真很小.

本系統(tǒng)高清視頻的解碼基于FFMPEG軟件解碼，解碼效率低且視頻播放過(guò)程中速率較慢，這是該系統(tǒng)需要進(jìn)一步優(yōu)化的主要方向.