改進(jìn)多信道技術(shù)在無(wú)線流媒體傳輸系統(tǒng)設(shè)計(jì)

周慧嬋

改進(jìn)多信道技術(shù)在無(wú)線流媒體傳輸系統(tǒng)設(shè)計(jì)

周慧嬋

在分析多信道無(wú)線網(wǎng)絡(luò)特征以及流媒體文件特點(diǎn)的基礎(chǔ)上，提出了一種改進(jìn)的多信道傳輸機(jī)制和處理方法，對(duì)視頻分幀與幀分子幀、H.264 流媒體數(shù)據(jù)編解碼、多信道傳輸與接收、丟幀重構(gòu)和子幀重組幾個(gè)關(guān)鍵方面進(jìn)行研究。在Android 移動(dòng)平臺(tái)上設(shè)計(jì)基于此機(jī)制的一整套無(wú)線實(shí)時(shí)流媒體傳輸系統(tǒng)，并進(jìn)行了測(cè)試實(shí)驗(yàn)。測(cè)試結(jié)果表明，系統(tǒng)運(yùn)行穩(wěn)定，性能良好，并且驗(yàn)證了即使在大量幀丟失的較惡劣無(wú)線網(wǎng)絡(luò)環(huán)境下，運(yùn)用此系統(tǒng)也可以顯著提高無(wú)線實(shí)時(shí)流媒體視頻播放的流暢性，從而達(dá)到有效提高無(wú)線實(shí)時(shí)流媒體傳輸QoS的目的。

無(wú)線流媒體；Android；視頻分幀；多信道；實(shí)時(shí)轉(zhuǎn)播

0　引言

隨著流媒體中各項(xiàng)技術(shù)的高速發(fā)展，基于無(wú)線網(wǎng)絡(luò)的流媒體服務(wù)也被廣泛地研究和開發(fā)［1］。然而無(wú)線網(wǎng)絡(luò)具有很大的不確定性，使無(wú)線流媒體終端的QoS很難被保證。提高無(wú)線流媒體傳輸?shù)腝oS 涉及到了流媒體文件編解碼，無(wú)線網(wǎng)絡(luò)信道傳輸，接收端的緩存優(yōu)化理論等許多該研究領(lǐng)域的核心技術(shù)［2］。國(guó)內(nèi)關(guān)于提高無(wú)線流媒體QoS的研究大多關(guān)注如何從網(wǎng)絡(luò)狀況，所使用的傳輸協(xié)議等方面進(jìn)行改善［3］。在國(guó)外則提出了很多解決此類問(wèn)題不同的思想，其中具有代表性的就是視頻分幀傳輸?shù)乃枷耄?-5］，其是從視頻數(shù)據(jù)處理的角度出發(fā)來(lái)提高傳輸?shù)姆?wù)質(zhì)量的。本文基于該思想，針對(duì)實(shí)時(shí)無(wú)線流媒體傳輸系統(tǒng)的分發(fā)性能，對(duì)無(wú)線流媒體傳輸?shù)母鱾€(gè)環(huán)節(jié)進(jìn)行了深入細(xì)致的研究，在Android移動(dòng)平臺(tái)上設(shè)計(jì)并實(shí)現(xiàn)一整套基于實(shí)時(shí)背景的無(wú)線流媒體傳輸系統(tǒng)。

1　系統(tǒng)設(shè)計(jì)方案

系統(tǒng)主要的功能就是實(shí)現(xiàn)視頻通過(guò)無(wú)線網(wǎng)絡(luò)進(jìn)行傳輸，并在移動(dòng)客戶端進(jìn)行播放。基于視頻分幀多信道傳輸?shù)睦碚摚槍?duì)實(shí)時(shí)無(wú)線流媒體傳輸系統(tǒng)的分發(fā)性能，采取基于視頻分幀的改進(jìn)多信道傳輸機(jī)制［6］，并且充分考慮多信道無(wú)線網(wǎng)絡(luò)的特征和流媒體文件的特點(diǎn)，提出新的處理方法和機(jī)制。系統(tǒng)將視頻原幀拆分為4個(gè)子幀分別通過(guò)4個(gè)無(wú)線信道采用UDP協(xié)議進(jìn)行傳輸，系統(tǒng)總體架構(gòu)如圖1所示：

圖1　系統(tǒng)總體架構(gòu)圖

在服務(wù)器端，當(dāng)接收到來(lái)自客戶端的視頻播放請(qǐng)求后，首先把需要播放的視頻分割成連續(xù)的視頻幀，再利用像素分割的方法將每個(gè)視頻幀拆分成4個(gè)子幀，每個(gè)子幀只擁有原幀四分之一的像素。每個(gè)視頻子幀通過(guò)累積分幀之后形成了自己獨(dú)立的子幀流序列，再分別運(yùn)用編碼技術(shù)壓縮傳輸視頻的數(shù)據(jù)量。為了降低同一傳輸信道中相同視頻幀中子幀的丟失和損壞對(duì)畫質(zhì)和播放流暢度的影響，每個(gè)子幀流序列分別延遲0 秒，f 秒，2f 秒，3f 秒，經(jīng)無(wú)線網(wǎng)絡(luò)傳輸至目的移動(dòng)客戶端。延遲時(shí)間可以根據(jù)無(wú)線網(wǎng)絡(luò)的特定狀況靈活設(shè)定，數(shù)值只需在合適范圍內(nèi)即可。客戶端通過(guò)相對(duì)應(yīng)的緩存延遲方法使4個(gè)子幀流序列按照原始幀序列進(jìn)行排序。排序完畢后，CFS（Check Frame Sequence，幀序列檢驗(yàn)）機(jī)制將按照幀序號(hào)檢驗(yàn)在傳輸過(guò)程中是否有丟幀的情況發(fā)生［4］，若無(wú)丟幀則直接組合成播放視頻原幀，若有丟幀情況發(fā)生，丟幀重構(gòu)算法將被用于對(duì)原始視頻子幀進(jìn)行恢復(fù)。恢復(fù)完成后，所有的子幀再重新組合為原始視頻幀并在移動(dòng)客戶端播放。

2　系統(tǒng)服務(wù)器端設(shè)計(jì)分析

在服務(wù)器端的設(shè)計(jì)中所面臨的第一個(gè)模塊就是要將需發(fā)送的流媒體視頻數(shù)據(jù)分為視頻幀，然后再將視頻幀分為4個(gè)子幀。視頻分幀與幀分子幀的原理為［5］：每一個(gè)視頻幀基于像素分割的方法被分成四個(gè)擁有相同像素的子幀，首先將整個(gè)視頻原幀上的所有像素點(diǎn)先劃分為一個(gè)個(gè)4*4的像素矩陣，然后再將每一個(gè)像素矩陣分割為4個(gè)子像素矩陣，每個(gè)子像素矩陣相當(dāng)于各取原像素矩陣中四分之一的像素點(diǎn)，其余為空，每個(gè)像素矩陣分割后再分別組成各自對(duì)應(yīng)的子幀，按照這樣的劃分和分割方法，每一個(gè)子幀將都擁有原視頻幀四分之一的像素值，有利于均分視頻原幀的像素值。

H.264 編碼模塊：當(dāng)每一個(gè)視頻原幀都按照相同的方法累積分幀后，每個(gè)視頻幀的子幀將形成各自的子幀流序列，這樣總共形成了4個(gè)子幀流序列［6］。因?yàn)楸鞠到y(tǒng)主要應(yīng)用于實(shí)時(shí)點(diǎn)播和轉(zhuǎn)播的無(wú)線流媒體傳輸系統(tǒng)，如現(xiàn)場(chǎng)新聞的實(shí)時(shí)聯(lián)播，體育比賽的實(shí)時(shí)轉(zhuǎn)播等，這類流媒體更加需要快速，流暢播放等特點(diǎn)，并且在接收到客戶端的請(qǐng)求后，為了轉(zhuǎn)播時(shí)間不滯后，服務(wù)器一般不預(yù)先對(duì)視頻進(jìn)行預(yù)處理，而是進(jìn)行在線實(shí)時(shí)編碼。所以每一個(gè)子幀流序列將采用MDC模式分別進(jìn)行編碼，編碼標(biāo)準(zhǔn)采用H.264。

多信道傳輸模塊：當(dāng)每一個(gè)子幀流序列分別進(jìn)行編碼后，就分別通過(guò)4個(gè)無(wú)線信道所組成的MIMO結(jié)構(gòu)進(jìn)行傳輸。第一個(gè)子幀流序列將不進(jìn)行延遲直接傳輸，第二個(gè)，第三個(gè)，第四個(gè)子幀流序列在進(jìn)行傳輸之前都將分別緩存在各自的緩沖區(qū)中0.5秒，1秒，1.5秒，再進(jìn)行傳輸。延遲時(shí)間間隔定為0.5秒的數(shù)據(jù)直接取自文獻(xiàn)［11］作者的研究。設(shè)置時(shí)間間隔傳輸?shù)闹饕蚴菫榱俗畲笙薅鹊亟档屯粋鬏敓o(wú)線信道中，相同視頻幀中子幀的丟失和損壞對(duì)后續(xù)視頻播放圖像質(zhì)量及播放流暢度的影響。

3　主要模塊的實(shí)現(xiàn)與關(guān)鍵技術(shù)

改進(jìn)多信道技術(shù)的無(wú)線流媒體傳輸系統(tǒng)分成以下幾個(gè)主要模塊：視頻分幀與幀分子幀，H.264 流媒體數(shù)據(jù)編碼與解碼，多信道傳輸，幀序列檢驗(yàn)和丟幀重構(gòu)，流媒體播放。

3.1視頻分幀傳輸

實(shí)現(xiàn)視頻的分幀傳輸，首先需要將視頻分為連續(xù)的視頻幀。開源的Xuggler 類庫(kù)提供了利用Java語(yǔ)言解壓縮，修改和重新壓縮任何媒體或者流文件的功能［7］。本系統(tǒng)選用Xuggler 包來(lái)實(shí)現(xiàn)視頻分幀的功能。通過(guò)引用該類庫(kù)中的相關(guān)方法可實(shí)現(xiàn)將原視頻流媒體文件分割成連續(xù)的視頻幀。系統(tǒng)主要使用了Java中兩個(gè)重要的包：BufferedImage包和ImageIO包中的基本類來(lái)實(shí)現(xiàn)視頻幀的分割。

3.2H.264 流媒體數(shù)據(jù)編解碼

為了配合服務(wù)器端采用H.264 編碼標(biāo)準(zhǔn)傳輸數(shù)據(jù)，在Android 端需要使用Java的JNI（Java Native Interface）技術(shù)，通過(guò)使用C/C++編寫H264 解碼函數(shù)。然后使函數(shù)能夠在Android 端進(jìn)行使用，就需要使用Android NDK 對(duì)C/C++源碼進(jìn)行編譯，生成庫(kù)文件后供在應(yīng)用層端的Java 程序調(diào)用，來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)的解碼。

3.3多信道傳輸與接收

多信道傳輸與接收模塊是本文系統(tǒng)中最重要的模塊，系統(tǒng)采用Java NIO 中的Channel 對(duì)象和多線程技術(shù)相結(jié)合的方式來(lái)實(shí)現(xiàn)，本系統(tǒng)選用UDP 協(xié)議作為主要傳輸層協(xié)議。Server 類（作為服務(wù)器端）中的datagram channels（數(shù)據(jù)報(bào)通道）被設(shè)置成不阻塞且一直監(jiān)聽注冊(cè)的，當(dāng)有來(lái)自客戶端的連接請(qǐng)求后，客戶端的socket 地址將會(huì)首先被添加到服務(wù)器端程序的線程池中。

Writer 類用來(lái)處理流媒體數(shù)據(jù)的多信道傳輸，線程池中的某個(gè)線程被喚醒后，通過(guò)識(shí)別客戶端socket 地址，開辟新的通道channels 來(lái)傳輸流媒體數(shù)據(jù)。4個(gè)子幀流序列通過(guò)4個(gè)無(wú)線信道進(jìn)行傳輸，每個(gè)無(wú)線信道由一個(gè)線程進(jìn)行控制。

在Android 客戶端，同樣需要打開四個(gè)通道來(lái)接收傳輸自服務(wù)器端的流媒體數(shù)據(jù)，實(shí)現(xiàn)的方法也同服務(wù)器端類似，使用多線程來(lái)控制通道的操作，多線程在這種情況下的使用優(yōu)勢(shì)將更加凸顯，主要在于線程之間可以共用內(nèi)存，相互間的切換速度更快，提高了執(zhí)行效率，改善了移動(dòng)客戶端CPU處理能力遠(yuǎn)不及PC機(jī)的缺點(diǎn)。對(duì)于傳輸延遲和客戶端緩存延遲的實(shí)現(xiàn)，只需指定控制信道的線程的睡眠時(shí)間即可。

接收傳輸自服務(wù)器端的流媒體數(shù)據(jù)同時(shí)，需要將前3個(gè)子幀流序列的數(shù)據(jù)暫時(shí)緩存在各自的緩沖池中并進(jìn)行相應(yīng)時(shí)間的延遲，直到第四個(gè)子幀流序列數(shù)據(jù)也完全接收完畢后，才將所有幀數(shù)據(jù)按照順序進(jìn)行排序，用于檢驗(yàn)是否有丟幀的情況發(fā)生。

3.4丟幀重構(gòu)和子幀重組

當(dāng)4個(gè)子幀流序列完全接收完畢后，需要按照序號(hào)進(jìn)行幀序列檢驗(yàn)，檢驗(yàn)在傳輸過(guò)程中是否有丟幀的情況發(fā)生，如果有丟幀，則需采用相應(yīng)的丟幀重構(gòu)機(jī)制對(duì)丟失的視頻子幀進(jìn)行重新構(gòu)造。丟幀重構(gòu)的基本設(shè)計(jì)原理已在第三章中闡述，有多種重構(gòu)方法，比較常用的是計(jì)算丟失子幀的相鄰幀的像素平均值，并替代其像素值彌補(bǔ)的方法。但是由于系統(tǒng)實(shí)驗(yàn)證明，乘除運(yùn)算耗費(fèi)比較多的系統(tǒng)資源，對(duì)于內(nèi)存容量較小的移動(dòng)客戶端并不適用，所以改用移位運(yùn)算來(lái)獲得所需替代子幀的像素值。

如果無(wú)線網(wǎng)絡(luò)環(huán)境良好，在傳輸過(guò)程中無(wú)丟幀情況發(fā)生，則將已分割的子幀重新組合后進(jìn)行播放，或者將丟失的幀重構(gòu)后也需要將所有幀一并進(jìn)行重新組合。系統(tǒng)中重組算法都是在recreate（）方法中進(jìn)行實(shí)現(xiàn)，將所有子幀的的像素點(diǎn)逐一讀取后再重新以正確的順序組合為一幅幅原幀圖像。

4　系統(tǒng)性能測(cè)試與分析

4.1丟幀視頻的流暢度與畫質(zhì)測(cè)試

測(cè)試一段長(zhǎng)約1 分鐘，MP4 格式的簡(jiǎn)短視頻，分辨率為標(biāo)準(zhǔn)176*144像素值，發(fā)送幀率控制為30 幀/秒，視頻幀總數(shù)約為1800 幀，無(wú)線網(wǎng)絡(luò)采用標(biāo)準(zhǔn)IEEE802.11，無(wú)線信道帶寬約為240kbps。通過(guò)發(fā)送不同質(zhì)量的視頻來(lái)模擬較惡劣的無(wú)線網(wǎng)絡(luò)環(huán)境，分別對(duì)四種不同的情況進(jìn)行了視頻播放測(cè)試：原幀播放，原幀分別丟失1、2、3個(gè)子幀并重構(gòu)后進(jìn)行播放，直觀效果如圖2所示：

圖2　丟幀測(cè)試效果圖

圖2中b，c，d 分別表示丟失1、2、3個(gè)子幀后接收到的視頻畫面效果（此處模擬的情況是需發(fā)送的每一個(gè)視頻幀都丟失1，2，3個(gè)子幀）。

從圖2可以看出，丟幀后視頻圖像畫質(zhì)與原圖像相比清晰度下降，但仍可分辨出圖像輪廓。經(jīng)測(cè)試丟幀并在客戶端重構(gòu)后的視頻依然可以流暢播放，只是對(duì)視頻的畫面質(zhì)量產(chǎn)生影響，丟幀數(shù)量越多，則視頻畫質(zhì)越差。

為了測(cè)試在信號(hào)不強(qiáng)的無(wú)線網(wǎng)絡(luò)環(huán)境下，本文無(wú)線流媒體傳輸系統(tǒng)與運(yùn)用傳統(tǒng)方法傳輸流媒體的系統(tǒng)在流暢性方面的不同表現(xiàn)，使用和實(shí)驗(yàn)一相同的測(cè)試環(huán)境，測(cè)試視頻選取30段不同質(zhì)量，相同制式的簡(jiǎn)短視頻進(jìn)行實(shí)驗(yàn)并統(tǒng)計(jì)數(shù)據(jù)，每段視頻播放時(shí)間在3-5分鐘之間，總共播放時(shí)間約為139分鐘。在同一臺(tái)服務(wù)器上部署兩個(gè)傳輸系統(tǒng)，先使用手機(jī)自帶的普通流媒體播放器播放這些視頻，調(diào)整手機(jī)位置尋找視頻出現(xiàn)斷續(xù)播放的位置，記錄失真的次數(shù)并記錄。再使用同一手機(jī)和部署本文流媒體系統(tǒng)的服務(wù)器進(jìn)行請(qǐng)求并測(cè)試，在同一地點(diǎn)用采取播放同樣這些視頻并記錄，為測(cè)試的記錄情況表。如表1所示：

表1　不同系統(tǒng)播放視頻失真情況對(duì)比表

由表1數(shù)據(jù)可以明顯看出，本文系統(tǒng)很大程度上減少了在無(wú)線網(wǎng)絡(luò)傳輸過(guò)程中，因嚴(yán)重丟幀造成視頻失真的發(fā)生次數(shù)。

4.2不同流媒體系統(tǒng)播放視頻流暢度對(duì)比的客觀與主觀測(cè)試

本文在相同的無(wú)線信道狀態(tài)下（信道誤比特率為10-3），所采用的30 段簡(jiǎn)短視頻中，隨機(jī)抽取5 段視頻的各前300幀進(jìn)行仿真實(shí)驗(yàn)。無(wú)線網(wǎng)絡(luò)環(huán)境也和實(shí)驗(yàn)一相同（帶寬240kbps，幀率30 幀/秒）。同樣采用普通流媒體系統(tǒng)和本文系統(tǒng)分別傳輸這5 段視頻幀序列來(lái)進(jìn)行對(duì)比，對(duì)比值選用PSNR 值，它是一種評(píng)價(jià)圖像的客觀標(biāo)準(zhǔn)，單位為dB，PSNR值越大，就代表視頻播放的失真現(xiàn)象和次數(shù)越少。各視頻幀序列在相同信道狀況下兩種傳輸系統(tǒng)的對(duì)比實(shí)驗(yàn)結(jié)果，如表2所示：

表2　不同系統(tǒng)對(duì)不同幀序列在相同信道狀況下的對(duì)比PSNR 值測(cè)試結(jié)果

從表2實(shí)驗(yàn)結(jié)果得出，與普通流媒體系統(tǒng)相比，本文系統(tǒng)能獲得平均2-3dB左右的質(zhì)量增益，表明在客戶端能獲得更高的視頻重建質(zhì)量。

5　總結(jié)

無(wú)線流媒體傳輸系統(tǒng)具有一般流媒體系統(tǒng)所具有的最基本功能，并且驗(yàn)證了即使在大量丟幀的較惡劣無(wú)線網(wǎng)絡(luò)環(huán)境下，此系統(tǒng)依然可以保證流媒體視頻流暢播放的可靠性和正確性，并且系統(tǒng)性能良好。總之，此論文工作不但可以作為后續(xù)理論研究和系統(tǒng)完善的很好基礎(chǔ)藍(lán)本，而且具有很大的實(shí)際應(yīng)用價(jià)值，特別適合推廣到實(shí)時(shí)流媒體傳輸?shù)奶囟☉?yīng)用場(chǎng)合中，如實(shí)況球賽的轉(zhuǎn)播，實(shí)時(shí)新聞的現(xiàn)場(chǎng)直播，視頻遠(yuǎn)程會(huì)議，可視電話，遠(yuǎn)程醫(yī)療以及最新的3G 實(shí)時(shí)通信系統(tǒng)等。

［1］ 楊明極， 畢晶. 基于Android 視頻客戶端的設(shè)計(jì)［J］. 電視技術(shù)， 2012，36（3）：P1-2.

［2］ 廖勇， 周德松. 流媒體技術(shù)入門與提高［J］. 科技在線，2006： 69-98.

［3］ 馮開江. 移動(dòng)流媒體技術(shù)的視頻編碼標(biāo)準(zhǔn)及協(xié)議［J］. 廣播電視信息，2007（12）：P34-37.

［4］ 肖民. 移動(dòng)流媒體中的編碼技術(shù)簡(jiǎn)介［J］. 廣播電視信息，2009（07）：27-28.

［5］ Tu-Chih Wang， Hung-Chi Fang. Low Delay， Error Robust Wireless Video. Transmission Architecture for Video Communication［J］. IEEE， 2007：265-268.

［6］ 盧雪晶， 盧官明. 適用于實(shí)時(shí)視頻傳輸?shù)姆謱佣嘀孛枋鼍幋a［J］. 電信快報(bào)-網(wǎng)絡(luò)通信， 2005（11）：P3-4.

［7］ 孫松源， 吳建國(guó). 基于RTP 和Android 的視頻傳輸?shù)难芯繉?shí)現(xiàn)方法［J］. 電腦知識(shí)與技術(shù)， 2012.4， 8（4）：P2-3.

Design of Improved Multi-channel Technology for Wireless Streaming System

Zhou Huichan
（China United Network Comminications Co. LTD.， Shanghai Branch， Shanghai 200120， China）

This paper analyzes the multi-channel wireless network features and characteristics of streaming media files， then proposes an improved multi-channel transmission mechanisms and treatment methods which research several key aspects， such as sub-frame and the frame of the video frame elements， H.264 streaming data encoding and decoding， multi-channel transmission and reception， dropped frames restruction and subframes reconstruction. On the Android mobile platform， it designs a set of wireless real-time streaming media transmission system based on this mechanism， and is tested. The experimental results show that the system is stable， good performance. And it is verified that even in a large number of frame loss of a relatively harsh environment of a wireless network， using this system can also be significantly improved wireless real-time streaming video playback smooth， so as to effectively improve wireless real-time streaming media transmission QoS.

Wireless Streaming； Android； Video Sub-frame； Multi-channel； Real-time Broadcast

TP311

A

1007-757X（2016）06-0055-03

2016.03.20）

周慧嬋（1982-），女，碩士，陜西人，中國(guó)聯(lián)合網(wǎng)絡(luò)通信有限公司上海市分公司，研究方向：聯(lián)通固網(wǎng)資源核查技術(shù)方案，上海，200120