IPTV智能終端傳輸系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)

單玉峰

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 糾錯(cuò)技術(shù)

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

1.3.1 自動(dòng)重傳ARQ

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

圖3 自動(dòng)重傳

1.3.2 前向糾錯(cuò)編碼 (FEC)

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

圖4 前向糾錯(cuò)編碼

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

1.4 快速頻道切換

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

影響頻道切換的幾個(gè)主要因素:

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

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

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

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

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

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

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

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

2 IPTV智能客戶(hù)端設(shè)計(jì)和實(shí)現(xiàn)

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

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

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

1)支持組播(multicast);

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

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

4)支持基于IETF標(biāo)準(zhǔn)的ARQ的網(wǎng)絡(luò)糾錯(cuò)功能;

5)支持基于IETF標(biāo)準(zhǔn)的快速頻道切換;

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

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

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

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

3 如何集成到用戶(hù)客戶(hù)端

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

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

3.1 初始化VQE－C

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

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

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

2)vqec_ifclient_start():啟動(dòng)VQE－C的事件處理器(Event Loop)，這個(gè)API調(diào)用并不返回，一般需要建立1個(gè)線(xiàn)程來(lái)單獨(dú)運(yùn)行這個(gè)事件處理器。

3)vqec_ifclient_tuner_create():創(chuàng)造調(diào)頻器(Tuner，VQE－C使用了傳統(tǒng)電視調(diào)頻器的名字用來(lái)標(biāo)識(shí)VQE－C中頻道的數(shù)據(jù)接收端)?？梢院?jiǎn)單的理解為1個(gè)視頻接收終端，Tuner創(chuàng)建的數(shù)量定義在系統(tǒng)配置文件中。

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

3.2 VQE－C 接收媒體流

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

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

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

vqec_vod_session_create():該API通過(guò)調(diào)用VQE－C RTSP客戶(hù)端來(lái)建立1個(gè)服務(wù)器端的會(huì)話(huà)(Session)。并且獲得頻道的信息。利用這個(gè)獲得的頻道信息，客戶(hù)端調(diào)用綁定API，然后調(diào)用VQE－C API發(fā)送RTSP播放請(qǐng)求給VOD服務(wù)器。

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

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

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

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

3.4 技術(shù)文檔

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

3.5 項(xiàng)目實(shí)現(xiàn)

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

圖6 比利時(shí)電訊采用VQE的拓?fù)浣Y(jié)構(gòu)

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

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

4 結(jié)束語(yǔ)

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

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

[2]夏勇，何晶.融合網(wǎng)絡(luò)寬帶IP互動(dòng)電視技術(shù)方案設(shè)計(jì)[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.