一種基于RTCP反饋的3G流媒體速率控制算法
加入技術(shù)交流群
2 發(fā)送速率控制算法
當客戶(hù)端向服務(wù)器發(fā)出服務(wù)請求后，服務(wù)器通過(guò)RTSP協(xié)議為客戶(hù)端配置連接屬性，并獲得網(wǎng)絡(luò )緩存和客戶(hù)端緩存Nmax和Cmax，完成流媒體會(huì )話(huà)的建立。會(huì )話(huà)建立后，服務(wù)器將媒體內容分割打包，標記序列號。并發(fā)送給客戶(hù)端。設第i個(gè)數據包的大小為Si，當服務(wù)器在會(huì )話(huà)初始時(shí)刻發(fā)送的第一個(gè)數據包序號為ISN=O，則在t時(shí)間內發(fā)送N個(gè)數據包的數據量為。服務(wù)器收到來(lái)自客戶(hù)端的RTCP反饋后，可以獲知RTCP RR報告產(chǎn)生時(shí)客戶(hù)端已接收的包序號HRSN，以及本地記錄的發(fā)送包序號，即當前已發(fā)送的最大包序號HTSN。序號HTSN與HRSN的差值表示為正在網(wǎng)絡(luò )中傳輸的數據包數目，假設這些數據包都暫存在網(wǎng)絡(luò )緩存中，那么可估計當前網(wǎng)絡(luò )緩存存儲狀態(tài)為：
因此，服務(wù)器每收到一個(gè)RTCP反饋包就可以由上式求得網(wǎng)絡(luò )緩存狀態(tài)?？蛻?hù)端收到的數據包預先存貯在終端緩存中，然后按時(shí)間戳順序送入解碼器解碼播放?？蛻?hù)端生成NADU反饋與序號為NSN的數據包預定播放時(shí)間之間的延遲為tPD，服務(wù)器接收到RTCP反饋的時(shí)間為tRR，序號為i的數據包預定播放時(shí)間即時(shí)間戳Ti，故有時(shí)間偏移toff：
這個(gè)時(shí)間偏移是RTCP反饋中NADU包從生成到被接收的時(shí)間，同時(shí)也考慮到了發(fā)生播放暫?；驍祿彌_的情況。服務(wù)器在收到反饋包后t時(shí)刻(t>tRR)可測知當前客戶(hù)端緩存的空余量為：
式中：FBS為NADU反饋的緩存可用空間；TNSN+toff為數據包NSN的實(shí)際解碼時(shí)間。由于式(3)沒(méi)有考慮服務(wù)器已經(jīng)發(fā)送，但客戶(hù)端尚未接收的數據包，故對上式作如下修正：
利用式(1)和式(4)，服務(wù)器在發(fā)送下一個(gè)數據包i=HTSN+1前，應做如下判斷：
當上述兩式同時(shí)成立時(shí)，表明網(wǎng)絡(luò )緩存和客戶(hù)端緩存尚有余量接收新的數據包，服務(wù)器繼續發(fā)送新的數據包是安全的。否則，服務(wù)器暫停發(fā)送直至上式中條件成立。進(jìn)一步考慮發(fā)送速率控制的有效性，對式(5)做如下修正：
式中：Nthrehold，Cthrehold為安全閾值，這個(gè)閾值可以保證在新的RTCP反饋到來(lái)前，不會(huì )因為不能及時(shí)判斷發(fā)送條件而造成緩存數據溢出。由式(1)和式(4)還可以看出，Ncurr估值略有偏高而Cfree估值略為偏低。這樣做是為了可以更有效地防止經(jīng)常性的網(wǎng)絡(luò )緩存數據上溢和移動(dòng)終端數據下溢的發(fā)生。
3 算法仿真
根據上述算法，用Matlab仿真，時(shí)長(cháng)為42 s的媒體內容以57 Kb／s的速率編碼，在服務(wù)器端均分為360個(gè)包。無(wú)線(xiàn)鏈路上的最大帶寬為64 Kb／s，在鏈路數據傳輸過(guò)程中有5 s的中斷。SGSN或RNC上的緩存最大值為160 Kb，客戶(hù)端緩存最大值為320 Kb，并在媒體應用前有3 s的預緩沖。設定安全閾值Nthrehold，Cthrehold分別為最大值的95％和90％?？蛻?hù)端RTCP反饋包的發(fā)送間隔為1 s。如果服務(wù)器對發(fā)送速率不加控制時(shí)，網(wǎng)絡(luò )緩存與客戶(hù)端緩存中的數據量如圖3，圖4所示?？蛻?hù)端在41 s左右緩存開(kāi)始發(fā)生數據溢出，網(wǎng)絡(luò )緩存在45～50 s之間由于無(wú)線(xiàn)鏈路發(fā)生中斷，網(wǎng)絡(luò )緩存中數據量急劇上升并發(fā)生數據上溢。圖5為服務(wù)器的發(fā)送速率。
評論