基于應(yīng)用層的IPTV業(yè)務(wù)質(zhì)量優(yōu)化方案

奚 溪，姚 良

（中國電信股份有限公司上海研究院 上海 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ì)量進行研究，針對網(wǎng)絡(luò)的丟包、時延、抖動這些影響IPTV業(yè)務(wù)質(zhì)量的主要因素，提出了通過IPTV應(yīng)用層的優(yōu)化方案，以適應(yīng)“盡力而為”的IP網(wǎng)絡(luò)，進一步提高IPTV的業(yè)務(wù)質(zhì)量。

前向糾錯；丟包重傳；流量控制

1 引言

隨著現(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ù)具有信息量大、實時性強等特點。由于傳統(tǒng)的IP網(wǎng)絡(luò)更多考慮的是不保證實時傳輸?shù)臄?shù)據(jù)通信，而如今要在IP網(wǎng)絡(luò)上進行實時多媒體業(yè)務(wù)的傳輸，將面臨許多問題。特別是IPTV采用RTP over UDP的方式傳輸，不能保證傳輸?shù)目煽啃裕虼藢τ贗PTV業(yè)務(wù)質(zhì)量的研究和優(yōu)化是十分必要的。

2 影響IPTV業(yè)務(wù)質(zhì)量的關(guān)鍵因素

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ù)和避免緩存上下溢的機制。其中，針對組播丟包恢復(fù)的機制是FEC，針對單播丟包恢復(fù)的機制是ARQ，針對單播避免緩存上下溢的機制是流量控制。

3 流媒體丟包恢復(fù)技術(shù)方案

3.1 丟包恢復(fù)技術(shù)原理

為了減少視頻數(shù)據(jù)丟失和錯誤對解碼質(zhì)量造成不利的影響，需要使用一些錯誤控制技術(shù)來提高視頻數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)目煽啃浴Ｄ壳爸饕餍械募m錯方案是前向糾錯技術(shù)和重傳技術(shù)。

3.1.1 前向糾錯技術(shù)

前向糾錯技術(shù)（forward error correction，F(xiàn)EC）是一種通過在信息源增加冗余信息實現(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)容進行前向糾錯編碼，生成冗余信息；

（2）原始媒體數(shù)據(jù)與FEC冗余數(shù)據(jù)發(fā)送到客戶端，可能存在丟包；

（3）終端根據(jù)收到的數(shù)據(jù)進行FEC解碼，恢復(fù)出丟失報文的完整內(nèi)容。

FEC無需反饋的機制特點使其適用于IPTV組播應(yīng)用。

3.1.2 丟包重傳

自動重傳請求（automatic repeat-request，ARQ）是一種通過丟包反饋重傳實現(xiàn)丟包恢復(fù)的措施。ARQ的數(shù)據(jù)處理流程如下：

（1）媒體數(shù)據(jù)經(jīng)過編號（如 RTP序號）后發(fā)送到客戶端，可能存在丟包；

（2）終端根據(jù)序號向服務(wù)器反饋丟失分組信息；

（3）服務(wù)器重傳丟失分組。

ARQ的技術(shù)需要反饋，因而更適用于IPTV的單播業(yè)務(wù)。

3.2 FEC技術(shù)實現(xiàn)

FEC的實現(xiàn)需要增加兩個模塊：在流媒體服務(wù)器側(cè)增加FEC的編碼模塊；在終端側(cè)增加FEC的解碼模塊。

目前流行的FEC算法有很多種，表1列出了一些應(yīng)用比較多的FEC算法，并且對這些算法進行了分析。

其中，ProMPEG是基于奇偶校驗算法，算法簡單，但是冗余開銷大，效果一般。Raptor編碼是預(yù)測編碼算法，抗突發(fā)丟包的能力差。Tornado算法是一種稀疏圖碼，編碼性能很高，但應(yīng)用不廣泛。RS算法基于BCH編碼方式，算法簡單，解碼與丟包位置無關(guān)，編解碼性能高、并且抗隨機和突發(fā)丟包能力強，應(yīng)用也比較廣泛，因而本文建議采用Reed-Solomon算法，丟包恢復(fù)能力與丟包的位置無關(guān)。FEC編碼組的RTP報文數(shù)和冗余報文數(shù)可設(shè)定，但是建議不超過100個RTP報文，冗余報文數(shù)不超過RTP報文數(shù)的5%。

FEC算法模塊在流媒體服務(wù)器、終端中的位置如圖1所示。

表1 FEC算法分析比較

3.3 ARQ技術(shù)實現(xiàn)

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ù)包進行排序。如被重傳的RTP數(shù)據(jù)包在被媒體播發(fā)模塊解碼時仍未收到，則放棄該RTP數(shù)據(jù)包，不影響媒體播放的實時性。

判斷RTP包丟失的依據(jù)是：當(dāng)收到RTP包序號不連續(xù)時，即判斷有一次RTP包丟失。一次RTP包丟失有可能丟失的是一個RTP包，也有可能是丟失連續(xù)的多個RTP包。不管是丟失一個RTP包，還是丟失連續(xù)多個的RTP包，終端向平臺請求重發(fā)的RTSP包只需發(fā)一次，RTSP包中包含有一個或多個丟失的RTP包序號信息。針對一次RTP包丟失，RTSP重傳請求只需發(fā)送一次，無論重傳RTP包是否達到，都不應(yīng)再向平臺發(fā)起RTSP重傳請求，這樣可以有效地避免反饋風(fēng)暴的發(fā)生。

4 流媒體傳輸流量控制技術(shù)方案

4.1 流量抖動原因

導(dǎo)致流媒體流量抖動的原因有很多種，視頻服務(wù)器性能變化、網(wǎng)絡(luò)線路出現(xiàn)擁堵、網(wǎng)絡(luò)設(shè)備的性能變化都可以導(dǎo)致視頻流的抖動變化。抖動會導(dǎo)致網(wǎng)絡(luò)設(shè)備和終端的緩存上溢和下溢，進而引起圖像的停頓或馬賽克。

目前采用的去除抖動的方式有3種：在流媒體服務(wù)器平臺側(cè)對輸出視頻流進行預(yù)處理，采用平谷、削峰和shaping的方法降低視頻流的輸出抖動；在網(wǎng)絡(luò)設(shè)備和終端側(cè)增加緩存空間；采用流量控制技術(shù)。本文中采用的是流量控制技術(shù)。

4.2 流量控制技術(shù)原理

流量控制的技術(shù)原理是：終端根據(jù)緩存的實際狀況，向流媒體服務(wù)器平臺請求碼率增加或減小。

流量控制機制是一種通過終端控制服務(wù)器的發(fā)送碼流速率來達到緩存區(qū)調(diào)整的方法。采用流量控制的流程如下：

（1）終端實時監(jiān)測緩存狀態(tài)，如超過了緩存上溢或下溢的預(yù)警線，則向服務(wù)器發(fā)出緩存調(diào)整指令。

（2）服務(wù)器根據(jù)終端的請求，在規(guī)定的碼流速率范圍內(nèi)，根據(jù)終端需要調(diào)整的緩存大小，確定碼流速率調(diào)整的大小和調(diào)整的時間。

4.3 流控技術(shù)實現(xiàn)

在平臺側(cè)和終端引入流量控制機制，具體的交互流程如圖2所示。

（1）終端與平臺交互驗證是否支持流量控制；

（2）終端進行RTSP信令交互；

（3）終端在發(fā)現(xiàn)緩存區(qū)溢出的情況下，通過發(fā)送進行流量控制的請求，與流媒體服務(wù)器進行流量控制；

（4）服務(wù)器響應(yīng)流量控制請求，調(diào)整發(fā)流的速率。

5 結(jié)束語

本文根據(jù)現(xiàn)網(wǎng)的IPTV質(zhì)量分析，提出了影響IPTV業(yè)務(wù)質(zhì)量的主要因素是丟包和抖動，并進一步提出了基于應(yīng)用層的IPTV質(zhì)量優(yōu)化方案，對于組播丟包引入FEC的方式，對于單播丟包引入ARQ機制，對于網(wǎng)絡(luò)抖動引起的緩存上溢和下溢可以采用流量控制的方式。這些優(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）