林志勇 葉樺 孫曉潔 仰燕蘭

(東南大學(xué)自動化學(xué)院，南京 210096)(東南大學(xué)復(fù)雜工程系統(tǒng)測量與控制教育部重點(diǎn)實(shí)驗室，南京 210096)

隨著網(wǎng)絡(luò)技術(shù)和嵌入式技術(shù)的迅猛發(fā)展，網(wǎng)絡(luò)視頻監(jiān)控已經(jīng)得到了廣泛的應(yīng)用，而基于3G網(wǎng)絡(luò)的視頻監(jiān)控系統(tǒng)在難以架設(shè)有線電纜的地方更是有著巨大的優(yōu)勢.但3G網(wǎng)絡(luò)很不穩(wěn)定，不同的時段、不同的地理位置，帶寬會相差很大，所以系統(tǒng)需要進(jìn)行流量控制.為了保證視頻的實(shí)時性，視頻數(shù)據(jù)一般采用UDP協(xié)議進(jìn)行數(shù)據(jù)傳輸，但UDP協(xié)議并不提供流量控制或者擁塞控制，所以必須根據(jù)當(dāng)前網(wǎng)絡(luò)狀況來自適應(yīng)調(diào)整視頻的碼率.

在數(shù)據(jù)的傳輸過程中，造成網(wǎng)絡(luò)狀況改變進(jìn)而影響視頻質(zhì)量主要分為以下2種情況:①3G網(wǎng)絡(luò)信號強(qiáng)度發(fā)生變化或者網(wǎng)絡(luò)負(fù)載發(fā)生變化，如監(jiān)控終端移動到3G信號比較弱的地方，3G網(wǎng)絡(luò)使用者增多，這些都會減小3G網(wǎng)絡(luò)有效帶寬.如果3G網(wǎng)絡(luò)帶寬減小，而視頻碼率不變的話，視頻碼率就會超出網(wǎng)絡(luò)的負(fù)載能力，進(jìn)而造成丟包甚至網(wǎng)絡(luò)擁塞.因此，就需要根據(jù)網(wǎng)絡(luò)狀況來調(diào)整碼率.② 在監(jiān)控終端中，產(chǎn)生的數(shù)據(jù)并不會立即發(fā)送出去，需要先存儲在環(huán)形緩存中，這樣視頻數(shù)據(jù)就只能暫時存儲在終端，等待發(fā)送，所以數(shù)據(jù)的發(fā)送并不是均勻的.如果在一段時間內(nèi)CPU比較忙，很多數(shù)據(jù)就會堆積在監(jiān)控終端，在接下來的一段時間內(nèi)需要發(fā)送的數(shù)據(jù)就會急劇增加.另外，在動態(tài)碼率下，畫面變化產(chǎn)生的平均數(shù)據(jù)量要大于畫面靜止時產(chǎn)生的平均數(shù)據(jù)量，即監(jiān)控終端產(chǎn)生的數(shù)據(jù)量很不均衡.這樣造成的后果是，雖然平均碼率沒有超過網(wǎng)絡(luò)帶寬，但某一時間段的發(fā)送速率已經(jīng)超過了網(wǎng)絡(luò)帶寬，因此就會造成丟包甚至擁塞.在查閱的文獻(xiàn)中，還沒有提出此問題，都默認(rèn)發(fā)送速率是均勻的，但實(shí)驗表明，在終端均勻發(fā)送數(shù)據(jù)是很難實(shí)現(xiàn)的.

基于上述原因，在視頻傳輸過程中，必須根據(jù)網(wǎng)絡(luò)狀況來自適應(yīng)調(diào)整碼率.關(guān)于網(wǎng)絡(luò)狀況的判定，現(xiàn)在已經(jīng)提出了很多方法，主要是根據(jù)包丟失相關(guān)標(biāo)志量和時間相關(guān)標(biāo)志量.文獻(xiàn)［1-2］根據(jù)丟包率來估算網(wǎng)絡(luò)帶寬.文獻(xiàn)［3-4］根據(jù)時間相關(guān)標(biāo)志量來估算網(wǎng)絡(luò)帶寬.但這兩種方法都有局限性，文獻(xiàn)［5］對這兩種方法進(jìn)行了比較:包丟失相關(guān)標(biāo)志量有滯后性，不能及時反映網(wǎng)絡(luò)狀況，時間相關(guān)標(biāo)志量計算復(fù)雜，實(shí)現(xiàn)難度比較大，容易產(chǎn)生較大誤差，算法大多局限于仿真.關(guān)于碼率的調(diào)整，一般采用加性增乘性減(AIMD)算法或改進(jìn)算法來調(diào)整碼率.

針對上述情況，本文結(jié)合丟包率和視頻延時兩個標(biāo)志量來判斷網(wǎng)絡(luò)狀況，并采用改進(jìn)的AIMD算法來計算新的碼率.實(shí)驗結(jié)果表明，視頻延時具有很好的預(yù)測作用，無論是3G網(wǎng)絡(luò)質(zhì)量變差還是數(shù)據(jù)發(fā)送不均勻，都能在視頻延時中體現(xiàn)出來，因此可以有效地調(diào)整視頻碼率，可以在一定程度上預(yù)防丟包和擁塞.在碼率波動和丟包率兩方面相比于RTT都有一定的優(yōu)勢.

1 視頻監(jiān)控系統(tǒng)介紹

整個視頻監(jiān)控系統(tǒng)由三部分組成:監(jiān)控終端、服務(wù)器和客戶端.監(jiān)控終端把采集到的視頻數(shù)據(jù)經(jīng)過服務(wù)器轉(zhuǎn)發(fā)給客戶端，客戶端通過服務(wù)器把Qos信息反饋給監(jiān)控終端.監(jiān)控終端根據(jù)客戶端的反饋信息計算新的碼率值.

1.1 系統(tǒng)結(jié)構(gòu)

監(jiān)控終端是基于海思Hi3512的嵌入式系統(tǒng)，基于Linux2.6.14內(nèi)核.Hi3512是海思半導(dǎo)體推出的一款基于ARM9處理器內(nèi)核以及視頻硬件加速引擎的高性能通信媒體處理器，具有H.264硬件編解碼功能.服務(wù)器程序運(yùn)行在聯(lián)通服務(wù)器上.監(jiān)控終端通過聯(lián)通3G網(wǎng)絡(luò)和服務(wù)器傳輸數(shù)據(jù)，客戶端通過聯(lián)通3G或有線寬帶和服務(wù)器通信.監(jiān)控終端和客戶端運(yùn)行后，首先需要登陸服務(wù)器.監(jiān)控終端登陸服務(wù)器后，服務(wù)器會向所有的在線客戶端發(fā)送此終端登陸的消息.客戶端登陸服務(wù)器后，服務(wù)器把所有已登陸的終端信息發(fā)送給客戶端.因此，每一個客戶端都可以看到所有在線的終端，并請求終端的視頻.系統(tǒng)結(jié)構(gòu)如圖1所示.

圖1 系統(tǒng)結(jié)構(gòu)圖

1.2 數(shù)據(jù)傳輸模型

監(jiān)控終端采集視頻數(shù)據(jù)，經(jīng)過H.264編碼，存儲在環(huán)形緩存里等待發(fā)送.如果視頻幀數(shù)據(jù)大于MTU(最大傳送單元)，還需要進(jìn)行分包處理，把視頻幀分割成大約1 K的數(shù)據(jù)包，在客戶端進(jìn)行重新組合.為了保證視頻的實(shí)時性，傳輸層采用UDP協(xié)議，但UDP協(xié)議本身并不提供任何網(wǎng)絡(luò)狀況信息和流量控制機(jī)制，所以為了獲得網(wǎng)絡(luò)狀況等相關(guān)信息，需要在視頻數(shù)據(jù)前加上一個特殊的信息包頭，包括終端號、數(shù)據(jù)包序列號、時間戳.在客戶端，首先對信息包頭進(jìn)行處理，根據(jù)這些信息判斷網(wǎng)絡(luò)狀況.另外，視頻幀在終端被分割成多個數(shù)據(jù)包，所以還需要標(biāo)示出數(shù)據(jù)包所屬視頻幀的相關(guān)信息，包括視頻幀序列號、視頻幀被分割的數(shù)據(jù)包總數(shù)和數(shù)據(jù)包在視頻幀中的位置.客戶端據(jù)此信息把數(shù)據(jù)包重新組合成視頻幀進(jìn)行解碼.整個視頻數(shù)據(jù)包的格式如圖2所示.

客戶端根據(jù)丟包率和視頻延時判斷當(dāng)前網(wǎng)絡(luò)狀況.客戶端根據(jù)視頻數(shù)據(jù)包中的數(shù)據(jù)包序列號字段計算丟包率，根據(jù)時間戳字段計算視頻延時，結(jié)合兩者判斷當(dāng)前網(wǎng)絡(luò)狀況，并給監(jiān)控終端發(fā)送反饋信息報.反饋信息包的格式如圖2所示.

圖2 視頻數(shù)據(jù)包和反饋信息包

監(jiān)控終端通過服務(wù)器給客戶端發(fā)送視頻數(shù)據(jù)，客戶端通過視頻數(shù)據(jù)包前面的信息包頭判斷網(wǎng)絡(luò)狀況，并把網(wǎng)絡(luò)狀況通過反饋信息報反饋給終端，終端根據(jù)網(wǎng)絡(luò)狀況計算新的碼率.綜上所述，整個系統(tǒng)的數(shù)據(jù)傳輸模型如圖3所示.

圖3 數(shù)據(jù)傳輸模型

2 碼率調(diào)控策略

系統(tǒng)控制策略主要是根據(jù)網(wǎng)絡(luò)狀況來自適應(yīng)調(diào)整視頻碼率.首先根據(jù)丟包率和視頻延時來判斷當(dāng)前網(wǎng)絡(luò)狀況，把網(wǎng)絡(luò)狀況分為空閑、輕載、滿載、過載和擁塞5個等級.根據(jù)改進(jìn)的AIMD算法來計算新的碼率.為了保證視頻圖像質(zhì)量，在減小碼率的同時，減小幀率.

2.1 網(wǎng)絡(luò)狀況判定

網(wǎng)絡(luò)狀況的判定主要有兩種方式:基于包丟失相關(guān)標(biāo)志量和基于時間相關(guān)標(biāo)志量兩種方式［5］.基于包丟失標(biāo)志量的計算方式目前比較成熟，可靠性好，運(yùn)算復(fù)雜度低，容易實(shí)現(xiàn).目前大多數(shù)算法都采用丟包率來判斷網(wǎng)絡(luò)狀況［1-2，6］.但丟包率有滯后性，當(dāng)網(wǎng)絡(luò)出現(xiàn)丟包時，再來調(diào)整就已經(jīng)有點(diǎn)遲了.基于時間標(biāo)志量的計算能更好地反映網(wǎng)絡(luò)狀況，在一定程度上能預(yù)測網(wǎng)絡(luò)質(zhì)量的變化.文獻(xiàn)［3］提出了基于RTT(往返時延)的網(wǎng)絡(luò)判定方法，在控制的實(shí)時性、網(wǎng)絡(luò)狀態(tài)的震蕩抑制等方面均有明顯的改善.文獻(xiàn)［4］提出了基于時延抖動的判定方法，能在丟包之前預(yù)先判斷網(wǎng)絡(luò)變化，但實(shí)驗基于局域網(wǎng)仿真，無法真實(shí)反映網(wǎng)絡(luò)狀況.文獻(xiàn)［7-8］結(jié)合丟包率和RTT兩種標(biāo)志量判斷網(wǎng)絡(luò)狀況，可以有效提高碼流的平穩(wěn)性，但實(shí)驗也是僅基于局域網(wǎng)環(huán)境.基于此，本文利用包丟失標(biāo)志量和時間標(biāo)志量綜合使用丟包率和視頻延時判斷網(wǎng)絡(luò)狀況.

2.1.1 丟包率

為了計算丟包率，需要知道預(yù)計接收包的數(shù)目和已經(jīng)接收包的數(shù)目，這可以根據(jù)數(shù)據(jù)包前面的信息包頭中數(shù)據(jù)包序列號字段得出.為了防止丟包率出現(xiàn)較大的隨機(jī)波動，采用加權(quán)平均算法來計算丟包率.把兩次碼率調(diào)整的時間間隔平均分為p段，設(shè)每一段的丟包率為 λi，i=1，2，…，p，則加權(quán)平均后的丟包率為

由于丟包率有滯后性，所以根據(jù)丟包率的變化趨勢來預(yù)測下一時間段的丟包率.對p段的相鄰丟包率差值也做加權(quán)平均處理，設(shè)相鄰時間段丟包率的差值為 vi=λi+1－λi，i=1，2，…，p－1，則加權(quán)平均后的相鄰時間段的丟包率差值為

結(jié)合加權(quán)平均后的丟包率和丟包率差值，預(yù)測下一時間段的丟包率為

使用預(yù)測得到的丟包率可以在一定程度上避免丟包率的滯后性.

2.1.2 視頻延時

視頻延時是指視頻數(shù)據(jù)自產(chǎn)生到客戶端接收時的時間差值(不包括解碼的時間).在監(jiān)控終端，視頻幀分包后，并不會立即發(fā)送出去，而是存儲在環(huán)形緩存里等待發(fā)送.數(shù)據(jù)包到達(dá)服務(wù)器后，也不會立即發(fā)送到客戶端，也是存儲在環(huán)形緩存里等待發(fā)送.所以，視頻延時是多個因素造成的，包括處理延時，傳輸延時和等待延時(在緩存中堆積的時間).碼率過高，網(wǎng)絡(luò)質(zhì)量變差，CPU繁忙，都會增大視頻延時.視頻延時太大，說明視頻碼率太高，系統(tǒng)來不及處理，可能現(xiàn)在還沒有丟包，但很快就會丟包甚至擁塞.

在視頻數(shù)據(jù)包的時間戳字段中填入視頻幀的產(chǎn)生時間，由于絕對時間需要的字節(jié)數(shù)太多，所以使用相對時間，即時間戳字段保存的是視頻幀產(chǎn)生時相對于終端開始運(yùn)行時的時間差.設(shè)終端開始運(yùn)行時的時間為Tdb，視頻幀產(chǎn)生的時間為Tde，則時間戳字段保存的是時間差為

在客戶端計算的也是相對于終端開始運(yùn)行時的時間差，但客戶端并不知道終端開始運(yùn)行的時間，所以終端開始運(yùn)行時首先登陸服務(wù)器，服務(wù)器開始計時，同時給所有在線的客戶端發(fā)送一個通知，客戶端接收到此通知后開始計時.設(shè)客戶端開始計時時間為Tcb，客戶端接收到完整視頻幀時的時間為Tce，時間差為

如果客戶端登陸晚于終端登陸，則還需要在服務(wù)器上的計時時間.設(shè)服務(wù)器開始計時時間為Tsb，客戶端登陸服務(wù)器的時間為Tse，該時間差為

結(jié)合式(4)、(5)和(6)，可以得到視頻幀自產(chǎn)生到客戶端接收到該視頻幀的時間差為

如果客戶端登陸比終端登陸較早，則Tsd=0，否則大于0.這樣計算出的延時只和相對時間有關(guān)，不涉及到絕對時間，所以即使終端服務(wù)器和客戶端各自的時鐘不一樣也不會影響結(jié)果.視頻延時的計算過程如圖4所示.

圖4 視頻延時計算示意圖

和丟包率相同，也采用加權(quán)平均算法來求取兩次碼率調(diào)整間的平均視頻延時，并根據(jù)變化趨勢來預(yù)測下一時間段的視頻延時，使用預(yù)測的視頻延時來判斷網(wǎng)絡(luò)狀況.

2.1.3 網(wǎng)絡(luò)狀況定義

根據(jù)丟包率和視頻延時兩個標(biāo)志量，把當(dāng)前網(wǎng)絡(luò)狀況分為5類:空閑(網(wǎng)絡(luò)帶寬使用很少)、輕載(網(wǎng)絡(luò)帶寬沒有充分利用)、滿載(網(wǎng)絡(luò)處于正常傳輸狀態(tài))、過載(即將發(fā)生擁塞)和擁塞.5種網(wǎng)絡(luò)狀況按如下方法判定:①空閑.沒有丟包，視頻延時極小，λloss＜λ0，Tdelay＜t0.② 輕載.丟包極少，視頻延時很小，λloss＜λ1，Tdelay＜t1.③ 滿載.偶爾有丟包，視頻延時適中，λloss＜λ2，Tdelay＜t2.④ 過載:丟包頻繁，視頻延時較大，λloss＜ λ3，Tdelay＜ t3.⑤ 擁塞.丟包嚴(yán)重或視頻延時很大，λloss≥λ4或 Tdelay≥t4.

2.2 碼率調(diào)整

2.2.1 改進(jìn)的AIMD算法

碼率調(diào)整是實(shí)現(xiàn)系統(tǒng)平穩(wěn)性、TCP友好性的關(guān)鍵.基于試探的碼率調(diào)整是比較常用的方法.這種方法的基本思想是:輕載時，試探性增加碼率使其接近有效帶寬；擁塞時，則立即降低碼率，緩解擁塞.目前，一般采用加性增乘性減(AIMD)算法或這種算法的改進(jìn)算法來調(diào)節(jié)碼率［5，9-10］.AIMD 算法一般表示為

式中，α≥0，0≤β ＜1，ν(t－1)和 ν(t)分別表示t－1和t時刻的碼率；α和β可以是常數(shù)，也可以是變常數(shù).常數(shù)加增長和常數(shù)乘減少方法計算簡單，實(shí)現(xiàn)起來比較容易，但碼率波動太大.文獻(xiàn)［4，11-12］采用了變常數(shù)加增長和變常數(shù)乘減少的方法，可以有效解決碼率波動大的問題，但計算較為復(fù)雜.為了同時解決碼率波動和計算復(fù)雜度的問題，對AIMD算法進(jìn)行如下改進(jìn):

在前面已經(jīng)把網(wǎng)絡(luò)狀況分為空閑、輕載、滿載、過載和擁塞5個等級.針對這5種網(wǎng)絡(luò)狀況，對碼率進(jìn)行調(diào)整.基本原則是:① 擁塞，采用乘減少的方式迅速減小碼率.②過載，采用常數(shù)減少的方式減小碼率.③ 滿載，保持碼率不變.④ 輕載，采用常數(shù)加增長的方式慢慢增大碼率.⑤ 空閑，采用常數(shù)加增長的方式快速增大碼率.調(diào)整策略如下式所示:

2.2.2 多客戶端

如果有多個客戶端同時請求一個終端視頻，則每一個終端計算出來的網(wǎng)絡(luò)狀況可能并不相同，因為每一個客戶端和服務(wù)器之間的網(wǎng)絡(luò)帶寬是不一樣的.這時有兩個辦法來計算終端的碼率:①按最差的網(wǎng)絡(luò)狀況來計算碼率；②對多個客戶端的網(wǎng)絡(luò)狀況求取平均值.第1種計算方法有時候會不太合理，如果一個客戶端的網(wǎng)絡(luò)狀況太差，所有的客戶端也只能得到較低的碼率.這里采用第2種方法，用1～5五個整數(shù)來代表5種網(wǎng)絡(luò)狀況.設(shè)同時請求該終端視頻的客戶端數(shù)為n，5種網(wǎng)絡(luò)狀況的客戶端數(shù)分別為 ni，i=1，2，…，5，則得到的平均網(wǎng)絡(luò)狀況為

式中，［ ］為取整符號.終端根據(jù)此平均網(wǎng)絡(luò)狀況來計算新的碼率值.

2.3 幀率調(diào)整

幀率并不影響視頻流的大小，所以調(diào)整幀率并不能改善網(wǎng)絡(luò)擁塞狀況.但幀率影響視頻的清晰度，在碼率一定的情況下，幀率越小，單個的視頻幀越清晰.所以在減小碼率時，為了保證視頻幀的清晰度，就不得不降低幀率.設(shè)幀率為fr，碼率為br，按照碼率計算幀率:

式(11)表示當(dāng)碼率在b1和b2之間變化時，幀率在f1和f2之間線性變化.

3 結(jié)果及分析

基于上述算法，對系統(tǒng)進(jìn)行了測試.服務(wù)器程序運(yùn)行在某市聯(lián)通服務(wù)器上，監(jiān)控終端和客戶端都通過聯(lián)通3G網(wǎng)絡(luò)和服務(wù)器傳輸數(shù)據(jù).為了有效觀察算法效果，選擇3G網(wǎng)絡(luò)比較繁忙的時間段，并用文獻(xiàn)［3，6］介紹的算法與本文提出的算法進(jìn)行對比.

首先對文獻(xiàn)［3］提出的基于RTT的自適應(yīng)控制算法所進(jìn)行測試.結(jié)果發(fā)現(xiàn)，在3G網(wǎng)絡(luò)環(huán)境下，基于該算法得到的碼率波動太大，而且碼率恢復(fù)需要的時間較長.另外，該算法把最小RTT作為一個常數(shù)，但最小RTT是一個根據(jù)網(wǎng)絡(luò)質(zhì)量變化的變量.所以，該算法對于3G這種網(wǎng)絡(luò)質(zhì)量頻繁變化的場合并不適用.

圖5是根據(jù)文獻(xiàn)［6］提出的自適應(yīng)流量控制算法和本文提出的算法所得到的碼率變化曲線對比.

圖5 碼率變化曲線對比

文獻(xiàn)［6］使用RTT和丟包率來調(diào)整碼率，本文使用視頻延時和丟包率來調(diào)整碼率.圖6是根據(jù)兩種算法所得到的丟包率對比，表1是詳細(xì)數(shù)據(jù)對比.

表1 兩種算法數(shù)據(jù)對比

從圖5、圖6和表1可以看出，在3G網(wǎng)絡(luò)環(huán)境下，本文提出的算法在碼率波動和丟包率兩方面都要優(yōu)于文獻(xiàn)［6］提出的算法.視頻延時和RTT的主要區(qū)別在于RTT并不包括視頻數(shù)據(jù)包在終端和服務(wù)器的等待延時和處理延時.由于視頻延時加入了等待延時和處理延時，因此，視頻延時對于網(wǎng)絡(luò)質(zhì)量變化反應(yīng)較為“遲鈍”，而RTT更為“敏感”，但很多時候，由于3G網(wǎng)絡(luò)的不穩(wěn)定，3G網(wǎng)絡(luò)并不是真正的擁塞，只是發(fā)生了短暫的網(wǎng)絡(luò)質(zhì)量波動.因此，在這種情況下，RTT的“敏感”反而會加大碼率的波動進(jìn)而造成更多的丟包.另外，過多的視頻數(shù)據(jù)包在終端和服務(wù)器等待是引發(fā)網(wǎng)絡(luò)質(zhì)量變化的一個重要因素，而視頻延時可以反映出在終端和服務(wù)器等待的數(shù)據(jù)包數(shù)量，如果等待的數(shù)據(jù)包過多，視頻延時就會增大，從而可以提前減小碼率以防丟包或者擁塞，而RTT則不能.

圖6 丟包率對比

無論網(wǎng)絡(luò)質(zhì)量變差還是系統(tǒng)太過繁忙來不及處理，都會加大視頻延時，前者增大數(shù)據(jù)包傳輸延時，后者增大處理延時和等待延時.不論哪一種原因造成的視頻延時，都說明當(dāng)前碼率超出了系統(tǒng)的處理能力，所以當(dāng)視頻延時增大時就要減小碼率.而RTT則只能反映出網(wǎng)絡(luò)質(zhì)量變差，并不能反映出等待延時和處理延時.

4 結(jié)語

本文針對基于3G網(wǎng)絡(luò)的視頻監(jiān)控系統(tǒng)提出了一種碼率自適應(yīng)調(diào)整算法。在深入分析現(xiàn)有碼率調(diào)控策略的缺陷后，提出了一種結(jié)合丟包率和視頻延時兩個特征量來判斷網(wǎng)路狀況，并根據(jù)改進(jìn)的AIMD算法來調(diào)整碼率的自適應(yīng)調(diào)整算法。理論分析和實(shí)驗結(jié)果表明，相比現(xiàn)有算法，在3G網(wǎng)絡(luò)下，采用本文介紹的視頻延時和丟包率來調(diào)整碼率的方法，碼率波動和丟包率都得到了很大的改善。

References)

［1］王正君，王友釗.基于RTCP的閉環(huán)碼率調(diào)控和流量整型策略［J］.計算機(jī)科學(xué)，2011，38(7):100-102.Wang Zhengjun，Wang Youzhao.Strategy of closedloop rate control and traffic shaping based on RTCP［J］.Computer Science，2011，38(7):100-102.

［2］程萬祥，張軼博，雷振明.平穩(wěn)的RTP自適應(yīng)算法［J］.齊齊哈爾大學(xué)學(xué)報，2002，18(1):45-48.Cheng Wanxiang，Zhang Yibo，Lei Zhenming.A modified RTP adaptive arithmetic［J］.Journal of Qiqihar U-niversity，2002，18(1):45-48.(in Chinese)

［3］朱利，周俊輝，鄭守淇，等.基于RTT的自適應(yīng)控制擁塞研究［J］.計算機(jī)學(xué)報，2000，23(7):705-710.Zhu Li，Zhou Junhui，Zheng Shouqi，et al.Research on adaptive congestion control based on RTT［J］.Chinese J Computers，2000，23(7):705-710.(in Chinese)

［4］萬正道，楊永超.基于RTP的實(shí)時多媒體數(shù)據(jù)網(wǎng)絡(luò)傳輸擁塞控制策略［J］.自動化技術(shù)與應(yīng)用，2010，29(7):44-46.Wan Zhengdao，Yang Yongchao.The congestion control strategy of real-time multimedia data transmitting over the network［J］.Techniques of Automation and Application，2010，29(7):44-46.(in Chinese)

［5］于溯，盛彥瑾，黃凱，等.RTP自適應(yīng)傳輸控制算法的研究［J］.計算機(jī)工程與科學(xué)，2005，27(11):52-56.Yu Su，Sheng Yanjan，Huang Kai，et al.Research on the algorithm of RTP adaptive transmission control［J］.Computer Engineering ＆ Science，2005，27(11):52-56.(in Chinese)

［6］Tos Uras，Ayav Tolga.Adaptive RTP rate control method［C］//Computer Software and Applications Conference Workshops.Munich，Germany，2011:7-12.

［7］蔣建國，蘇兆品，李援，等.RTP/RTCP自適應(yīng)流量控制算法［J］.電子學(xué)報，2006，34(9):1659-1662.Jiang Jianguo，Su Zhaopin，Li Yuan，et al.Adaptive flow control algorithm for RTP/RTCP［J］.Acta Electronic Sinica，2006，34(9):1659-1662.(in Chinese)

［8］Schiopu P，Apetrechioaie B，Mateescu L.High resolution video acquisition and transmission system，using DSP［C］//IEEE 17th International Symposium for Design and Technology in Electronic Packaging.Timisoara，2011:273-276.

［9］巴洪濤，陳耀武，周蓉.監(jiān)控系統(tǒng)中實(shí)時視頻流碼率動態(tài)調(diào)整機(jī)制的研究［J］.計算機(jī)科學(xué)，2010，37(4):296-298.Ba Hongtao，Chen Yaowu，Zhou Rong.Studis on dynamic adjustment mechanism of real-time video streaming on surveillance system［J］.Computer Science，2010，37(4):296-298.(in Chinese)

［10］Sivabalakrishna M，Manjula D.Analysis of decision feedback using RTCP for multimedia streaming over3G［C］//Proceedings of the International Conference on Computer and CommunicationEngineering.KualaLumpur，Malaysia，2008:1023-1026.

［11］El-Marakby Randa.Enhanced Qos for real-time multimedia delivery over the wireless link using RFID technology［C］//IEEE International Symposium on Signal Processing and Information Technology.Vancouver，BC，USA，2006:728-734.

［12］Huang Yih，Xu Genwen，Huang Leijun.Adaptive AIMD rate control for smooth multimedia streaming［C］//Proceedings of Computer Communications and Networks.Fairfax，VA，2003:171-177.