阮 科，鄒 潔，朱永慶

（中國電信股份有限公司廣東研究院 廣州510630）

1 視頻服務(wù)的QoE分析

在三網(wǎng)融合背景下，傳統(tǒng)廣電運(yùn)營商、電信運(yùn)營商以及互聯(lián)網(wǎng)運(yùn)營商均以視頻服務(wù)為重要的業(yè)務(wù)切入點(diǎn)，為用戶提供高質(zhì)量的視頻體驗(yàn)是視頻業(yè)務(wù)成功的關(guān)鍵因素之一。因此，不同網(wǎng)絡(luò)環(huán)境下視頻業(yè)務(wù)體驗(yàn)的提升成為業(yè)界重要的研究領(lǐng)域。QoE由寬帶論壇提出，是以用戶體驗(yàn)為衡量標(biāo)準(zhǔn)且與網(wǎng)絡(luò)無關(guān)的業(yè)務(wù)質(zhì)量指標(biāo)。針對視頻業(yè)務(wù)的特點(diǎn)，寬帶論壇提出的相應(yīng)指標(biāo)見表1。

從表1可以看出，視頻業(yè)務(wù)對網(wǎng)絡(luò)分組丟失的要求最為嚴(yán)苛，而相較于標(biāo)清節(jié)目，高清內(nèi)容對分組丟失的承受力更弱，分組丟失率上升時用戶體驗(yàn)快速下降。

運(yùn)營商IP網(wǎng)絡(luò)性能指標(biāo)見表2。大多數(shù)物理網(wǎng)絡(luò)都很難在端到端性能上符合這些指標(biāo)要求，為提升用戶體驗(yàn)，保證競爭力，必然需要引入一定的分組丟失和出錯修復(fù)機(jī)制。

表2 運(yùn)營商IP網(wǎng)絡(luò)性能指標(biāo)

2 視頻封裝特點(diǎn)

根據(jù)MPEG標(biāo)準(zhǔn)組織的建議，視頻內(nèi)容的數(shù)字化傳送可分為 ES（elementary stream）流、MPEG-TS流、RTP 流和IP流等幾個層面，如圖1所示，每一層流媒體都對應(yīng)特定的封裝，實(shí)現(xiàn)特定的功能。

表1 視頻業(yè)務(wù)QoE指標(biāo)

圖1 數(shù)字視頻封裝格式

ES流是音視頻內(nèi)容壓縮后的原始數(shù)據(jù)，根據(jù)MPEG標(biāo)準(zhǔn)的定義，存在 I幀 （intra-coded frame，I-frame）、B 幀（bidirectional frame，B-frame） 和P 幀 （predicted frame，P-frame）3種幀格式。I幀是基準(zhǔn)幀，包含完整圖像的信息，其信息量最大，占的信息也最多；P幀是前向預(yù)知幀，需要根據(jù)I幀進(jìn)行圖像重建，和I幀同時作為重建B幀圖像的基準(zhǔn)幀之一；B幀是雙向幀，需要參考I幀與P幀進(jìn)行圖像重建。一個完整的視頻GoP（group of pictures）格式如圖2所示。當(dāng)I幀丟失時，整個GoP內(nèi)容均無法重現(xiàn)，而B幀和P幀丟失時只會影響個別畫面或者畫面中的個別子塊。

圖2 視頻GoP格式

為了適應(yīng)視頻內(nèi)容的流化，需要將ES流分割成多個數(shù)據(jù)分組，方便其在網(wǎng)絡(luò)上的傳送。MPEG-TS是MPEG標(biāo)準(zhǔn)組織定義的格式，可通過PSI（program specification information）（包括PAT、PMT），幫助解碼設(shè)備識別TS流中的視頻、音頻和數(shù)據(jù)內(nèi)容。TS流中，單個報文統(tǒng)一為188 byte。在數(shù)字電視中，一般以MPEG-TS報文為最小傳輸單元。

為支持視頻內(nèi)容在IP網(wǎng)絡(luò)上的傳送，IETF定義了以RTP為基礎(chǔ)的流媒體傳送標(biāo)準(zhǔn)體系。一個RTP分組封裝7個MPEG-TS報文，長度為1 500 byte；采用 UDP封裝，以支持其在IP網(wǎng)絡(luò)上的傳遞，也有部分視頻流媒體系統(tǒng)采用直接UDP封裝MPEG-TS報文的方式。

從封裝格式可以看出，相對于傳統(tǒng)廣電網(wǎng)絡(luò)，IP網(wǎng)絡(luò)的分組丟失影響將更嚴(yán)重，影響范圍更大。

一方面，由于一個IP報文中封裝了更多的內(nèi)容，IP報文丟失后出現(xiàn)I幀丟失的幾率更高，將影響整個GoP。同時，IP報文分組丟失時丟失的信息過多，而壓縮編碼機(jī)制內(nèi)部的冗余機(jī)制一般只能克服比特級的錯誤分組，終端無法修復(fù)IP網(wǎng)絡(luò)中的分組丟失和出錯事件。

另一方面，廣電企業(yè)的同軸電纜網(wǎng)在分組丟失和出錯的處理上與IP網(wǎng)絡(luò)不同。當(dāng)網(wǎng)絡(luò)上出現(xiàn)比特級的錯誤分組時，同軸網(wǎng)絡(luò)不會采取分組丟失處理方式，機(jī)頂盒則可以利用視頻編碼本身的一些冗余機(jī)制進(jìn)行優(yōu)化，從而大幅減少影響用戶體驗(yàn)事件的發(fā)生幾率；而在IP網(wǎng)絡(luò)中，任何一個比特發(fā)生錯誤，底層傳送層就會執(zhí)行分組丟失動作，因此在IP網(wǎng)絡(luò)中分組丟失事件的發(fā)生幾率更高。

由上可見，為了在IP網(wǎng)絡(luò)上呈現(xiàn)不低于數(shù)字電視的用戶體驗(yàn)，IP視頻流媒體系統(tǒng)更有必要部署分組丟失修復(fù)機(jī)制。

3 視頻冗余技術(shù)

視頻重傳技術(shù)大致可分為3個主要類型。

3.1 FEC技術(shù)

FEC技術(shù)是指通過前向編碼上的冗余來克服分組丟失和出錯對視頻解碼的影響，其應(yīng)用范圍極其廣泛。在視頻傳送領(lǐng)域，存在多種不同的應(yīng)用機(jī)制，主要有應(yīng)用層FEC（AL-FEC）、網(wǎng)絡(luò)層FEC兩種。AL-FEC透明地工作在IP層之上的應(yīng)用層，其發(fā)送端在視頻流媒體服務(wù)器處對所有或有選擇的一組視頻流進(jìn)行冗余處理，處理后的AL-FEC流在終端設(shè)備的接收端進(jìn)行后處理，分離出原始碼流。FEC工作原理如圖3所示。

基于IP網(wǎng)絡(luò)的AL-FEC大致可分為兩種：Raptor編碼和Pro-MPEG CoP3編碼。

Raptor碼擁有很低的接收開銷和系統(tǒng)碼等特性。將Raptor碼應(yīng)用于視頻業(yè)務(wù)成為一種很具吸引力的選擇，數(shù)字視頻廣播(DVB)的IPTV應(yīng)用和3GPP的多媒體廣播多播業(yè)務(wù)(MBMS)都選擇了Raptor碼作為其AL-FEC規(guī)范。AL-FEC(Raptor)提供了應(yīng)用層端到端的可靠性，能對抗高分組丟失率，同時擁有靈活的糾錯能力(針對不同的文件及不同的分組丟失率設(shè)置不同的保護(hù)參數(shù))和高效性，只需很少的修復(fù)數(shù)據(jù)即可保證重構(gòu)源文件；但必須與物理層及鏈路層的FEC結(jié)合使用，且網(wǎng)絡(luò)帶寬代價一般為5%～10%。

Pro-MPEG CoP3編碼其實(shí)是一種簡單的奇偶檢驗(yàn)碼，它可以分為CoP3 1D(對行或列進(jìn)行編碼)和CoP3 2D(對行與列都編碼)。當(dāng)僅使用CoP3 1D時，生成的編碼只能保護(hù)一行或一列中出現(xiàn)一個數(shù)據(jù)分組丟失的情況，如果原始數(shù)據(jù)分組序列中出現(xiàn)連續(xù)兩個數(shù)據(jù)分組丟失(比如數(shù)據(jù)分組0和數(shù)據(jù)分組1或者數(shù)據(jù)分組0和數(shù)據(jù)分組L)，則丟失的兩個數(shù)據(jù)分組將無法恢復(fù)。但當(dāng)使用CoP3 2D時，這種情況將不會出現(xiàn)。

從實(shí)際的測試結(jié)果看，F(xiàn)EC技術(shù)大規(guī)模部署的難點(diǎn)在于如何克服分組丟失能力的有效性不足、效率偏低問題，在CoP3編碼中，5%的分組丟失修復(fù)率需要額外占用30%的冗余帶寬；同時，F(xiàn)EC技術(shù)只能修復(fù)具有特定特征的分組丟失事件。因此，將FEC技術(shù)應(yīng)用在突發(fā)事件經(jīng)常發(fā)生、網(wǎng)絡(luò)存在異構(gòu)環(huán)境的IP網(wǎng)絡(luò)中存在一定的限制。

3.2 空域冗余技術(shù)

空域冗余技術(shù)是指同時建立兩條或多條傳送電路，利用兩條鏈路互為冗余，可有效克服網(wǎng)絡(luò)中單一節(jié)點(diǎn)/鏈路出現(xiàn)分組丟失和出錯的場景。

MoFRR技術(shù)是目前業(yè)界正在研究的典型空域冗余技術(shù)。其實(shí)現(xiàn)原理是通過支持MoFRR技術(shù)的邊緣路由器，接收到用戶發(fā)起的IGMP join消息時，同時在兩個獨(dú)立接口上向視頻源端發(fā)出PIM join消息，同時建立兩條獨(dú)立的多播轉(zhuǎn)發(fā)路徑。邊緣路由器將兩個RPF接口配置為主備模式，在正常環(huán)境下丟棄備用接口接收的多播報文。當(dāng)路由器檢測到網(wǎng)絡(luò)發(fā)生故障時，自動地切換主備接口，保留備用接口的業(yè)務(wù)流量，通過緩存實(shí)現(xiàn)流統(tǒng)計(jì)模式下的無分組丟失收斂；當(dāng)故障恢復(fù)時，網(wǎng)絡(luò)可選擇性切換回主用路徑。

空域冗余應(yīng)用的主要問題在于冗余路徑的實(shí)現(xiàn)代價和多流之間的同步，在面向用戶部署時存在擴(kuò)展性問題，只適用于骨干網(wǎng)段單一多播流的場景。

圖3 FEC工作原理

3.3 分組丟失重傳技術(shù)

分組丟失重傳（RET）技術(shù)是IP網(wǎng)絡(luò)中應(yīng)用范圍最為廣泛的分組丟失和出錯修復(fù)技術(shù)，TCP協(xié)議是利用重傳技術(shù)在IP網(wǎng)絡(luò)中實(shí)現(xiàn)端到端分組丟失修復(fù)應(yīng)用最廣的協(xié)議；在應(yīng)用于流媒體傳輸領(lǐng)域時，考慮到流媒體協(xié)議的實(shí)時性需求，普通的TCP協(xié)議棧效率偏低，IETF推薦采用RTP/RTCP協(xié)議棧，在UDP基礎(chǔ)上實(shí)現(xiàn)分組丟失重傳。

在實(shí)際實(shí)現(xiàn)時，大約可以分為兩種方式：在流媒體服務(wù)器上實(shí)現(xiàn)，主要面向使用單播技術(shù)的點(diǎn)播用戶；在IP網(wǎng)絡(luò)中部署，主要面向使用多播技術(shù)的直播用戶。后者的實(shí)現(xiàn)機(jī)制如圖4所示。

圖4 視頻重傳實(shí)現(xiàn)原理

實(shí)現(xiàn)流程如下。

（1）IP路由器上的視頻業(yè)務(wù)板對多播方式傳送的視頻直播內(nèi)容進(jìn)行緩存，一般可以緩存視頻流8～10 s，1～2個GoP；

（2）機(jī)頂盒檢測傳送接收多播報文中的RTP封裝，通過RTP序列號連續(xù)性檢測出分組丟失的序列號；

（3）發(fā)現(xiàn)分組丟失后，機(jī)頂盒發(fā)送重傳請求（RTCP報文）給視頻業(yè)務(wù)板；

（4）視頻業(yè)務(wù)板把緩存的報文（RTCP報文）發(fā)送給機(jī)頂盒；

（5）機(jī)頂盒把重傳過來的報文插入正常的視頻流里面（STB有緩沖，可以等待一定時間內(nèi)重傳過來的報文）。

RET機(jī)制利用了RTP封裝信息的Sequence Number參數(shù)，圖5是一個RTP封裝的報文頭。

從實(shí)際的測試結(jié)果看，在標(biāo)清碼率環(huán)境下，分組丟失重傳技術(shù)能克服超過10%的分組丟失行為，且適用于正態(tài)分布、平均分布、突發(fā)等不同的分組丟失特征；在高清碼率環(huán)境下，分組丟失重傳技術(shù)能克服4%左右的分組丟失行為。部署分組丟失重傳技術(shù)，可以極大地降低網(wǎng)絡(luò)中出現(xiàn)的隨機(jī)分組丟失現(xiàn)象對用戶體驗(yàn)的影響；同時，其只在網(wǎng)絡(luò)出現(xiàn)分組丟失時才發(fā)生，重傳時占用網(wǎng)絡(luò)資源約20%，適用于目前電信運(yùn)營商的大多數(shù)接入環(huán)境。因此，分組丟失重傳技術(shù)是IP網(wǎng)絡(luò)環(huán)境下行之有效的分組丟失修復(fù)技術(shù)。

圖5 RTP封裝報文頭

4 分組丟失重傳技術(shù)的應(yīng)用場景

IPTV業(yè)務(wù)是電信運(yùn)營商實(shí)現(xiàn)全業(yè)務(wù)運(yùn)營的戰(zhàn)略性業(yè)務(wù)，也是超寬帶網(wǎng)絡(luò)架構(gòu)中的大帶寬接入用戶的主要填充業(yè)務(wù)。為優(yōu)化IPTV業(yè)務(wù)的視頻傳送質(zhì)量，提升IPTV用戶的業(yè)務(wù)體驗(yàn)，可在網(wǎng)絡(luò)上部署分組丟失重傳技術(shù)。

·IPTV點(diǎn)播業(yè)務(wù)。在IPTV系統(tǒng)中，利用RTP協(xié)議族中內(nèi)建的信令技術(shù)，通過IPTV機(jī)頂盒對視頻流進(jìn)行監(jiān)控，發(fā)現(xiàn)分組丟失時，通過RTCP信令實(shí)現(xiàn)分組丟失重傳。為了提升分組丟失重傳效率，也可以在網(wǎng)絡(luò)邊緣節(jié)點(diǎn)上部署分組丟失重傳技術(shù)，對熱門片源進(jìn)行緩存和重傳。

·IPTV直播業(yè)務(wù)。為提高IPTV直播業(yè)務(wù)的承載質(zhì)量，大多數(shù)電信運(yùn)營商采用多播方式承載直播業(yè)務(wù)流，而多播技術(shù)本身無法提供分組丟失重傳機(jī)制。在實(shí)際部署時，可在IP承載網(wǎng)上部署視頻Cache設(shè)備，目前已有部分電信設(shè)備廠商提供支持集成Cache板卡的IP路由器設(shè)備。在超寬帶網(wǎng)絡(luò)架構(gòu)下，可在IP城域網(wǎng)內(nèi)部署該設(shè)備作為IPTV業(yè)務(wù)的接入控制點(diǎn)，直接對IPTV用戶進(jìn)行分組丟失重傳和故障修復(fù)。

視頻重傳方案還支持視頻單板的多級布署，如果視頻單板之間發(fā)生分組丟失，下一級的視頻單板可以作為RET的客戶端向上一級視頻單板請求重傳丟棄的報文，也可以把IPTV系統(tǒng)作為RET的Server請求重傳。在此情況下，下一級視頻單板可以先用多播的方式向STB發(fā)送一個不發(fā)送重傳請求的報文，避免大量的重傳請求發(fā)送到視頻單板。在視頻單板收到重傳過來的報文之后，再采取多播的方式把重傳報文發(fā)送給STB。

重傳機(jī)制的實(shí)現(xiàn)依賴于一些外部因素，一是需要RTP封裝，二是要求STB支持重傳的流程。對于要求一，運(yùn)營商需要對IPTV系統(tǒng)的輸出進(jìn)行標(biāo)準(zhǔn)化，統(tǒng)一支持RTP封裝；對于要求二，運(yùn)營商可委托第三方的公司負(fù)責(zé)STB和IPTV以及FCC/RET的集成，解決雙方的集成配套問題。

5 未來視頻修復(fù)技術(shù)的主要發(fā)展方向

視頻修復(fù)技術(shù)的發(fā)展是未來視頻業(yè)務(wù)承載的重點(diǎn)之一，在超寬帶IP網(wǎng)絡(luò)架構(gòu)下，未來分組丟失修復(fù)技術(shù)應(yīng)主要關(guān)注以下幾個方向。

·編碼技術(shù)。傳統(tǒng)的視頻編碼技術(shù)主要關(guān)注視頻的壓縮效率，在網(wǎng)絡(luò)帶寬日益豐富的背景下，視頻編碼技術(shù)應(yīng)更加注意其在不同網(wǎng)絡(luò)條件下的一致性體驗(yàn)的問題。通過引入多層次編碼、FEC等技術(shù)，可以加強(qiáng)編碼本身在網(wǎng)絡(luò)劣化條件下的自修復(fù)能力。

·CDN層面。CDN是流媒體服務(wù)的主要提供者，目前電信運(yùn)營商和互聯(lián)網(wǎng)運(yùn)營商各有其優(yōu)化策略。電信運(yùn)營商一般仍然以RTP/RTCP為主要的技術(shù)框架，以保障流媒體的傳送質(zhì)量為重點(diǎn)；而互聯(lián)網(wǎng)運(yùn)營商多以HTTP為基礎(chǔ)技術(shù)，通過終端的緩存和平臺的文件切割來保障視頻流吞吐，未來這兩種方式應(yīng)逐步走向融合。

·IP承載網(wǎng)層面。隨著芯片技術(shù)和虛擬化技術(shù)的發(fā)展，IP網(wǎng)絡(luò)對業(yè)務(wù)和應(yīng)用的感知和優(yōu)化能力日益增加。電信運(yùn)營商可發(fā)揮自身的網(wǎng)絡(luò)優(yōu)勢，通過網(wǎng)絡(luò)Cache、CDN以及DPI等技術(shù)，將IP網(wǎng)絡(luò)打造成真正適合視頻承載的基礎(chǔ)設(shè)施。

6 結(jié)束語

基于寬帶IP網(wǎng)絡(luò)實(shí)現(xiàn)高質(zhì)量視頻傳送是未來發(fā)展的方向，在超寬帶環(huán)境下，傳統(tǒng)的視頻修復(fù)技術(shù)或者效果不佳，或者效率較低，不能完全適應(yīng)新的網(wǎng)絡(luò)環(huán)境和業(yè)務(wù)環(huán)境。電信運(yùn)營商應(yīng)充分利用超寬帶網(wǎng)絡(luò)中的各種優(yōu)化技術(shù)，積極部署新型、更加適應(yīng)IP網(wǎng)絡(luò)環(huán)境的基于分組丟失重傳機(jī)制的視頻修復(fù)機(jī)制，提前占領(lǐng)高清內(nèi)容傳送的制高點(diǎn)，為最終構(gòu)建可持續(xù)的超寬帶盈利網(wǎng)絡(luò)提供有效的工具。

1 Broadband Forum TR126.Triple-play Services Quality of Experience(QoE)Requirements,2006

2 ISO/IEC.13818-1(Systems)13818-2(Video Coding),2007

3 RFC3550. RTP: A Transport Protocol for Real-Time Applications,2003

4 ETSI TS 102 472 V1.1.1.Digital Video Broadcasting(DVB),IP Datacast over DVB-H:Content Delivery Protocols,2005

5 SMPTE Specification 2022-1.Forward ErrorCorrection for Real-Time Video/Audio Transport over IP Networks,2007