奚 溪,姚 良
(中國電信股份有限公司上海研究院 上海 200122)
基于應用層的IPTV業(yè)務質(zhì)量優(yōu)化方案
奚 溪,姚 良
(中國電信股份有限公司上海研究院 上海 200122)
IPTV承載在IP網(wǎng)絡上,由于IP網(wǎng)絡“盡力而為”的特性,IPTV業(yè)務往往會受到網(wǎng)絡帶寬、傳輸時延、網(wǎng)絡丟包等各種因素的影響,導致IPTV業(yè)務質(zhì)量下降。本文對IPTV業(yè)務質(zhì)量進行研究,針對網(wǎng)絡的丟包、時延、抖動這些影響IPTV業(yè)務質(zhì)量的主要因素,提出了通過IPTV應用層的優(yōu)化方案,以適應“盡力而為”的IP網(wǎng)絡,進一步提高IPTV的業(yè)務質(zhì)量。
前向糾錯;丟包重傳;流量控制
隨著現(xiàn)代網(wǎng)絡和多媒體業(yè)務的發(fā)展,傳統(tǒng)的網(wǎng)頁瀏覽、視頻下載、郵件發(fā)送等業(yè)務已經(jīng)無法滿足人們的需求,具有交互特性的IPTV很好地將電視服務和互聯(lián)網(wǎng)瀏覽、電子郵件以及多種在線信息咨詢、娛樂、教育及商務功能結(jié)合在一起,從而得到越來越多的關注。然而,IPTV這種流媒體業(yè)務具有信息量大、實時性強等特點。由于傳統(tǒng)的IP網(wǎng)絡更多考慮的是不保證實時傳輸?shù)臄?shù)據(jù)通信,而如今要在IP網(wǎng)絡上進行實時多媒體業(yè)務的傳輸,將面臨許多問題。特別是IPTV采用RTP over UDP的方式傳輸,不能保證傳輸?shù)目煽啃?,因此對于IPTV業(yè)務質(zhì)量的研究和優(yōu)化是十分必要的。
IPTV業(yè)務質(zhì)量主要表現(xiàn)在:視頻播放是否清晰;是否有馬賽克、停頓、斷流等現(xiàn)象。影響IPTV業(yè)務質(zhì)量的因素有:IPTV頭端的編碼器、編碼速率、TS封包質(zhì)量、流輸出穩(wěn)定性以及網(wǎng)絡傳輸過程中的丟包、抖動和時延等。在影響IPTV業(yè)務質(zhì)量的諸多因素中,平臺流輸出的穩(wěn)定性和網(wǎng)絡傳輸損傷是最為關鍵的。
在流媒體傳輸過程中,丟包直接影響了視頻音頻的解碼,會引起停頓或馬賽克。過大的抖動則會引起網(wǎng)絡設備緩存上溢,或終端緩存的上溢和下溢。緩存上溢會引起丟包,緩存下溢會引起視音頻解碼的停頓。即使視頻服務器碼流輸出平穩(wěn),但如果視頻文件編碼速率的抖動過大,終端收到的碼流速率和消耗的碼流速率不匹配,也會引起終端緩存的上溢或下溢。
因此,針對丟包和抖動,應在IPTV平臺和終端間引入丟包恢復和避免緩存上下溢的機制。其中,針對組播丟包恢復的機制是FEC,針對單播丟包恢復的機制是ARQ,針對單播避免緩存上下溢的機制是流量控制。
為了減少視頻數(shù)據(jù)丟失和錯誤對解碼質(zhì)量造成不利的影響,需要使用一些錯誤控制技術來提高視頻數(shù)據(jù)在網(wǎng)絡上傳輸?shù)目煽啃?。目前主要流行的糾錯方案是前向糾錯技術和重傳技術。
3.1.1 前向糾錯技術
前向糾錯技術(forward error correction,F(xiàn)EC)是一種通過在信息源增加冗余信息實現(xiàn)丟包恢復的措施。在IP網(wǎng)絡里,數(shù)據(jù)報文的正確性已經(jīng)由網(wǎng)絡層保證,如果出現(xiàn)傳輸錯誤,設備、網(wǎng)卡會自動丟棄。所以,這里的FEC應用不是糾錯,而是丟包恢復。FEC的數(shù)據(jù)處理流程如下:
(1)媒體服務器對原始媒體內(nèi)容進行前向糾錯編碼,生成冗余信息;
(2)原始媒體數(shù)據(jù)與FEC冗余數(shù)據(jù)發(fā)送到客戶端,可能存在丟包;
(3)終端根據(jù)收到的數(shù)據(jù)進行FEC解碼,恢復出丟失報文的完整內(nèi)容。
FEC無需反饋的機制特點使其適用于IPTV組播應用。
3.1.2 丟包重傳
自動重傳請求(automatic repeat-request,ARQ)是一種通過丟包反饋重傳實現(xiàn)丟包恢復的措施。ARQ的數(shù)據(jù)處理流程如下:
(1)媒體數(shù)據(jù)經(jīng)過編號(如 RTP序號)后發(fā)送到客戶端,可能存在丟包;
(2)終端根據(jù)序號向服務器反饋丟失分組信息;
(3)服務器重傳丟失分組。
ARQ的技術需要反饋,因而更適用于IPTV的單播業(yè)務。
FEC的實現(xiàn)需要增加兩個模塊:在流媒體服務器側(cè)增加FEC的編碼模塊;在終端側(cè)增加FEC的解碼模塊。
目前流行的FEC算法有很多種,表1列出了一些應用比較多的FEC算法,并且對這些算法進行了分析。
其中,ProMPEG是基于奇偶校驗算法,算法簡單,但是冗余開銷大,效果一般。Raptor編碼是預測編碼算法,抗突發(fā)丟包的能力差。Tornado算法是一種稀疏圖碼,編碼性能很高,但應用不廣泛。RS算法基于BCH編碼方式,算法簡單,解碼與丟包位置無關,編解碼性能高、并且抗隨機和突發(fā)丟包能力強,應用也比較廣泛,因而本文建議采用Reed-Solomon算法,丟包恢復能力與丟包的位置無關。FEC編碼組的RTP報文數(shù)和冗余報文數(shù)可設定,但是建議不超過100個RTP報文,冗余報文數(shù)不超過RTP報文數(shù)的5%。
FEC算法模塊在流媒體服務器、終端中的位置如圖1所示。
表1 FEC算法分析比較
ARQ的重傳反饋有兩種方式:一種是通過RTCP方式反饋丟包的信息;一種是通過RTSP的方式反饋丟包信息。考慮到日后分片式流媒體服務器是一種趨勢,在單播請求中RTP的地址會有變化,RTCP的地址也同樣會跟著變,對于重傳請求服務器的刀片定位會有影響。因而建議采用不變的RTSP方式用于回饋丟包信息。
終端根據(jù)收到數(shù)據(jù)包的RTP序號判斷是否有RTP數(shù)據(jù)包丟失,當發(fā)現(xiàn)有RTP數(shù)據(jù)包丟失時,終端以RTSP協(xié)議向平臺發(fā)起重傳請求。重傳的RTP數(shù)據(jù)包與原RTP數(shù)據(jù)包結(jié)構相同,終端收到重傳的RTP數(shù)據(jù)包后,在終端側(cè)應有RTP亂序現(xiàn)象,終端應根據(jù)RTP序號重新對RTP數(shù)據(jù)包進行排序。如被重傳的RTP數(shù)據(jù)包在被媒體播發(fā)模塊解碼時仍未收到,則放棄該RTP數(shù)據(jù)包,不影響媒體播放的實時性。
判斷RTP包丟失的依據(jù)是:當收到RTP包序號不連續(xù)時,即判斷有一次RTP包丟失。一次RTP包丟失有可能丟失的是一個RTP包,也有可能是丟失連續(xù)的多個RTP包。不管是丟失一個RTP包,還是丟失連續(xù)多個的RTP包,終端向平臺請求重發(fā)的RTSP包只需發(fā)一次,RTSP包中包含有一個或多個丟失的RTP包序號信息。針對一次RTP包丟失,RTSP重傳請求只需發(fā)送一次,無論重傳RTP包是否達到,都不應再向平臺發(fā)起RTSP重傳請求,這樣可以有效地避免反饋風暴的發(fā)生。
導致流媒體流量抖動的原因有很多種,視頻服務器性能變化、網(wǎng)絡線路出現(xiàn)擁堵、網(wǎng)絡設備的性能變化都可以導致視頻流的抖動變化。抖動會導致網(wǎng)絡設備和終端的緩存上溢和下溢,進而引起圖像的停頓或馬賽克。
目前采用的去除抖動的方式有3種:在流媒體服務器平臺側(cè)對輸出視頻流進行預處理,采用平谷、削峰和shaping的方法降低視頻流的輸出抖動;在網(wǎng)絡設備和終端側(cè)增加緩存空間;采用流量控制技術。本文中采用的是流量控制技術。
流量控制的技術原理是:終端根據(jù)緩存的實際狀況,向流媒體服務器平臺請求碼率增加或減小。
流量控制機制是一種通過終端控制服務器的發(fā)送碼流速率來達到緩存區(qū)調(diào)整的方法。采用流量控制的流程如下:
(1)終端實時監(jiān)測緩存狀態(tài),如超過了緩存上溢或下溢的預警線,則向服務器發(fā)出緩存調(diào)整指令。
(2)服務器根據(jù)終端的請求,在規(guī)定的碼流速率范圍內(nèi),根據(jù)終端需要調(diào)整的緩存大小,確定碼流速率調(diào)整的大小和調(diào)整的時間。
在平臺側(cè)和終端引入流量控制機制,具體的交互流程如圖2所示。
(1)終端與平臺交互驗證是否支持流量控制;
(2)終端進行RTSP信令交互;
(3)終端在發(fā)現(xiàn)緩存區(qū)溢出的情況下,通過發(fā)送進行流量控制的請求,與流媒體服務器進行流量控制;
(4)服務器響應流量控制請求,調(diào)整發(fā)流的速率。
本文根據(jù)現(xiàn)網(wǎng)的IPTV質(zhì)量分析,提出了影響IPTV業(yè)務質(zhì)量的主要因素是丟包和抖動,并進一步提出了基于應用層的IPTV質(zhì)量優(yōu)化方案,對于組播丟包引入FEC的方式,對于單播丟包引入ARQ機制,對于網(wǎng)絡抖動引起的緩存上溢和下溢可以采用流量控制的方式。這些優(yōu)化機制的引入,可以保障IPTV視頻的傳輸質(zhì)量,有效提高觀看IPTV視頻組播和點播的質(zhì)量。
1 RFC3550.A Transport Protocol for Real-Time Applications
2 RFC5510.Reed-Solomon Forward Error Correction (FEC)Schemes
3 RFC2327.Session Description Protocol
4 RFC2326.Real Time Streaming Protocol(RTSP)
2010-07-15)