專利名稱：基于實時傳輸/控制協(xié)議的h.264流媒體傳輸控制方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種流媒體傳輸控制方法，具體是涉及H.264的基于實時傳輸/控制協(xié)議(RTP/RTCP)視頻傳輸?shù)陌l(fā)送控制方法。
背景技術(shù)：
隨著Internet和多媒體技術(shù)的快速發(fā)展，視頻的網(wǎng)絡(luò)實時傳輸成為網(wǎng)絡(luò)應(yīng)用的研究熱點之一。H.264標(biāo)準(zhǔn)以其高壓縮率、高質(zhì)量、低碼率成為目前和下一代網(wǎng)上多媒體傳輸?shù)闹饕袷胶蜆?biāo)準(zhǔn)。視頻的實時傳輸要求傳輸?shù)臅r延要小、丟包率要低，然而由于TCP(傳輸控制協(xié)議)的重發(fā)機制帶來較大時延，UDP(用戶數(shù)據(jù)報協(xié)議)本身又不提供任何QOS保證，因此需要新的協(xié)議來滿足網(wǎng)絡(luò)視頻傳輸對時延和丟包的高要求。RTP/RTCP可解決上述問題，RTP報文用來傳輸實時數(shù)據(jù)，可以靈活改變發(fā)送速率，并可防止傳輸順序混亂；而RTCP報文在傳輸過程中為RTP數(shù)據(jù)提供網(wǎng)絡(luò)狀況和服務(wù)質(zhì)量的反饋信息。二者結(jié)合可以提供可靠的端到端傳輸，并能適應(yīng)帶寬需要和和提供音視頻同步控制機制，因此被越來越多的流媒體服務(wù)所采用。
在基于RTP/RTCP的流媒體服務(wù)中，研究RTP包的自適應(yīng)傳輸控制具有十分重要的作用。該控制方法通過反饋的網(wǎng)絡(luò)狀況、服務(wù)質(zhì)量信息來調(diào)整服務(wù)器端的發(fā)送速率，一方面可以降低端到端的延遲，另一方面可防止網(wǎng)絡(luò)擁塞，保證一定的服務(wù)質(zhì)量，實現(xiàn)端到端的流量控制。因此，隨著流媒體服務(wù)的進一步發(fā)展，這類算法正受到越來越多的重視。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，可有效進行Server-Client(服務(wù)器端-客戶端)之間的傳輸控制；客戶端提供準(zhǔn)確有效的反饋信息，在不增加網(wǎng)絡(luò)負(fù)載的前提下，通過調(diào)整服務(wù)器端的發(fā)送機制來提高H.264視頻流的質(zhì)量。
為了達(dá)到上述目的，本發(fā)明提供了一種基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，利用RTCP反饋信息實現(xiàn)控制，其包含以下步驟步驟1、服務(wù)器端構(gòu)造SR報文和APP報文，以恒定的發(fā)送速率向客戶端發(fā)送RTCP-SR控制信息和RTCP-APP探測包；所述的RTCP-APP探測包用來探測網(wǎng)絡(luò)帶寬變化情況，由于RTCP-APP探測包體積小且使用靈活，故不會給網(wǎng)絡(luò)帶來負(fù)擔(dān)；步驟2、客戶端接收并解析服務(wù)器端發(fā)送的RTCP-SR和RTCP-APP報文，構(gòu)造RTCP-RR和RTCP-APP反饋報文并以恒定的發(fā)送速率發(fā)送至服務(wù)器端；步驟3、服務(wù)器端在接收客戶端反饋的RTCP-RR和RTCP-APP報文后解析，獲取參數(shù)往返時間、網(wǎng)絡(luò)延時、丟包率，分析得出當(dāng)前網(wǎng)絡(luò)帶寬和運行狀況；步驟4、服務(wù)器端根據(jù)分析得到的網(wǎng)絡(luò)狀況，進行參數(shù)調(diào)整，通過調(diào)整視頻基本流的RTP包大小和發(fā)送速率來實現(xiàn)服務(wù)器端的發(fā)送控制。
步驟1中，服務(wù)器端以每間隔1s的恒定發(fā)送速率向客戶端發(fā)送1次RTCP-APP探測包，以每間隔5s的恒定發(fā)送速率向客戶端發(fā)送1次RTCP-SR控制信息。
步驟2中，客戶端以每間隔1s的恒定發(fā)送速率向服務(wù)器端發(fā)送1次RTCP-APP探測包反饋報文，以每間隔5s的恒定發(fā)送速率向服務(wù)器端發(fā)送1次RTCP-SR反饋報文。
所述的步驟3包含以下步驟步驟3.1、根據(jù)RTCP-RR報文中的反饋信息，計算參數(shù)步驟3.1.1、計算往返時間RTT(Round-Trip time)RTT＝T-LSR，其中，T表示服務(wù)器端收到RTCP-RR反饋報文的時刻，LSR(Last SR timestamp)表示上一個RTCP-SR的時間戳；步驟3.1.2、計算網(wǎng)絡(luò)傳輸延時TdelayTdelay＝(T-LSR-DLSR)/2，其中，T表示服務(wù)器端收到RTCP-RR反饋報文的時刻，LSR表示上一個RTCP-SR的時間戳；DLSR(Delay since last SR)表示自上一個RTCP-SR后的延遲；步驟3.1.3、計算丟包率PlossPloss＝Pn/256，其中，Pn為RTCP-RR報文中的分組丟失率字段；步驟3.2、根據(jù)往返時間RTT和丟包率Ploss來判斷當(dāng)前的網(wǎng)絡(luò)狀態(tài)；所述的網(wǎng)絡(luò)狀態(tài)具體分為輕載(Unloaded)、負(fù)載(Loaded)、輕塞(LightCongested)和擁塞(Congested)四種；步驟3.2.1、更新平均往返時間RTT平均RTT平均＝(1-平滑因子)×RTT平均+平滑因子×RTT當(dāng)前，其中，0.5＜平滑因子＜0.75；當(dāng)服務(wù)器端得到第一個RTT時，即初始狀態(tài)時，定義RTT平均＝RTT當(dāng)前；RTT負(fù)載＝0.25×RTT當(dāng)前；RTT非負(fù)載＝0.75×RTT當(dāng)前；步驟3.2.2、若RTT當(dāng)前＞RTT平均，則有RTT最大＝RTT當(dāng)前；RTT負(fù)載＝上調(diào)因子×RTT最大；RTT非負(fù)載＝下調(diào)因子×RTT最大；其中，0.5＜上調(diào)因子＜1，0＜下調(diào)因子＜0.5；若RTT當(dāng)前＜＝RTT平均，則直接執(zhí)行步驟3.2.3；步驟3.2.3、若丟包率Ploss＞0，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為擁塞，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.4；步驟3.2.4、若RTT平均＜＝RTT非負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為輕載，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.5；步驟3.2.5、若RTT平均＞RTT非負(fù)載，并且RTT平均＜＝RTT負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為負(fù)載，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.6；步驟3.2.6、若RTT平均＞RTT負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為輕塞，繼續(xù)執(zhí)行步驟4。
步驟3中，利用平滑因子計算RTT平均，通過RTT當(dāng)前與平滑因子的乘積來實時更新RTT平均，由于RTCP-SR和RTCP-RR報文每隔5s發(fā)送一次，故服務(wù)器端每隔5s即可利用客戶端的反饋信息更新RTT平均，并判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)，快速追蹤網(wǎng)絡(luò)變化。
所述的步驟4包含以下步驟步驟4.1、根據(jù)由步驟3分析得到的網(wǎng)絡(luò)狀態(tài)信息，服務(wù)器端參數(shù)調(diào)整模塊調(diào)整報文發(fā)送速率，以適應(yīng)當(dāng)前網(wǎng)絡(luò)狀況步驟4.1.1、若RTT平均＞＝上次調(diào)整速率時的時間間隔，則繼續(xù)執(zhí)行步驟4.1.2，否則執(zhí)行步驟4.2；步驟4.1.2、若網(wǎng)絡(luò)狀態(tài)為負(fù)載，保持當(dāng)前發(fā)送速率不變，穩(wěn)定速率以平滑因子進行調(diào)整，即穩(wěn)定速率＝穩(wěn)定速率×(1-平滑因子)+當(dāng)前速率×平滑因子，其中，0.75＜平滑因子＜1，所述的穩(wěn)定速率是中間變量，其是輔助調(diào)節(jié)當(dāng)前發(fā)送速率的中間量；繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.3；步驟4.1.3、若網(wǎng)絡(luò)狀態(tài)為擁塞，當(dāng)前發(fā)送速率按調(diào)節(jié)因子線性遞減，即當(dāng)前發(fā)送速率＝max(當(dāng)前發(fā)送速率×調(diào)節(jié)因子，最小速率)，其中，0.5＜調(diào)節(jié)因子＜0.75，所述的最小速率是指發(fā)送速率的最小值，此值是隨時間網(wǎng)絡(luò)變化而變化；穩(wěn)定速率按比例遞減，即穩(wěn)定速率＝穩(wěn)定速率×調(diào)節(jié)因子，其中，0.5＜調(diào)節(jié)因子＜0.75；繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.4；在網(wǎng)絡(luò)處于擁塞狀態(tài)下，穩(wěn)定速率的遞減是為了在輕載狀態(tài)時，謹(jǐn)慎增加當(dāng)前發(fā)送速率，防止下一時段的報文包丟失；步驟4.1.4、若網(wǎng)絡(luò)狀態(tài)為輕塞，可預(yù)測到報文包將會繼續(xù)丟失，故緩慢降低當(dāng)前速率，即當(dāng)前速率＝max(當(dāng)前速率×調(diào)節(jié)因子，最小速率)，其中，0.5＜調(diào)節(jié)因子＜0.75；繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.5；步驟4.1.5、若網(wǎng)絡(luò)狀態(tài)為輕載，且當(dāng)前發(fā)送速率＜穩(wěn)定速率，則處于慢啟動階段，此時，當(dāng)前發(fā)送速率可以較大幅度增大，即當(dāng)前發(fā)送速率＝(RR包間的時間間隔/平均RTT)×調(diào)整因子+當(dāng)前發(fā)送速率，其中，RR包間的時間間隔/平均RTT即為RTT的個數(shù)，調(diào)整因子的取值范圍是(0，1)，繼續(xù)執(zhí)行步驟4.2；若網(wǎng)絡(luò)狀態(tài)為輕載，且當(dāng)前發(fā)送速率＞＝穩(wěn)定速率，則處于擁塞可避免階段，當(dāng)前發(fā)送速率的增大幅度放緩，即當(dāng)前發(fā)送速率＝(RR包間的時間間隔/平均RTT)×調(diào)整因子×調(diào)整因子+當(dāng)前發(fā)送速率，其中，RR包間的時間間隔/平均RTT即為RTT的個數(shù)，調(diào)整因子的取值范圍是(0，1)，繼續(xù)執(zhí)行步驟4.2；步驟4.2、服務(wù)器端利用RTCP-APP探測包計算網(wǎng)絡(luò)瓶頸帶寬Bneck，根據(jù)Bneck來調(diào)整RTP包的大小步驟4.2.1、計算BneckBneck＝APP包的大小/兩個APP包的發(fā)送時間間隔；步驟4.2.2、更新APP的平均包大小平均包大小＝(1-0.75)×平均包大小+0.75×當(dāng)前包大小，其中，因RTP包傳輸約占總帶寬的75％，故設(shè)置調(diào)節(jié)因子為0.75；
步驟4.2.3、若瓶頸帶寬Bneck＞平均包大小，表明處于帶寬充足條件下，最大包大小等于瓶頸帶寬與調(diào)節(jié)因子的乘積，即最大包大?。狡款i帶寬×調(diào)節(jié)因子，其中，0.75＜調(diào)節(jié)因子＜1；當(dāng)前包大小取最大包大小和平均包大小的平均，適當(dāng)增加包的大小，即當(dāng)前包大?。?最大包大小+平均包大小)/2；然后結(jié)束；步驟4.2.4、若瓶頸帶寬Bneck＜＝平均包大小，表明處于帶寬緊張情況下，平均包大?。狡骄笮　琳{(diào)節(jié)因子，其中，0.5＜調(diào)節(jié)因子＜0.75；當(dāng)前包大小取最大包大小和平均包大小中的最小值，減小包大小，即當(dāng)前包大小＝min(平均包大小，瓶頸帶寬×調(diào)節(jié)因子)，其中，0.5＜調(diào)節(jié)因子＜0.75。
本發(fā)明中，在服務(wù)器端和客戶端各設(shè)置有定時器，當(dāng)網(wǎng)絡(luò)處于擁塞狀態(tài)而引起RTCP-APP報文丟失時，當(dāng)定時器計時超過5s，服務(wù)器端或客戶端仍未收到RTCP-APP報文時，客戶端或服務(wù)器端將自動重發(fā)。
本發(fā)明中，由于RTCP不存在握手功能，故在服務(wù)器端和客戶端各有RTCP報文的緩沖區(qū)，二者的RTCP數(shù)據(jù)包發(fā)送和接收不影響RTP數(shù)據(jù)的傳輸，同時APP包對網(wǎng)絡(luò)帶寬負(fù)載影響不大。
本發(fā)明提供的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，在不增加網(wǎng)絡(luò)負(fù)擔(dān)的情況下，可以降低服務(wù)器端到客戶端的延時和丟包率，且傳輸后的視頻主觀效果良好。


圖1是本發(fā)明提供的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法的示意圖。
具體實施例方式
以下根據(jù)圖1來具體說明本發(fā)明的一種較佳實施方式如圖1所示，是本發(fā)明提供的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法的示意圖，利用RTCP反饋信息實現(xiàn)控制，其包含以下步驟步驟1、服務(wù)器端構(gòu)造SR報文和APP報文，以恒定的發(fā)送速率向客戶端發(fā)送RTCP-SR控制信息和RTCP-APP探測包；所述的RTCP-APP探測包用來探測網(wǎng)絡(luò)帶寬變化情況，由于RTCP-APP探測包體積小且使用靈活，故不會給網(wǎng)絡(luò)帶來負(fù)擔(dān)；步驟2、客戶端接收并解析服務(wù)器端發(fā)送的RTCP-SR和RTCP-APP報文，構(gòu)造RTCP-RR和RTCP-APP反饋報文并以恒定的發(fā)送速率發(fā)送至服務(wù)器端；步驟3、服務(wù)器端在接收客戶端反饋的RTCP-RR和RTCP-APP報文后解析，獲取參數(shù)往返時間、網(wǎng)絡(luò)延時、丟包率，分析得出當(dāng)前網(wǎng)絡(luò)帶寬和運行狀況；步驟4、服務(wù)器端根據(jù)分析得到的網(wǎng)絡(luò)狀況，進行參數(shù)調(diào)整，通過調(diào)整視頻基本流的RTP包大小和發(fā)送速率來實現(xiàn)服務(wù)器端的發(fā)送控制。
步驟1中，服務(wù)器端以每間隔1s的恒定發(fā)送速率向客戶端發(fā)送1次RTCP-APP探測包，以每間隔5s的恒定發(fā)送速率向客戶端發(fā)送1次RTCP-SR控制信息。
步驟2中，客戶端以每間隔1s的恒定發(fā)送速率向服務(wù)器端發(fā)送1次RTCP-APP探測包反饋報文，以每間隔5s的恒定發(fā)送速率向服務(wù)器端發(fā)送1次RTCP-SR反饋報文。
所述的步驟3包含以下步驟步驟3.1、根據(jù)RTCP-RR報文中的反饋信息，計算參數(shù)步驟3.1.1、計算往返時間RTTRTT＝T-LSR，其中，T表示服務(wù)器端收到RTCP-RR反饋報文的時刻，LSR表示上一個RTCP-SR的時間戳；步驟3.1.2、計算網(wǎng)絡(luò)傳輸延時TdelayTdelay＝(T-LSR-DLSR)/2，其中，T表示服務(wù)器端收到RTCP-RR反饋報文的時刻，LSR表示上一個RTCP-SR的時間戳；DLSR表示自上一個RTCP-SR后的延遲；步驟3.1.3、計算丟包率PlossPloss＝Pn/256，其中，Pn為RTCP-RR報文中的分組丟失率字段；步驟3.2、根據(jù)往返時間RTT和丟包率Ploss來判斷當(dāng)前的網(wǎng)絡(luò)狀態(tài)；所述的網(wǎng)絡(luò)狀態(tài)具體分為輕載、負(fù)載、輕塞和擁塞四種；步驟3.2.1、更新平均往返時間RTT平均RTT平均＝(1-0.75)×RTT平均+0.75×RTT當(dāng)前，其中，0.75為平滑因子；當(dāng)服務(wù)器端得到第一個RTT時，即初始狀態(tài)時，定義RTT平均＝RTT當(dāng)前；RTT負(fù)載＝0.25×RTT當(dāng)前；RTT非負(fù)載＝0.75×RTT當(dāng)前；步驟3.2.2、若RTT當(dāng)前＞RTT平均，則有
RTT最大＝RTT當(dāng)前；RTT負(fù)載＝上調(diào)因子×RTT最大；RTT非負(fù)載＝下調(diào)因子×RTT最大；其中，0.5＜上調(diào)因子＜1，0＜下調(diào)因子＜0.5；若RTT當(dāng)前＜＝RTT平均，則直接執(zhí)行步驟3.2.3；步驟3.2.3、若丟包率Ploss＞0，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為擁塞，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.4；步驟3.2.4、若RTT平均＜＝RTT非負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為輕載，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.5；步驟3.2.5、若RTT平均＞RTT非負(fù)載，并且RTT平均＜＝RTT負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為負(fù)載，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.6；步驟3.2.6、若RTT平均＞RTT負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為輕塞，繼續(xù)執(zhí)行步驟4。
步驟3中，利用平滑因子計算RTT平均，通過RTT當(dāng)前與平滑因子的乘積來實時更新RTT平均，由于RTCP-SR和RTCP-RR報文每隔5s發(fā)送一次，故服務(wù)器端每隔5s即可利用客戶端的反饋信息更新RTT平均，并判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)，快速追蹤網(wǎng)絡(luò)變化。
所述的步驟4包含以下步驟步驟4.1、根據(jù)由步驟3分析得到的網(wǎng)絡(luò)狀態(tài)信息，服務(wù)器端參數(shù)調(diào)整模塊調(diào)整報文發(fā)送速率，以適應(yīng)當(dāng)前網(wǎng)絡(luò)狀況步驟4.1.1、若RTT平均＞＝上次調(diào)整速率時的時間間隔，則繼續(xù)執(zhí)行步驟4.1.2，否則執(zhí)行步驟4.2；步驟4.1.2、若網(wǎng)絡(luò)狀態(tài)為負(fù)載，保持當(dāng)前發(fā)送速率不變，穩(wěn)定速率以平滑因子0.25進行調(diào)整，即穩(wěn)定速率＝穩(wěn)定速率×(1-0.25)+當(dāng)前速率×0.25，繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.3；所述的穩(wěn)定速率是中間變量，其是輔助調(diào)節(jié)當(dāng)前發(fā)送速率的中間量；步驟4.1.3、若網(wǎng)絡(luò)狀態(tài)為擁塞，當(dāng)前發(fā)送速率按調(diào)節(jié)因子0.875線性遞減，即當(dāng)前發(fā)送速率＝max(當(dāng)前發(fā)送速率×0.875，最小速率)；其中，所述的最小速率是指發(fā)送速率的最小值，此值是隨時間網(wǎng)絡(luò)變化而變化；穩(wěn)定速率按0.75的比例遞減，即穩(wěn)定速率＝穩(wěn)定速率×0.75，繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.4；在網(wǎng)絡(luò)處于擁塞狀態(tài)下，穩(wěn)定速率的遞減是為了在輕載狀態(tài)時，謹(jǐn)慎增加當(dāng)前發(fā)送速率，防止下一時段的報文包丟失；步驟4.1.4、若網(wǎng)絡(luò)狀態(tài)為輕塞，可預(yù)測到報文包將會繼續(xù)丟失，故緩慢降低當(dāng)前速率，即當(dāng)前速率＝max(當(dāng)前速率×0.95，最小速率)，繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.5；步驟4.1.5、若網(wǎng)絡(luò)狀態(tài)為輕載，且當(dāng)前發(fā)送速率＜穩(wěn)定速率，則處于慢啟動階段，此時，當(dāng)前發(fā)送速率可以較大幅度增大，即當(dāng)前發(fā)送速率＝(RR包間的時間間隔/平均RTT)×調(diào)整因子+當(dāng)前發(fā)送速率，其中，RR包間的時間間隔/平均RTT即為RTT的個數(shù)，調(diào)整因子的取值范圍是(0，1)，繼續(xù)執(zhí)行步驟4.2；若網(wǎng)絡(luò)狀態(tài)為輕載，且當(dāng)前發(fā)送速率＞＝穩(wěn)定速率，則處于擁塞可避免階段，當(dāng)前發(fā)送速率的增大幅度放緩，即當(dāng)前發(fā)送速率＝(RR包間的時間間隔/平均RTT)×調(diào)整因子×調(diào)整因子+當(dāng)前發(fā)送速率，其中，RR包間的時間間隔/平均RTT即為RTT的個數(shù)，調(diào)整因子的取值范圍是(0，1)，繼續(xù)執(zhí)行步驟4.2；步驟4.2、服務(wù)器端利用RTCP-APP探測包計算網(wǎng)絡(luò)瓶頸帶寬Bneck，根據(jù)Bneck來調(diào)整RTP包的大小步驟4.2.1、計算BneckBneck＝APP包的大小/兩個APP包的發(fā)送時間間隔；步驟4.2.2、更新APP的平均包大小平均包大?。?1-0.75)×平均包大小+0.75×當(dāng)前包大小，其中，因RTP包傳輸約占總帶寬的75％，故設(shè)置調(diào)節(jié)因子為0.75；步驟4.2.3、若瓶頸帶寬Bneck＞平均包大小，表明處于帶寬充足條件下，最大包大小等于瓶頸帶寬與調(diào)節(jié)因子0.75的乘積，即最大包大?。狡款i帶寬×0.75；當(dāng)前包大小取最大包大小和平均包大小的平均，適當(dāng)增加包的大小，即當(dāng)前包大?。?最大包大小+平均包大小)/2；然后結(jié)束；步驟4.2.4、若瓶頸帶寬Bneck＜＝平均包大小，表明處于帶寬緊張情況下，平均包大?。狡骄笮　?.75；當(dāng)前包大小取最大包大小和平均包大小中的最小值，減小包大小，即當(dāng)前包大?。絤in(平均包大小，瓶頸帶寬×0.75)。
本發(fā)明中，在服務(wù)器端和客戶端各設(shè)置有定時器，當(dāng)網(wǎng)絡(luò)處于擁塞狀態(tài)而引起RTCP-APP報文丟失時，當(dāng)定時器計時超過5s，服務(wù)器端或客戶端仍未收到RTCP-APP報文時，客戶端或服務(wù)器端將自動重發(fā)。
本發(fā)明中，由于RTCP不存在握手功能，故在服務(wù)器端和客戶端各有RTCP報文的緩沖區(qū)，二者的RTCP數(shù)據(jù)包發(fā)送和接收不影響RTP數(shù)據(jù)的傳輸，同時APP包對網(wǎng)絡(luò)帶寬負(fù)載影響不大。
以下為將本發(fā)明應(yīng)用到基于RTP/RTCP的H.264視頻實時傳輸系統(tǒng)得到的結(jié)果，采用CIF格式視頻測試序列。表1和表2分別表示對網(wǎng)絡(luò)的丟包率和發(fā)送前、接收后PSNR的統(tǒng)計情況。

表1丟包率統(tǒng)計結(jié)果

表2 PSNR的統(tǒng)計結(jié)果由表1可見，丟包率均低于0.02％；從表2可看出發(fā)送前和接收解碼后PSNR下降比例不超過0.5dB。由此可以看出，本發(fā)明提供的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，在不增加網(wǎng)絡(luò)負(fù)擔(dān)的情況下，可以降低端到端延時和丟包率，且傳輸后的視頻主觀效果良好。
權(quán)利要求
1.一種基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，其特征在于，包含以下步驟步驟1、服務(wù)器端構(gòu)造SR報文和APP報文，以恒定的發(fā)送速率向客戶端發(fā)送RTCP-SR控制信息和RTCP-APP探測包；步驟2、客戶端接收并解析服務(wù)器端發(fā)送的RTCP-SR和RTCP-APP報文，構(gòu)造RTCP-RR和RTCP-APP反饋報文并以恒定的發(fā)送速率發(fā)送至服務(wù)器端；步驟3、服務(wù)器端在接收客戶端反饋的RTCP-RR和RTCP-APP報文后解析，獲取參數(shù)往返時間、網(wǎng)絡(luò)延時、丟包率，分析得出當(dāng)前網(wǎng)絡(luò)帶寬和運行狀況；步驟4、服務(wù)器端根據(jù)分析得到的網(wǎng)絡(luò)狀況，進行參數(shù)調(diào)整，通過調(diào)整視頻基本流的RTP包大小和發(fā)送速率來實現(xiàn)服務(wù)器端的發(fā)送控制。
2.如權(quán)利要求1所述的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，其特征在于，步驟1中，服務(wù)器端以每間隔1s的恒定發(fā)送速率向客戶端發(fā)送1次RTCP-APP探測包，以每間隔5s的恒定發(fā)送速率向客戶端發(fā)送1次RTCP-SR控制信息。
3.如權(quán)利要求1所述的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，其特征在于，步驟2中，客戶端以每間隔1s的恒定發(fā)送速率向服務(wù)器端發(fā)送1次RTCP-APP探測包反饋報文，以每間隔5s的恒定發(fā)送速率向服務(wù)器端發(fā)送1次RTCP-SR反饋報文。
4.如權(quán)利要求1所述的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，其特征在于，所述的步驟3包含以下步驟步驟3.1、根據(jù)RTCP-RR報文中的反饋信息，計算參數(shù)步驟3.1.1、計算往返時間RTTRTT＝T-LSR，其中，T表示服務(wù)器端收到RTCP-RR反饋報文的時刻，LSR表示上一個RTCP-SR的時間戳；步驟3.1.2、計算網(wǎng)絡(luò)傳輸延時TdelayTdelay＝(T-LSR-DLSR)/2，其中，T表示服務(wù)器端收到RTCP-RR反饋報文的時刻，LSR表示上一個RTCP-SR的時間戳；DLSR表示自上一個RTCP-SR后的延遲；步驟3.1.3、計算丟包率PlossPloss＝Pn/256，其中，Pn為RTCP-RR報文中的分組丟失率字段；步驟3.2、根據(jù)往返時間RTT和丟包率Ploss來判斷當(dāng)前的網(wǎng)絡(luò)狀態(tài)；所述的網(wǎng)絡(luò)狀態(tài)分為輕載、負(fù)載、輕塞和擁塞四種；步驟3.2.1、更新平均往返時間RTT平均RTT平均＝(1-平滑因子)×RTT平均+平滑因子×RTT當(dāng)前，其中，0.5＜平滑因子＜0.75；當(dāng)服務(wù)器端得到第一個RTT時，即在初始狀態(tài)時，定義RTT平均＝RTT當(dāng)前；RTT負(fù)載＝0.25×RTT當(dāng)前；RTT非負(fù)載＝0.75×RTT當(dāng)前；步驟3.2.2、若RTT當(dāng)前＞RTT平均，則有RTT最大＝RTT當(dāng)前；RTT負(fù)載＝上調(diào)因子×RTT最大；RTT非負(fù)數(shù)＝下調(diào)因子×RTT最大；其中，0.5＜上調(diào)因子＜1，0＜下調(diào)因子＜0.5；若RTT當(dāng)前＜＝RTT平均，則直接執(zhí)行步驟3.2.3；步驟3.2.3、若丟包率Ploss＞0，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為擁塞，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.4；步驟3.2.4、若RTT平均＜＝RTT非負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為輕載，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.5；步驟3.2.5、若RTT平均＞RTT非負(fù)載，并且RTT平均＜＝RTT負(fù)載，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為負(fù)載，繼續(xù)執(zhí)行步驟4；否則執(zhí)行步驟3.2.6；步驟3.2.6、若RTT平均＞RTT負(fù)數(shù)，則判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)為輕塞，繼續(xù)執(zhí)行步驟4。
5.如權(quán)利要求1所述的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，其特征在于，所述的步驟4包含以下步驟步驟4.1、根據(jù)由步驟3分析得到的網(wǎng)絡(luò)狀態(tài)信息，服務(wù)器端參數(shù)調(diào)整模塊調(diào)整報文發(fā)送速率步驟4.1.1、若RTT平均＞＝上次調(diào)整速率時的時間間隔，則繼續(xù)執(zhí)行步驟4.1.2，否則執(zhí)行步驟4.2；步驟4.1.2、若網(wǎng)絡(luò)狀態(tài)為負(fù)載，保持當(dāng)前發(fā)送速率不變，穩(wěn)定速率以平滑因子進行調(diào)整，即穩(wěn)定速率＝穩(wěn)定速率×(1-平滑因子)+當(dāng)前速率×平滑因子，其中，0.75＜平滑因子＜1，所述的穩(wěn)定速率是輔助調(diào)節(jié)當(dāng)前發(fā)送速率的中間變量；繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.3；步驟4.1.3、若網(wǎng)絡(luò)狀態(tài)為擁塞，當(dāng)前發(fā)送速率按調(diào)節(jié)因子線性遞減，即當(dāng)前發(fā)送速率＝max(當(dāng)前發(fā)送速率×調(diào)節(jié)因子，最小速率)；其中，0.5＜調(diào)節(jié)因子＜0.75，所述的最小速率是指發(fā)送速率的最小值，此值隨時間網(wǎng)絡(luò)變化而變化；穩(wěn)定速率按比例遞減，即穩(wěn)定速率＝穩(wěn)定速率×調(diào)節(jié)因子，其中，0.5＜調(diào)節(jié)因子＜0.75；繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.4；步驟4.1.4、若網(wǎng)絡(luò)狀態(tài)為輕塞，緩慢降低當(dāng)前速率，即當(dāng)前速率＝max(當(dāng)前速率×調(diào)節(jié)因子，最小速率)，其中，0.5＜調(diào)節(jié)因子＜0.75；繼續(xù)執(zhí)行步驟4.2；否則執(zhí)行步驟4.1.5；步驟4.1.5、若網(wǎng)絡(luò)狀態(tài)為輕載，且當(dāng)前發(fā)送速率＜穩(wěn)定速率，處于慢啟動階段，當(dāng)前發(fā)送速率＝(RR包間的時間間隔/平均RTT)×調(diào)整因子+當(dāng)前發(fā)送速率，其中，RR包間的時間間隔/平均RTT即為RTT的個數(shù)，調(diào)整因子的取值范圍是(0，1)，繼續(xù)執(zhí)行步驟4.2；若網(wǎng)絡(luò)狀態(tài)為輕載，且當(dāng)前發(fā)送速率＞＝穩(wěn)定速率，處于擁塞可避免階段，當(dāng)前發(fā)送速率＝(RR包間的時間間隔/平均RTT)×調(diào)整因子×調(diào)整因子+當(dāng)前發(fā)送速率，其中，RR包間的時間間隔/平均RTT即為RTT的個數(shù)，調(diào)整因子的取值范圍是(0，1)，繼續(xù)執(zhí)行步驟4.2；步驟4.2、服務(wù)器端利用RTCP-APP探測包計算網(wǎng)絡(luò)瓶頸帶寬Bneck，根據(jù)Bneck來調(diào)整RTP包的大小步驟4.2.1、計算BneckBneck＝APP包的大小/兩個APP包的發(fā)送時間間隔；步驟4.2.2、更新APP的平均包大小平均包大小＝(1-0.75)×平均包大小+0.75×當(dāng)前包大??；步驟4.2.3、若瓶頸帶寬Bneck＞平均包大小，處于帶寬充足條件下，最大包大?。狡款i帶寬×調(diào)節(jié)因子，其中，0.75＜調(diào)節(jié)因子＜1；當(dāng)前包大?。?最大包大小+平均包大小)/2；然后結(jié)束；步驟4.2.4、若瓶頸帶寬Bneck＜＝平均包大小，處于帶寬緊張情況下，平均包大?。狡骄笮　琳{(diào)節(jié)因子，其中，0.5＜調(diào)節(jié)因子＜0.75；當(dāng)前包大?。絤in(平均包大小，瓶頸帶寬×調(diào)節(jié)因子)，其中，0.5＜調(diào)節(jié)因子＜0.75。
6.如權(quán)利要求1所述的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，其特征在于，在服務(wù)器端和客戶端各設(shè)置有定時器。
全文摘要
本發(fā)明涉及一種基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，在不增加網(wǎng)絡(luò)負(fù)載的前提下，利用客戶端提供的準(zhǔn)確有效的反饋信息，對當(dāng)前網(wǎng)絡(luò)狀況進行分析判斷，根據(jù)分析結(jié)果自適應(yīng)調(diào)整視頻基本流的RTP包大小和發(fā)送速率，實現(xiàn)服務(wù)器端的發(fā)送控制。本發(fā)明提供的基于實時傳輸/控制協(xié)議的H.264流媒體傳輸控制方法，在不增加網(wǎng)絡(luò)負(fù)擔(dān)的情況下，可以降低服務(wù)器端到客戶端的延時和丟包率，且傳輸后的視頻主觀效果良好。
文檔編號H04L1/00GK1980238SQ200610117729
公開日2007年6月13日 申請日期2006年10月30日 優(yōu)先權(quán)日2006年10月30日
發(fā)明者騰國偉, 石旭利, 王紅娟, 王國中 申請人:上海廣電(集團)有限公司中央研究院