林 銳，劉 峰

(南京郵電大學(xué)圖像處理與圖像通信江蘇省重點(diǎn)實(shí)驗(yàn)室，南京 210003)

視頻業(yè)務(wù)的快速發(fā)展占用了互聯(lián)網(wǎng)中大量帶寬，如何在有限的帶寬下提供更高質(zhì)量的服務(wù)成為研究的熱點(diǎn)。一方面，新的視頻壓縮技術(shù)快速發(fā)展，相同質(zhì)量的視頻所需要的碼率越來越小;另一方面，許多專家提出并改善眾多自適應(yīng)的流媒體傳輸方案，在自適應(yīng)流媒體系統(tǒng)中，系統(tǒng)可以根據(jù)帶寬和客戶端的設(shè)備條件提供不同質(zhì)量級(jí)別的視頻，充分利用帶寬。

早期，人們認(rèn)為TCP協(xié)議作為一個(gè)面向連接的協(xié)議，其重傳機(jī)制和擁塞控制機(jī)制都不適用于實(shí)時(shí)多媒體傳輸?shù)摹Ｒ虼?，早期大量的視頻流傳輸都是基于UDP(或者RTP over UDP)協(xié)議的［1］。然而，近年的研究表明，當(dāng)該系統(tǒng)能夠自適應(yīng)于網(wǎng)絡(luò)變化時(shí)［1］，TCP的擁塞控制和可靠性傳輸并不會(huì)影響流媒體系統(tǒng)的表現(xiàn)。因此，不再使用傳統(tǒng)的流媒體協(xié)議，如RTP/RTCP，而使用基于HTTP的方式進(jìn)行內(nèi)容分發(fā)是目前流媒體發(fā)展的趨勢(shì)?；贖TTP方式的下載在服務(wù)器的構(gòu)架上比專門的流媒體服務(wù)器下載更便宜;HTTP服務(wù)常用的80端口所有防火墻和路由器都放行，而傳統(tǒng)的流媒體協(xié)議通常對(duì)防火墻和路由器有特別的要求，UDP包傳送的時(shí)候會(huì)要求特別的網(wǎng)絡(luò)端口;在HTTP服務(wù)器上，媒體文件和其他的別的文件一樣直接緩沖在服務(wù)器上，不要求特別的代理和緩沖。

本文首先介紹了基于HTTP的流媒體系統(tǒng)的現(xiàn)況，然后介紹了本文的基于HTTP長(zhǎng)連接［2］的自適應(yīng)流媒體傳輸系統(tǒng)的總體設(shè)計(jì)，各功能模塊及其之間相互關(guān)系和該系統(tǒng)所采用的自適應(yīng)控制策略，接著給出實(shí)驗(yàn)結(jié)果，最后給出總結(jié)。

1 基于HTTP的流媒體系統(tǒng)

漸進(jìn)式下載是一種基于HTTP的流媒體系統(tǒng)的分發(fā)方式，它是一種簡(jiǎn)單的從HTTP WEB服務(wù)器進(jìn)行文件下載的普通方式。該種方式將播放內(nèi)容直接放在瀏覽器的緩存里，客戶端在下載的同時(shí)播放媒體內(nèi)容，不用等到整個(gè)文件下載完成;然而HTTP WEB服務(wù)器會(huì)在媒體文件下載完成之前一直傳送數(shù)據(jù)流，造成客戶端數(shù)據(jù)的大量累積，浪費(fèi)不必要的網(wǎng)絡(luò)資源。現(xiàn)在流行的視頻網(wǎng)站，比如說Youtube、優(yōu)酷網(wǎng)、土豆網(wǎng)，幾乎都是在使用漸進(jìn)式下載技術(shù)。

近年來出現(xiàn)了基于HTTP的自適應(yīng)流媒體傳輸系統(tǒng)，常見的有:Apple公司的HTTP Live Streaming(HLS)，微軟的 SilverLight Smooth Streaming［3］，以及 Adobe 的 HTTP Dynamic Streaming。這些系統(tǒng)都將視頻源切割成一個(gè)個(gè)數(shù)秒大小的視頻端(切片)，并把每一段視頻轉(zhuǎn)碼成不同的質(zhì)量級(jí)別;客戶端首先向服務(wù)器請(qǐng)求一個(gè)播放列表，播放列表中包含切片的基本信息(如切片持續(xù)時(shí)間，開始時(shí)間戳，以及先后順序)，然后再按播放列表根據(jù)網(wǎng)絡(luò)狀況和緩存情況適時(shí)的向服務(wù)器請(qǐng)求相應(yīng)質(zhì)量級(jí)別的切片，這樣使用戶得到在不同帶寬條件下的較佳體驗(yàn)［4］?？梢园l(fā)現(xiàn)，這些系統(tǒng)客戶端每下載一個(gè)切片，客戶端就需要和服務(wù)器重新建立一次連接;并且客戶端需要隨時(shí)更新播放列表才能從服務(wù)器獲得正確的切片。此外，由于系統(tǒng)的自適應(yīng)功能是由客戶端驅(qū)動(dòng)的，用戶均需要下載特定的播放器，如微軟的要安裝Silverlight插件，HLS只適用于Apple的一些系統(tǒng)中［3］。

為此，本文提出一種基于HTTP長(zhǎng)連接的自適應(yīng)流媒體傳輸系統(tǒng)，在該系統(tǒng)中，用戶向服務(wù)器發(fā)出請(qǐng)求后，服務(wù)器和客戶端就會(huì)建立一個(gè)HTTP長(zhǎng)連接，然后服務(wù)器根據(jù)網(wǎng)絡(luò)狀況和發(fā)送情況適時(shí)的向客戶端發(fā)送相應(yīng)質(zhì)量和時(shí)間段的切片。該系統(tǒng)不僅利用了HTTP長(zhǎng)連接技術(shù)，有效的減少頻繁建立連接帶來的網(wǎng)絡(luò)資源開銷;同時(shí)采取了服務(wù)器端驅(qū)動(dòng)的自適應(yīng)控制策略，對(duì)客戶端的要求較低，具有很強(qiáng)的通用性。

2 系統(tǒng)設(shè)計(jì)

基于HTTP的自適應(yīng)流媒體傳輸系統(tǒng)主要利用HTTP長(zhǎng)連接和服務(wù)器端驅(qū)動(dòng)的自適應(yīng)控制策略。傳統(tǒng)的基于HTTP的流媒體系統(tǒng)通常采用HTTP短連接，即客戶端每接收一個(gè)切片，都需要像服務(wù)器發(fā)出請(qǐng)求，然后建立連接，發(fā)送數(shù)據(jù)，而切片通常很短，因而客戶端和服務(wù)器之間就在頻繁的建立和斷開連接，對(duì)網(wǎng)絡(luò)資源造成浪費(fèi)。為此本文采取HTTP長(zhǎng)連接，即客戶端與服務(wù)器端先建立連接，連接建立后就不再斷開，然后再進(jìn)行報(bào)文發(fā)送和接收，這種方式下由于通信連接的一直存在，就避免了客戶端向服務(wù)器請(qǐng)求切片時(shí)頻繁的建立和斷開連接［2］。服務(wù)器端驅(qū)動(dòng)的自適應(yīng)控制算法指的是服務(wù)器端監(jiān)測(cè)客戶端的播放狀況和當(dāng)前的網(wǎng)絡(luò)環(huán)境，并根據(jù)其監(jiān)測(cè)結(jié)果發(fā)送相應(yīng)的數(shù)據(jù)給客戶端。

2.1 總體設(shè)計(jì)

該系統(tǒng)中包括源端、服務(wù)器和客戶端3個(gè)部分組成，其中服務(wù)器為主要部分，它包括:源多碼率模塊、子流切片模塊、切片管理模塊、客戶端緩存區(qū)控制模塊、帶寬監(jiān)測(cè)模塊、自適應(yīng)控制模塊和網(wǎng)絡(luò)發(fā)送模塊。如圖1所示。源端將節(jié)目源發(fā)送至服務(wù)器，服務(wù)器對(duì)節(jié)目源進(jìn)行相應(yīng)處理等待并響應(yīng)客戶端的請(qǐng)求，客戶端接收切片并播放，整個(gè)系統(tǒng)中服務(wù)器為主要部分。

圖1 系統(tǒng)設(shè)計(jì)總體框圖

服務(wù)器的源多碼率模塊將節(jié)目源下采樣成多種碼率級(jí)別，然后子流切片模塊將其得到的各個(gè)碼率級(jí)別的子流進(jìn)行切片，將得到的切片送到切片管理模塊中，等待客戶端的請(qǐng)求，當(dāng)客戶端向服務(wù)器發(fā)送請(qǐng)求時(shí)，兩者之間就建立起一個(gè)長(zhǎng)連接，客戶端緩存區(qū)控制模塊監(jiān)測(cè)客戶端播放狀況以及緩存區(qū)狀況，帶寬監(jiān)測(cè)模塊監(jiān)測(cè)當(dāng)前的網(wǎng)絡(luò)狀況，自適應(yīng)控制模塊根據(jù)客戶端緩存區(qū)控制模塊和帶寬監(jiān)測(cè)模塊的結(jié)果控制網(wǎng)絡(luò)發(fā)送模塊向客戶端適時(shí)發(fā)送相應(yīng)數(shù)據(jù)。

源多碼率模塊是指將高碼率高分辨率的節(jié)目源通過下采樣的方法轉(zhuǎn)化為多種碼率級(jí)別的節(jié)目子流，這里的多種碼率級(jí)別指的是相同分辨率下的不同碼率級(jí)別。

子流切片模塊是指將每個(gè)子流切割成一個(gè)個(gè)4～6 s的切片，每一個(gè)切片由若干個(gè)GoP(視頻圖像組)組成，對(duì)于不同碼率的同一段切片，要保證開始和結(jié)束的時(shí)間戳一致。該模塊產(chǎn)生的切片由切片管理模塊統(tǒng)一管理和調(diào)配，方便客戶端的請(qǐng)求及服務(wù)器的選擇。

客戶端的緩存區(qū)應(yīng)保持在一個(gè)安全的范圍，如果發(fā)送的太快，緩存區(qū)產(chǎn)生上溢，雖不影響用戶的體驗(yàn)，卻會(huì)造成網(wǎng)絡(luò)資源不必要的浪費(fèi);如果發(fā)送的太慢，緩存區(qū)產(chǎn)生下溢，則會(huì)讓客戶端播放產(chǎn)生停頓，影響用戶的觀看。因此客戶端緩存區(qū)控制模塊監(jiān)測(cè)客戶端的緩存區(qū)狀況，并將獲得的信息提供給自適應(yīng)控制模塊。

自適應(yīng)控制模塊根據(jù)客戶端緩存區(qū)控制模塊和帶寬監(jiān)測(cè)模塊的結(jié)果選擇相應(yīng)的發(fā)送時(shí)間和碼率，具體方法見2.2 節(jié)。

帶寬監(jiān)測(cè)模塊對(duì)網(wǎng)絡(luò)狀況進(jìn)行監(jiān)測(cè)，該模塊根據(jù)2.2節(jié)中介紹的帶寬預(yù)測(cè)方法進(jìn)行帶寬預(yù)測(cè)。而網(wǎng)絡(luò)發(fā)送模塊通過HTTP協(xié)議向客戶端發(fā)送相應(yīng)的切片。

2.2 系統(tǒng)采用的碼率自適應(yīng)控制策略

進(jìn)行自適應(yīng)碼率控制一方面要考慮所發(fā)送視頻的碼率級(jí)別是否與當(dāng)前的網(wǎng)絡(luò)狀況相符;另一方面還要考慮客戶端緩存區(qū)的數(shù)據(jù)量，如果客戶端緩存區(qū)的數(shù)據(jù)量太小，而發(fā)送的碼率級(jí)別比較大，則很有可能造成客戶端緩存區(qū)的下溢，影響客戶體驗(yàn)［5-7］。本文的自適應(yīng)碼率控制方法就是從這兩方面入手。

TCP的瞬時(shí)傳播速率是時(shí)刻變化的，所以用它來衡量網(wǎng)絡(luò)的傳送能力是不可行的。為此，本文利用相對(duì)較長(zhǎng)一段時(shí)間的平均帶寬來衡量當(dāng)前的網(wǎng)絡(luò)狀況，具體方法如下

假設(shè)當(dāng)前帶寬為Bi，則可以根據(jù)之前發(fā)送每片時(shí)的平均帶寬進(jìn)行預(yù)測(cè)，預(yù)測(cè)值為，預(yù)測(cè)值由之前發(fā)送的5片的平均帶寬 Bi－1，Bi－2，Bi－3，Bi－4，Bi－5得到。首先找到5 個(gè)帶寬中最小的2個(gè)Bk1，Bk2(Bk1＜Bk2);再通過二者的加權(quán)和得到預(yù)測(cè)值。λ1，λ2為加權(quán)因子，計(jì)算公式如下

式中:發(fā)送第i－k個(gè)切片時(shí)的平均帶寬為

式中:MSSi－k為第 i－ k個(gè)切片的大小;Tsi－k為發(fā)送第 ik個(gè)切片所用時(shí)間。

如果當(dāng)前的帶寬與發(fā)送切片的碼率相符，則說明當(dāng)前切片的碼率級(jí)別的選擇符合當(dāng)前的網(wǎng)絡(luò)狀況;如果當(dāng)前的帶寬小于發(fā)送切片的碼率，則說明選擇的碼率過大，需要切換到較低的碼率;如果當(dāng)前的帶寬大于發(fā)送切片的碼率，則說明選擇的碼率過小，需要切換到較低的碼率。因此，可以根據(jù)當(dāng)前平均帶寬的變化來控制即將發(fā)送切片的碼率。

設(shè)R1節(jié)目源經(jīng)過源多碼率模塊處理后產(chǎn)生N種碼率級(jí)別的子流，它們的碼率分別是R1，R2，…，RN。而客戶端緩存區(qū)中媒體流可以播放的時(shí)間用tm來表示，設(shè)客戶端緩存區(qū)中允許的最小的媒體流的播放時(shí)間為tmin。

自適應(yīng)控制流程如圖2所示。本文首先要保證客戶端的緩沖區(qū)數(shù)據(jù)在安全范圍內(nèi)，防止緩沖區(qū)下溢，如果一旦發(fā)現(xiàn)緩沖區(qū)下溢，則立即將碼率下調(diào)至最低級(jí)別，并立刻發(fā)送切片;其次根據(jù)相應(yīng)的原則對(duì)要發(fā)送切片的碼率進(jìn)行調(diào)整。

圖2 自適應(yīng)控制算法流程圖

式中μup和μdown為碼率切換的判斷系數(shù)。

當(dāng)系統(tǒng)滿足上調(diào)碼率級(jí)別的條件時(shí)，則將發(fā)送的下一切片的碼率級(jí)別比上一切片高一個(gè)級(jí)別;當(dāng)系統(tǒng)要下調(diào)碼率級(jí)別時(shí)，則將發(fā)送的下一切片的碼率級(jí)別Rnext調(diào)整至滿足如下條件

在進(jìn)行自適應(yīng)控制時(shí)，要保證客戶端的緩沖區(qū)在一個(gè)安全范圍內(nèi)，不能產(chǎn)生上溢，更不可發(fā)生下溢，為此，設(shè)定發(fā)送兩片的時(shí)間間隔為ts，

3 實(shí)驗(yàn)結(jié)果

本文將源端、服務(wù)器和客戶端放在一個(gè)局域網(wǎng)中，在客戶端通過Netlimiter軟件控制服務(wù)器與客戶端之間的網(wǎng)絡(luò)帶寬。本文的切片采用3種質(zhì)量級(jí)別550 kbit/s，950 kbit/s和1800 kbit/s，每個(gè)切片長(zhǎng)約4～6 s;而客戶端緩存區(qū)中媒體流允許的最小播放的時(shí)間為tmin=4000 ms。系統(tǒng)啟動(dòng)后，運(yùn)行穩(wěn)定，對(duì)發(fā)送的1500片進(jìn)行分析。

如圖3和圖4所示，本文系統(tǒng)在網(wǎng)絡(luò)環(huán)境發(fā)生變化時(shí)，能及時(shí)做出響應(yīng)，將要發(fā)送的切片的質(zhì)量級(jí)別切換至相應(yīng)的級(jí)別?？梢钥闯霎?dāng)網(wǎng)絡(luò)狀況穩(wěn)定在很好的狀況時(shí)，系統(tǒng)穩(wěn)定的發(fā)送最高質(zhì)量級(jí)別的切片，當(dāng)網(wǎng)絡(luò)狀況穩(wěn)定在較差的狀況時(shí)，系統(tǒng)發(fā)送的切片的質(zhì)量級(jí)別會(huì)出現(xiàn)波動(dòng)，但從圖5和表1中可以發(fā)現(xiàn)，此種狀況下，系統(tǒng)發(fā)送的大部分切片的質(zhì)量級(jí)別是與帶寬值相符的，而出現(xiàn)波動(dòng)的原因有二:一方面，發(fā)送切片的質(zhì)量級(jí)別是一個(gè)平均值，每一個(gè)切片的平均碼率是變化的，而當(dāng)設(shè)定的帶寬值與切片質(zhì)量級(jí)別相近時(shí)，會(huì)出現(xiàn)切片的平均碼率大于平均帶寬的狀況;另一方面，網(wǎng)絡(luò)的平均帶寬只是評(píng)價(jià)網(wǎng)絡(luò)狀況的一個(gè)指標(biāo)，網(wǎng)絡(luò)環(huán)境是時(shí)刻變化的，有可能出現(xiàn)擁塞等其他影響數(shù)據(jù)傳輸?shù)臓顩r出現(xiàn)。

圖3 網(wǎng)絡(luò)環(huán)境變化下的切片質(zhì)量級(jí)別分布—1

圖6展示的是客戶端緩存區(qū)中所剩數(shù)據(jù)可以播放的時(shí)間，從圖中可以看到，該時(shí)間絕大部分情況下大于tmin，并始終在0以上，說明沒有出現(xiàn)下溢的情況;同時(shí)，該時(shí)間在10 s附近上下浮動(dòng)，亦沒有出現(xiàn)顯著的上溢，說明本文系統(tǒng)讓客戶端緩存區(qū)保持在一個(gè)安全范圍內(nèi)，在保證客戶流暢觀看的條件下，節(jié)省了帶寬資源。

表1 不同帶寬穩(wěn)定狀況下切片質(zhì)量級(jí)別分布表

圖6 客戶端緩存區(qū)數(shù)據(jù)量的變化

4 結(jié)論

本文的基于HTTP長(zhǎng)連接的自適應(yīng)傳輸系統(tǒng)中客戶端無需安裝特殊的插件，具有很強(qiáng)的適應(yīng)性和通用性;同時(shí)，由于采用了HTTP長(zhǎng)連接，避免了客戶端向服務(wù)器請(qǐng)求切片時(shí)頻繁的建立和斷開連接，節(jié)省了網(wǎng)絡(luò)資源。

本文系統(tǒng)所采用的自適應(yīng)控制策略能夠很好的適應(yīng)網(wǎng)絡(luò)環(huán)境，當(dāng)網(wǎng)絡(luò)帶寬發(fā)生變化時(shí)，系統(tǒng)對(duì)推送的切片的質(zhì)量級(jí)別及時(shí)做出調(diào)整，同時(shí)在網(wǎng)絡(luò)狀況穩(wěn)定時(shí)，切片的質(zhì)量級(jí)別亦能基本符合帶寬狀況。本文系統(tǒng)實(shí)現(xiàn)了客戶端緩存區(qū)的數(shù)據(jù)量在一定范圍波動(dòng)，沒有發(fā)生下溢確保了客戶端的播放流暢，亦未發(fā)生上溢，防止了過度的數(shù)據(jù)累積。

［1］AKHSHABI S，BEGEN A C，DOVROLIS C.An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP［EB/OL］.［2011-07-15］.http://www.cc.gatech.edu/～ dovrolis/Papers/final-saamer-mmsys11.pdf.

［2］FIELDING R，GETTY J，MOGUL J，et al.Hypertext transfer protocol--HTTP/1.1［S］.1999.

［3］MA K J，MAN L，HUANGA，et al.Video rate adaptation in mobile devices via HTTP progressive download of stitched media files［J］.IEEE Trans.Multimedia，2011，15(3):320-322.

［4］JARNIKOV D，O?Z?ELEBI T.Client intelligence for adaptive streaming solutions［C］//IEEE International Conference on Multimedia and Expo(ICME).［S.l.］:IEEE Press，2010:1499-1504.

［5］LIU Chenghao，BOUAZIZI I，GABBOUJ M.Rate adaptation for adaptive HTTP streaming［C］//Proc.MMSys'11 Proceedings of the second annual ACM conference on Multimedia systems.San Jose:ACM Press，2011:169-174.

［6］李爭(zhēng)明，張佐，葉德鍵.自適應(yīng)流媒體傳輸方案研究及其應(yīng)用［J］.計(jì)算機(jī)工程，2006，32(12):226-228.

［7］祝睿杰，別紅霞.影響流媒體系統(tǒng)視頻質(zhì)量的關(guān)鍵參數(shù)仿真測(cè)試研究［J］.電視技術(shù)，2009，33(S2):228-231.