【作 者】文銘，胡海波

上海交通大學(xué)生物醫(yī)學(xué)工程學(xué)院，上海市，200240

0 引言

隨著科技的發(fā)展，醫(yī)療信息化已經(jīng)成為一種趨勢。國家的“十二五”規(guī)劃中明確指出，醫(yī)療信息化是醫(yī)藥衛(wèi)生改革的重要組成部分，需要運(yùn)用云計(jì)算、移動(dòng)互聯(lián)等新興技術(shù)，推動(dòng)數(shù)字醫(yī)療、遠(yuǎn)程手術(shù)等項(xiàng)目的發(fā)展，因此智能移動(dòng)設(shè)備將在醫(yī)療行業(yè)發(fā)揮更加重要的作用[1]。

在醫(yī)療領(lǐng)域，盡管3G網(wǎng)絡(luò)飛速發(fā)展，視頻的傳輸主要還是通過有線網(wǎng)完成。如何在帶寬受限、網(wǎng)絡(luò)不穩(wěn)定、屏幕較小的情況下設(shè)計(jì)出符合嵌入式特點(diǎn)的流媒體系統(tǒng)則成為推動(dòng)3G網(wǎng)絡(luò)在醫(yī)療領(lǐng)域發(fā)展的關(guān)鍵[2]。同時(shí)，醫(yī)療領(lǐng)域?qū)Ω咔逦直媛蕡D像和實(shí)時(shí)視頻數(shù)據(jù)傳輸有較高要求，但是3G網(wǎng)絡(luò)由于自身缺陷，如誤碼率高、抗干擾能力差，使得數(shù)據(jù)在傳輸過程中極易丟失，影響系統(tǒng)穩(wěn)定性[3]。這就需要在視頻傳輸途中，努力提升數(shù)據(jù)壓縮比，同時(shí)修正網(wǎng)絡(luò)實(shí)時(shí)傳輸過程中引起的數(shù)據(jù)錯(cuò)誤。

針對(duì)以上情況，本文對(duì)視頻實(shí)時(shí)傳輸進(jìn)行了研究和探討，提出了一種采用H.264/AVC編碼壓縮，通過擴(kuò)展實(shí)時(shí)傳輸協(xié)議（real-time transport protocol-RTP)和控制協(xié)議（real-time transport control protocol-RTCP)來傳輸實(shí)時(shí)流媒體的解決方案。

1 移動(dòng)流媒體系統(tǒng)設(shè)計(jì)

移動(dòng)流媒體傳輸系統(tǒng)主要分為兩個(gè)部分：（1）提供流媒體傳輸?shù)姆?wù)端；（2）便攜式終端播放器。系統(tǒng)總體框圖，如圖1所示。服務(wù)端作為整個(gè)系統(tǒng)的核心，當(dāng)便攜式終端發(fā)起請求時(shí)，服務(wù)端將建立RTSP連接，然后從圖像源處取出視頻數(shù)據(jù)流并壓縮封裝成RTP包，經(jīng)過3G網(wǎng)絡(luò)傳送到客戶端解碼播放。

圖1 系統(tǒng)結(jié)構(gòu)Fig.1 The architecture of the system

1.1 流媒體服務(wù)器

本文設(shè)計(jì)的基于3G網(wǎng)絡(luò)的流媒體服務(wù)器可以運(yùn)行在windows和Linux等多個(gè)操作系統(tǒng)上。根據(jù)服務(wù)器要實(shí)現(xiàn)的功能以及3G網(wǎng)絡(luò)的特殊性，文中進(jìn)行了兩個(gè)方面的改進(jìn)，包括服務(wù)端網(wǎng)絡(luò)糾錯(cuò)和服務(wù)端網(wǎng)絡(luò)監(jiān)測。

1.1.1 服務(wù)端網(wǎng)絡(luò)糾錯(cuò)

3G網(wǎng)絡(luò)具有帶寬有限、誤碼率高、抗干擾能力差、多徑衰落等缺點(diǎn)，使得數(shù)據(jù)在傳輸中易丟失，影響系統(tǒng)穩(wěn)定性，因此本系統(tǒng)采用前向糾錯(cuò)（Forward Error Correction-FEC）[4-6]來恢復(fù)數(shù)據(jù)，即在傳輸?shù)脑紨?shù)據(jù)中加入被稱為糾錯(cuò)碼的冗余數(shù)據(jù)，在一定條件下，就可以根據(jù)原始數(shù)據(jù)和冗余數(shù)據(jù)在解碼端自動(dòng)糾正錯(cuò)誤，從而降低誤碼率。

由于要區(qū)分原始數(shù)據(jù)和冗余數(shù)據(jù)，本系統(tǒng)在實(shí)現(xiàn)時(shí)擴(kuò)展了RTP標(biāo)準(zhǔn)協(xié)議，即設(shè)置RTP包頭的X字段為1，然后在RTP Header后面加入了Extension Header。原始RTP頭和擴(kuò)展以后的頭對(duì)比，如圖2所示。

圖2 原始RTP包頭和擴(kuò)展RTP包頭對(duì)比Fig.2 The format of original header and extension header

Extension Header 占有4個(gè)字節(jié)長度，考慮到移動(dòng)網(wǎng)絡(luò)帶寬受限的約束，本系統(tǒng)把前2個(gè)字節(jié)設(shè)置為0，這樣就不會(huì)過多占用網(wǎng)絡(luò)通道。而后2個(gè)字節(jié)直接表示RTP包的長度，因?yàn)镽TP標(biāo)準(zhǔn)協(xié)議是沒有記錄RTP包長度的，在數(shù)據(jù)傳輸過程中總是按照某個(gè)固定長度L來發(fā)送的，這樣即使負(fù)載數(shù)據(jù)為空也要預(yù)留長度L的空間，對(duì)于本來就不寬松的移動(dòng)帶寬來說是一種浪費(fèi)。通過這種改進(jìn)，能夠按照需要的長度發(fā)送數(shù)據(jù)，客戶端也能夠很快獲得負(fù)載數(shù)據(jù)的長度信息，從而提高帶寬利用率。

1.1.2 服務(wù)端網(wǎng)絡(luò)監(jiān)測

主要監(jiān)測3個(gè)數(shù)據(jù)：RTCP發(fā)送者報(bào)告（sender report：SR）、RTCP接收者報(bào)告（receive report：RR）、RTCP自定義段（application-defined RTCP packet：APP）[7]。當(dāng)前，國內(nèi)外學(xué)者提出了多種解決方法[8-10]，但是系統(tǒng)都比較復(fù)雜。本文則改進(jìn)了反饋機(jī)制，在APP中設(shè)置了幾個(gè)重要參數(shù)：網(wǎng)絡(luò)帶寬bandwidth、已接收到的RTP原始數(shù)據(jù)的數(shù)目original source number、已接收到的RTP冗余數(shù)據(jù)的數(shù)目Redundant number、已修復(fù)的原始數(shù)據(jù)的數(shù)目repair source number。帶寬計(jì)算公式如下：假設(shè)兩次接收數(shù)據(jù)的時(shí)間間隔是T，RTP包的長度是L，已接收到的RTP原始數(shù)據(jù)的數(shù)目是N，則傳輸數(shù)據(jù)必需的帶寬

由于需要對(duì)網(wǎng)絡(luò)進(jìn)行修復(fù)，因此剩余可用帶寬設(shè)為0，所以上式也可表示網(wǎng)絡(luò)中的實(shí)際帶寬。根據(jù)這些數(shù)據(jù)，服務(wù)器能夠得到網(wǎng)絡(luò)的狀態(tài)（包括有效帶寬、丟包率、時(shí)延特性等），從而通知編碼器相應(yīng)的調(diào)節(jié)編碼速率，同時(shí)調(diào)節(jié)數(shù)據(jù)發(fā)送速率，提高實(shí)時(shí)視頻傳輸?shù)男Ч?/p>

1.2 客戶端播放器

在3G網(wǎng)絡(luò)條件下，便攜式終端有多種選擇。本文選擇在Android手機(jī)上實(shí)現(xiàn)流媒體播放器。為了能夠正確解碼視頻流，包括兩個(gè)方面的工作：數(shù)據(jù)重排序、數(shù)據(jù)解碼。

1.2.1 數(shù)據(jù)重排序

根據(jù)RTP包的序列號(hào)和時(shí)間戳來重新排序。同時(shí)對(duì)于丟失的數(shù)據(jù)，采用前向糾錯(cuò)進(jìn)行恢復(fù)，當(dāng)數(shù)據(jù)重新整合完成后，就送入解碼模塊。

1.2.2 數(shù)據(jù)解碼

本系統(tǒng)在標(biāo)準(zhǔn)RTP/RTCP協(xié)議基礎(chǔ)上，增添了獨(dú)立的擴(kuò)展頭用于視頻流控制，增添了冗余數(shù)據(jù)用于信道編碼，因此需自制客戶端來識(shí)別有效的數(shù)據(jù)類型。由于使用了擴(kuò)展的RTP協(xié)議來傳輸數(shù)據(jù)，標(biāo)準(zhǔn)播放器將不能顯示帶冗余數(shù)據(jù)的視頻流?？蛻舳私獯a器考慮到開源特性和降低成本的目的，系統(tǒng)采用FFMPEG來解碼，能夠最大程度的保留視頻的原始特性。

2 系統(tǒng)測試

本系統(tǒng)采用3G網(wǎng)絡(luò)來測試。服務(wù)器端在PC電腦上，客戶端在Android手機(jī)上實(shí)現(xiàn)。

考慮到手機(jī)的限制，視頻碼率不能太高，查詢Android相關(guān)文件后確定碼率在380 kbps左右。圖3為Android關(guān)于視頻質(zhì)量的設(shè)定。

圖3 Android 視頻質(zhì)量標(biāo)準(zhǔn)Fig.3 The standard of Android video quality

實(shí)驗(yàn)時(shí)3G移動(dòng)網(wǎng)絡(luò)各參數(shù)如表1所示。

實(shí)驗(yàn)分為兩種情況：（1）直接傳輸，即未加入網(wǎng)絡(luò)糾錯(cuò)、網(wǎng)絡(luò)監(jiān)測、抗干擾等技術(shù)；（2）采用本系統(tǒng)進(jìn)行數(shù)據(jù)傳輸。通過圖4對(duì)比，說明本系統(tǒng)能夠有效消除畫面抖動(dòng)；圖5是丟包后，前向糾錯(cuò)對(duì)圖片進(jìn)行修復(fù)的效果，有效的減少了馬賽克。通過對(duì)比可以看出，本系統(tǒng)前向糾錯(cuò)技術(shù)對(duì)于丟失的數(shù)據(jù)有較好的修復(fù)能力，能夠顯著的改善畫面效果，從而減少傳輸延時(shí)抖動(dòng)，提高傳輸平穩(wěn)性。

表1 3G移動(dòng)網(wǎng)絡(luò)參數(shù)Tab.1 Parameters of 3G network

圖4 消除畫面抖動(dòng)Fig.4 Remove image jitter

圖5 修復(fù)鋸齒、馬賽克Fig.5 Repair image

3 結(jié)論

近年來，流媒體傳輸?shù)目焖侔l(fā)展引起了國內(nèi)外眾多專家學(xué)者的廣泛關(guān)注和研究興趣。本文結(jié)合當(dāng)前3G網(wǎng)絡(luò)的特點(diǎn)，提出以H.264/AVC為編碼器來壓縮視頻文件，并用RTP協(xié)議來傳輸數(shù)據(jù)，同時(shí)在Android客戶端顯示，最終實(shí)現(xiàn)了移動(dòng)網(wǎng)絡(luò)環(huán)境下實(shí)時(shí)流媒體的傳輸。針對(duì)移動(dòng)網(wǎng)絡(luò)信道不穩(wěn)定、易丟包等缺點(diǎn)文中采用增加冗余數(shù)據(jù)這種前向糾錯(cuò)的方法來修復(fù)。通過實(shí)驗(yàn)證明了本系統(tǒng)有一定的糾錯(cuò)能力，為以后進(jìn)一步優(yōu)化奠定了基礎(chǔ)。

[1]平板電腦將在“十二五”期間醫(yī)療信息化中發(fā)揮重要作用[J].醫(yī)學(xué)信息學(xué)雜志,2012,33(2): 94.

[2]蘇征遠(yuǎn),易燕,趙慶江,等.基于3G的流媒體服務(wù)技術(shù)研究[J].電子設(shè)計(jì)工程,2012,1: 74-76.

[3]柳林.面向3G的H.264/AVC壓縮視頻通信技術(shù)研究[D].浙江大學(xué),2006.

[4]Mazzotti M,Paolini E,Chiani M,et al,Analysis of packet-level forward error correction for video transmission[C].IEEE VTC Spring,2011: 1-5.

[5]Diaz C,Cabrera J,Jaureguizar F,et al.A video-aware FEC-based unequal loss protection scheme[C].IEEE ICCE,2011: 3-4.

[6]Li L,Han Q,Niu X.Enhanced adaptive FEC based multiple description coding for internet video streaming over wireless network [C].6th IIH-MSP,2010: 478-481.

[7]Schulzrinne H,Casner S,Frederick R,et al.RTP: A transport protocol for real-time applications[R].RFC 3550,Tech Rep,2003:35-37.

[8]Krishnapriya S,Hariharan B,Kumar S.Resolution scaled quality adaptation for ensuring video availability in real-time systems[C].IEEE HPCC-ICESS,2012: 873-878.

[9]Zhao J,Liu X.A new control mechanism for real-time video transmission based on H.264[C].IEEE ICAL,2009: 1742-1745.

[10]Xu L,Ai S.A new feedback control strategy of video transmission based on RTP[C]. ICIEA,2006: 1-4.