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