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