單玉峰

(思科系統(tǒng)公司，圣何塞加利福利亞州 美國 95134)

近幾年來，隨著網(wǎng)絡技術(shù)的發(fā)展和寬帶網(wǎng)絡基礎(chǔ)設施的普及，網(wǎng)絡多媒體技術(shù)得到了越來越多的關(guān)注。世界上許多網(wǎng)絡服務商開始部署網(wǎng)絡電視(IPTV)[1]和交互式視頻應用(Interactive TV)[2]，以家用電視機(計算機或者智能手機)作為主要終端，通過IP協(xié)議向用戶提供電視節(jié)目以及多種交互式數(shù)字媒體服務及其增值業(yè)務。不同于傳統(tǒng)電視單向廣播的特點，IPTV的最大優(yōu)勢在于其“互動性”和“按需觀看”。為了獲得新的用戶和搶占電視市場份額，僅僅這兩大優(yōu)勢是不夠的，新的網(wǎng)絡多媒體服務應該提供比當前的電視服務更好的服務質(zhì)量。針對于視頻傳輸質(zhì)量來講，目前公認的IPTV行業(yè)基準是播放1個2小時的電影，最多允許1個傳輸差錯。這個非常嚴格的“應用層”的要求映射到網(wǎng)絡層是視頻傳送的丟包率不應大于1.0e－6。雖然網(wǎng)絡服務商在設計網(wǎng)絡的時候采用高可靠性部件和各種各樣的冗余，但是完全消除網(wǎng)絡層的傳輸故障是不可能的。優(yōu)化傳輸中的可靠性是非常有必要的，可以大大降低視頻應用的差錯率和提高服務質(zhì)量，以利于和傳統(tǒng)電視競爭[3]。本文主要討論IPTV系統(tǒng)中智能客戶端的關(guān)鍵技術(shù)以及實現(xiàn)。

1 IPTV傳輸中的主要技術(shù)要求

1.1 IPTV 系統(tǒng)結(jié)構(gòu)

典型的IPTV系統(tǒng)通常包括超級頭端(Super Headend，SHE)、區(qū)域頭端(Reginal Headend，RHE)、視頻交換中心(Video Switching Office，VSO)和最終用戶等，如圖1所示。這些系統(tǒng)分別分布在核心網(wǎng)(Core Network)、承運網(wǎng)(Distribution And Aggregation Network)、接入網(wǎng)(Access Network)以及家庭網(wǎng)絡中。SHE通常負責接收原始媒體，通過視頻編碼后依靠核心網(wǎng)絡傳送給RHE。RHE通過承運網(wǎng)鏈接VSO，提供視頻服務給最終用戶。

1.2 運載網(wǎng)路傳輸?shù)目煽啃?/h3>

提供視頻應用的網(wǎng)絡服務商在優(yōu)化他們網(wǎng)絡的時候一方面要保證用戶的服務質(zhì)量，另一方面又要保證自身的最佳經(jīng)濟利益。他們經(jīng)常超額規(guī)劃他們的網(wǎng)絡，并且假設所有的用戶不會同時使用網(wǎng)絡，因此對某種服務分配的網(wǎng)絡帶寬通常要小于所有用戶的帶寬之和。雖然從經(jīng)濟角度來講比較合算，但同時也引進了可能的網(wǎng)絡擁塞。當網(wǎng)絡擁塞發(fā)生時，非實時應用例如TCP文件下載，發(fā)送端可以采用降低發(fā)送速率的辦法來避免擁塞。但是實時多媒體應用通常在傳送中需要固定的網(wǎng)絡帶寬，采用這種改變速率的方法會引起用戶視頻觀看質(zhì)量的下降。因此，解決實時應用的優(yōu)化方法不是降低傳送的速率，而是盡量避免這種情況發(fā)生。

圖1 IPTV的系統(tǒng)結(jié)構(gòu)

目前IPTV運營商主要提供基于組播的實時節(jié)目和基于VOD的點播節(jié)目[4]。針對于組播的網(wǎng)絡傳輸設計比較簡單，因為運營商掌握所有組播節(jié)目的帶寬，而且組播使用的核心網(wǎng)絡帶寬并不隨著用戶數(shù)量的增加而增大，在運載網(wǎng)路設計中可以預留足夠的帶寬以保證服務質(zhì)量。對于直播VOD節(jié)目，使用的網(wǎng)絡帶寬會隨觀看用戶的增加而增大，當網(wǎng)絡流量達到最大設計流量的時候，服務器應該拒絕新的媒體播放請求，從而避免擁塞的發(fā)生。這種辦法的好處是只影響1個用戶而不會影響其他所有正在接收視頻的其他用戶，新的用戶請求會被推遲到有帶寬的時候。

在媒體系統(tǒng)中，應使用視頻接入許可控制(Video Call Admission Control)技術(shù)來解決網(wǎng)絡擁塞問題。通常需要2步來完成視頻接入許可控制。第1步是利用RSVP(Resource Reservation Protocol)的核心網(wǎng)(Core and Distribution Network)接入許可控制，如圖2，以確保核心網(wǎng)有足夠的帶寬來傳送新的媒體流。具體步驟為:用戶通過機頂盒遙控器選擇想要看的電影，用戶請求(VOD Request)通過運營商的邊界集中路由器(Edge Aggregation Router)傳送到視頻服務器(VOD Server)。VOD服務器發(fā)送RSVP信息給用戶機頂盒，同時實時跟蹤在核心網(wǎng)和傳送層的變化。沿著這個路徑，路由器執(zhí)行帶寬賬戶功能(Bandwidth Accounting Function)。如果有足夠的帶寬支持視頻傳送，路由器將會批準帶寬請求，否則會拒絕。當請求被拒絕時，RSVP－CAC信息將會被送回視頻服務器，然后視頻服務器送給用戶拒絕信息或者忙音。

圖2 核心網(wǎng)接入許可控制

第2步接入網(wǎng)絡的許可控制，用來確定接入網(wǎng)絡是否有足夠的帶寬運載請求的視頻數(shù)據(jù)。在收到用戶VOD請求后，視頻服務器發(fā)送1個帶寬查詢信息給策略服務器(Policy Server)。策略服務器管理著所有的接入用戶，根據(jù)它掌握的用戶信息，視頻服務器的請求可能被批準或者拒絕。第1步和第2步可以同時進行。

當核心網(wǎng)和接入網(wǎng)的接入請求得到許可后，視頻服務器就可以發(fā)送用戶請求的電影，同時又可以保證不影響其他用戶的觀看質(zhì)量。

1.3 糾錯技術(shù)

大多數(shù)系統(tǒng)運營商的用戶接入網(wǎng)絡丟包率在1e－4級別。而視頻系統(tǒng)對丟包率的要求是小于1e－6。因此為了保證理想的視頻傳送質(zhì)量，一定的網(wǎng)路糾錯技術(shù)是必不可少的。目前比較成熟的網(wǎng)絡糾錯技術(shù)有2種:自動重傳(Automatic Retransmission Request，ARQ)和前向糾錯編碼(Forward Error Correction，F(xiàn)EC)，這2種方法都有各自的優(yōu)點和缺點。在有些IPTV系統(tǒng)中采用ARQ，有些系統(tǒng)運營商采用FEC，還有的系統(tǒng)結(jié)合使用這2種方法[5]。

1.3.1 自動重傳ARQ

如圖3所示，自動重傳技術(shù)是由接收端驅(qū)動的，在網(wǎng)絡傳輸過程中，當接收端檢測到有丟失的數(shù)據(jù)包，接收端就會發(fā)送1個請求給服務器請求其重發(fā)丟失的數(shù)據(jù)包。服務器在接收到用戶的請求后，重發(fā)丟失的數(shù)據(jù)包。這種方法的優(yōu)點是只傳送丟失的數(shù)據(jù)包，占用網(wǎng)絡帶寬較少，它的缺點也很明顯，需要發(fā)送請求重傳信息給服務器，有傳送延遲 (數(shù)據(jù)包的網(wǎng)路往返傳送時間，Round Trip Time)。在多播環(huán)境中，特別是用戶比較多的時候反饋信息會擁塞發(fā)送服務器，因此在多播時，通常需要配備專門服務器用來處理重傳請求信息和發(fā)送丟失的數(shù)據(jù)包。在點對點的通信，例如視頻點播，這種方法比較有效。

圖3 自動重傳

1.3.2 前向糾錯編碼 (FEC)

不同于自動重傳，前向糾錯技術(shù)是由發(fā)送端驅(qū)動的，發(fā)送者在發(fā)送視頻數(shù)據(jù)包的同時，也發(fā)送一些經(jīng)過編碼的數(shù)據(jù)包(如圖4中的“R”，編碼包的數(shù)量需要根據(jù)網(wǎng)路丟包率來決定)。在網(wǎng)絡傳送過程中，如果有數(shù)據(jù)包丟失，接收端就會嘗試利用接收的編碼包來恢復丟失的視頻包。這種方法的優(yōu)點是不需要發(fā)送反饋信息給發(fā)送者，僅僅是從服務器到客戶端的單向通信。缺點是服務器不知道送多少編碼數(shù)據(jù)包是合適的，如果送的多，有利于恢復丟失的數(shù)據(jù)包，但同時增加了網(wǎng)絡帶寬的占有率。如果網(wǎng)絡丟包率很低，這些帶寬都浪費了。如果送的少，可能并不能用來恢復所有的丟失的視頻數(shù)據(jù)包。

圖4 前向糾錯編碼

一種比較好的辦法是結(jié)合這兩種技術(shù)的優(yōu)點，例如服務器在發(fā)送媒體數(shù)據(jù)包的同時，發(fā)送少量的糾錯編碼包，如果在傳送過程中出現(xiàn)丟包，接收端首先利用糾錯編碼包重建丟失的數(shù)據(jù)包，如果不能重建所有的丟包，接收端可以利用自動重傳來修復剩余的丟包。

1.4 快速頻道切換

快速頻道切換主要是針對組播頻道來講的，頻道切換時間定義為從用戶按下遙控器按鍵到第1個視頻圖像在電視上顯示的時間間隔。在現(xiàn)在的非IP電視中，頻道切換的延遲非常小。在IP電視網(wǎng)絡中，每1個電視頻道就是1個組播數(shù)據(jù)流，IP機頂盒利用IGMP組播協(xié)議在組播數(shù)據(jù)流之間轉(zhuǎn)換。當用戶發(fā)出頻道切換的請求時，IP機頂盒首先送出IGMP“離開”信息(IGMP Leave)給正在播放的頻道，然后發(fā)出IGMP“加入”信息 (IGMP Join)給新的頻道。一定時間的延遲后，新頻道的組播數(shù)據(jù)流就會傳送到機頂盒。當機頂盒接收到需要的視頻解碼信息后，機頂盒解碼接收的視頻數(shù)據(jù)包，然后把新頻道的視頻顯示在電視機上，完成1次頻道切換。

影響頻道切換的幾個主要因素:

1)IGMP協(xié)議信號延遲:IGMP協(xié)議的“離開”和“加入”信息需要傳送到相應的邊界路由器以斷開舊的和接收新的組播數(shù)據(jù)流。

2)MPEG解碼延遲:為了能夠解碼MPEG數(shù)據(jù)流，解碼器需要得到節(jié)目信息表(Program Specific Information，PSI)，特別是節(jié)目分配表(Program Allocation Table，PAT)。根據(jù)MPEG標準中，2個PAT表在數(shù)據(jù)流中的距離可能會高達500 ms。也就是說解碼器在最壞的情況下可能會接收長達500 ms的數(shù)據(jù)才能得到想要的PSI信息。

3)視頻I幀獲得時間:在MPEG視頻編碼的時候，通常會把1組原始數(shù)據(jù)幀(Group of Picture，GoP，一般12～15幀)作為1個編碼對象。MPEG可以把數(shù)據(jù)幀壓縮成3種格式:I幀(Intra－Frame Coding，可以單獨解碼);P幀(Predicated Frame Coding，需要依賴I幀或者前面的P幀解碼);和B幀(Bi－directional Coding需要依賴前后的I或P幀解碼)。為了節(jié)約傳送帶寬，在MPEG視頻壓縮標準中，通常1個GoP只有1個I幀，其他的都是P或者B幀。但是接收端需要解碼I幀后，才能解碼其他的P或者B幀。I幀的延遲是根據(jù)GoP的大小來決定的，在典型的廣播系統(tǒng)中，通常每隔500 ms發(fā)送1個I幀(在H.264編碼中也可能采用多于1 s的GoP)。因次在頻道切換時，I幀的延遲是比較大的一個影響因素。

4)加密系統(tǒng)密碼獲取延遲

在1個典型的加密系統(tǒng)(Conditional Access System，CAS)中，權(quán)利控制信息(Entitlement Control Messages，ECM)和權(quán)利管理信息(Entitlement Management Messages，EMM)被用來加密要傳送的媒體。這些信息每隔一段時間被嵌入到傳送的MPEG媒體中，機頂盒必須接收到ECM和EMM才能解密MPEG數(shù)據(jù)流。解密密碼的獲取也增加了頻道切換的延遲。

以上的主要延遲綜合起來，IPTV用戶的頻道切換時間可能會達到幾秒鐘。相比于現(xiàn)在非IP電視的少于1 s的頻道切換時間，幾秒鐘的切換時間是不能容忍的。為了降低以上談到的延遲，相應的快速頻道切換技術(shù)必須包含在IPTV系統(tǒng)中。

1.5 用戶視頻質(zhì)量的監(jiān)控和報告

當系統(tǒng)運營商推出新的視頻服務的時候，他們希望了解到每個用戶的服務質(zhì)量如何，用戶的滿意程度直接關(guān)系新服務的成敗。為了了解用戶的視頻觀看質(zhì)量和維持高質(zhì)量的服務，系統(tǒng)運營商通常會要求客戶端能實時提供相應的反饋信息[6]。這些信息會有助于系統(tǒng)運營商優(yōu)化自己的網(wǎng)絡和提供相應的新服務。通常運營商有專門的服務器接收這些報告然后進行分析。因此客戶端開發(fā)者應該把能夠收集和反饋用戶服務質(zhì)量信息作為一個重要的功能來實現(xiàn)。

2 IPTV智能客戶端設計和實現(xiàn)

適用網(wǎng)絡發(fā)展的要求，結(jié)合思科強大的網(wǎng)路技術(shù)力量，推出了一整套的網(wǎng)絡視頻解決方案。針對IPTV系統(tǒng)來講主要有CDS－TV，VQE等等，這些IPTV系統(tǒng)支持直播VOD、組播頻道、快速頻道切換、網(wǎng)路傳輸糾錯以及復雜的媒體存儲和系統(tǒng)管理等等。

在這套系統(tǒng)中，設計和實現(xiàn)了一個基于國際標準的智能傳輸客戶端開源軟件VQE－C，任何開發(fā)商都可以直接利用思科的VQE－C源代碼開發(fā)智能客戶端。這些客戶端可以無縫地和思科上述的IPTV服務器端交互，大大節(jié)省開發(fā)商的系統(tǒng)開發(fā)時間。由于采用國際標準，因此可以兼容任何采用相同標準的系統(tǒng)及服務器。并且思科在推出新的服務器端的應用時，會同時推出升級的客戶端VQE－C的新版本，客戶端開發(fā)商只要重新編譯一下新的VQE－C就會支持新的應用，而不需要再進行新的費時開發(fā)以支持服務器的新功能。VQE－C客戶端的配置也非常靈活，它提供1個系統(tǒng)配置文件，通過改變配置文件可以滿足各種各樣的應用。

VQE－C客戶端是基于Linux平臺使用C語言開發(fā)的，任何運行在Linux上的應用均可以很方便地使用它。VQE－C軟件包的源代碼可以從思科的網(wǎng)站上免費下載，它提供的功能如下:

1)支持組播(multicast);

2)支持基于RTSP協(xié)議的直播VOD;

3)支持基于MPEG CoP#3的前向編碼糾錯FEC;

4)支持基于IETF標準的ARQ的網(wǎng)絡糾錯功能;

5)支持基于IETF標準的快速頻道切換;

6)支持基于RTCP協(xié)議的用戶視頻質(zhì)量的監(jiān)控報告;

7)數(shù)據(jù)傳輸支持RTP和UDP;

8)支持網(wǎng)絡地址轉(zhuǎn)換(Network Address Translation，NAT)。

這些功能都集成在一個開源的軟件包中，并且提供系統(tǒng)配置文件來設置不同的應用需求。開發(fā)者可以把VQE－C想象成網(wǎng)絡接口(Network Socket)編程的一個替代層(如圖5所示)。這個替代層可以完成上述描述的功能，并提供簡單易用的編程接口。在組播環(huán)境中，如果IPTV系統(tǒng)需要支持快速頻道切換和網(wǎng)絡糾錯，需要在接入網(wǎng)中部署單獨的VQE－S服務器。在直播VOD環(huán)境中，VQE－S服務器是思科視頻播放服務器CDS－TV中的一個服務器進程。

3 如何集成到用戶客戶端

圖5 VQE－C在系統(tǒng)集成中的位置

VQE－C模塊可以運行在Linux內(nèi)核模式(Kernel Mode)或者用戶模式(User Mode)，并提供了一系列的應用編程接口來幫助開發(fā)者使用VQE－C的功能。不管運行在內(nèi)核模式還是用戶模式，應用編程接口的調(diào)用都是一樣的。VQE－C模塊在客戶應用系統(tǒng)中的位置可以參考圖5。開發(fā)用戶需要把VQE－C集成到IPTV客戶端才能使用VQE－C的功能。

3.1 初始化VQE－C

不管是對直播或者是組播用戶，集成VQE－C的第1步是在客戶端系統(tǒng)啟動的時候初始化和運行VQE－C，并且創(chuàng)建相應的“調(diào)頻器”(Tuner)。每1個調(diào)頻器就是1個VQE－C數(shù)據(jù)的接收端。創(chuàng)建的調(diào)頻器數(shù)目可以根據(jù)用戶的需求來決定，可以簡單理解為創(chuàng)建的調(diào)頻器的數(shù)目應該是用戶同時接收的媒體流的數(shù)目。例如，如果用戶需要一邊看電視一邊記錄另一個頻道，那么就需要創(chuàng)建2個調(diào)頻器。

VQE－C初始化時API的調(diào)用步驟:

1)vqec_ifclient_init():初始化VQE－C，處理系統(tǒng)配置文件。

2)vqec_ifclient_start():啟動VQE－C的事件處理器(Event Loop)，這個API調(diào)用并不返回，一般需要建立1個線程來單獨運行這個事件處理器。

3)vqec_ifclient_tuner_create():創(chuàng)造調(diào)頻器(Tuner，VQE－C使用了傳統(tǒng)電視調(diào)頻器的名字用來標識VQE－C中頻道的數(shù)據(jù)接收端)。可以簡單的理解為1個視頻接收終端，Tuner創(chuàng)建的數(shù)量定義在系統(tǒng)配置文件中。

初始化完成后，VQE－C作為1個線程運行在客戶端中(例如機頂盒)，中間件可以調(diào)用VQE－C提供的API來完成需要的功能。

3.2 VQE－C 接收媒體流

在完成對VQE－C的初始化后，用戶就可以使用VQE－C提供的服務。如果用戶需要接收某個頻道的數(shù)據(jù)流，中間件需要調(diào)用以下API綁定到這個數(shù)據(jù)流。

vqec_ifclient_tuner_bind_chan():綁定API，綁定調(diào)頻器到1個正在播放的視頻流或者1個頻道。當VQE－C綁定1個組播頻道后就自動開始接收數(shù)據(jù)。

對于組播數(shù)據(jù)流，上述API的調(diào)用會發(fā)出組播“加入”命令到需要觀看的頻道，對于直播VOD客戶來講，在調(diào)用綁定API之前需要調(diào)用另外1個針對直播的API以獲得頻道信息。

vqec_vod_session_create():該API通過調(diào)用VQE－C RTSP客戶端來建立1個服務器端的會話(Session)。并且獲得頻道的信息。利用這個獲得的頻道信息，客戶端調(diào)用綁定API，然后調(diào)用VQE－C API發(fā)送RTSP播放請求給VOD服務器。

3.3 中間件接收視頻數(shù)據(jù)給解碼器

完成上述的頻道綁定(和播放)后，VQE－C已經(jīng)開始接收媒體數(shù)據(jù)流，并且根據(jù)配置文件自動執(zhí)行糾錯功能和快速頻道切換功能，中間件需要調(diào)用下列API把VQE－C接收的數(shù)據(jù)傳送給解碼器。

vqec_ifclient_tuner_recvmsg():機頂盒調(diào)用這個API接收經(jīng)過VQE－C處理的數(shù)據(jù)包，數(shù)據(jù)包被傳給解碼器進行解碼。

在VQE－C的運行過程中，VQE－C監(jiān)控服務質(zhì)量，根據(jù)配置這些信息可以被發(fā)送到VQE－S作為運營商的服務質(zhì)量評估。

3.4 技術(shù)文檔

在VQE－C的軟件包中包含了3個參考文件。系統(tǒng)集成指南提供了詳細的API介紹和如何集成VQE－C到你的開發(fā)系統(tǒng)中。系統(tǒng)配置指南提供了如何配置系統(tǒng)文件會得需要的功能和參數(shù)配置。CLI命令指南提供了如何使用VQE－C的命令行來調(diào)試VQE－C的輸出。

3.5 項目實現(xiàn)

該客戶端被成功的應用在世界上許多的IPTV運營商中。圖6列出了VQE在比利時電訊IPTV系統(tǒng)中的拓撲結(jié)構(gòu)[7]。IPTV Set－Top Box運行 VQE 客戶端，Retransmission Server運行VQE服務器軟件。

圖6 比利時電訊采用VQE的拓撲結(jié)構(gòu)

圖7顯示了VQE用戶質(zhì)量監(jiān)控系統(tǒng)檢測到的從周五到周一4天的糾錯包數(shù)據(jù)流量，這個圖表相關(guān)的用戶數(shù)是1.83萬使用VQE的IPTV用戶。

圖7 VQE用戶質(zhì)量監(jiān)控系統(tǒng)檢測到的糾錯包的數(shù)據(jù)流量

4 結(jié)束語

在本文中，描述了1個智能IPTV客戶端所需要的技術(shù)以及它的實現(xiàn)，并且提供了1個開源的客戶端軟件。這個軟件可以大大提供開發(fā)商的IPTV客戶端的開發(fā)時間，同時開發(fā)的客戶端可以無縫的和思科的服務器進行交互，也可以和遵循同樣標準的第三方服務器交互，大大擴展了客戶端的使用范圍和支持的廠商。這個系統(tǒng)現(xiàn)在已經(jīng)得到了世界上許多運營商的支持，開發(fā)商可以利用該系統(tǒng)作任何需要的二次開發(fā)。

[1]嚴華.IPTV 技術(shù)與發(fā)展探討[J].計算機應用，2008(2):59－61.

[2]夏勇，何晶.融合網(wǎng)絡寬帶IP互動電視技術(shù)方案設計[J].電視技術(shù)，2010，34(10):9－13.

[3]EVANS J，BEGEN A C，GREENGRASS J，et al.Toward lossless video transport[J].IEEE Internet Comput.，2011，15(6):48－57.

[4]BEGEN A C，GLAZEBROOK N，STEEG W V.A unified approach for repairing packet loss and accelerating channel changes in multicast IPTV[C]//Proc.IEEE Consumer Communications and Networking Conf(CCNC):Special Session on IPTV towards Seamless Infotainment.Las Vegas，NV:IEEE Press，2009(1):1－6.

[5]LI Zhi，ZHU Xiaoqing，BEGEN A C，et al.Forward and retransmitted systematic lossy error protection for IPTV video multicast[C]//Proc.Packet Video Wksp.Seattle.WA:IEEE Press，2009(5):1－9.

[6]BEGEN A C，PERKINS C，OTT J.On the use of RTP for monitoring and fault isolation in IPTV[J].IEEE Network，Special Issue on Improving Quality of Experience for Network Services，2010，24(2):14－19.

[7]MIGNON M，BOUCKHOUT K，GAHM J，et al.Scaling server－based channel－change acceleration to millions of IPTV subscribers[C]//Proc.Packet Video Wksp.Munich，Germany:IEEE Press，2012.