陳 美,汪清清
(中國電信股份有限公司江蘇分公司 南京210017)
隨著通信技術的不斷發展,互聯網業務已從滿足用戶的基本需求轉變為滿足用戶更豐富的消費性和娛樂性需求,視頻業務成為主要的互聯網應用之一,也是各大運營商競爭的焦點之一。目前,視頻業務種類繁多,如在線視頻、IPTV、視頻監控、會議電視等。
2010年,國務院正式決定加快推進電信網、有線電視網和互聯網的三網融合,作為三網融合的重要切入點,電信運營商必將大力發展IPTV、手機影視等視頻業務,最終實現以IP網絡為統一承載的語音、數據和視頻3重業務的捆綁[1]。
對視頻業務來說,用戶往往通過看視頻卡不卡、切換快不快判斷業務質量的優劣。IP承載網是一個“盡力而為”的網絡,而視頻業務是一個需要高帶寬、低傳輸延時和低延時抖動的業務,任何一個環節出現問題都可能導致用戶觀看視頻時出現馬賽克、卡頓、響應慢等現象,甚至無法觀看。因此,提升視頻業務質量、優化使用感知更具迫切性。
三網融合后,視頻媒體的交互化是產業發展的必然趨勢。IPTV產業形態日趨成熟,產業價值不斷提升,將成為三網融合進程中最為核心的主導型業務。本文以IPTV為例,闡述FEC及FCC技術在提升視頻業務使用感知方面的應用。
隨著IPTV產業鏈的逐漸成熟,業務需求已從“可用”、“能用”向“好用”階段轉變,能否提供好的用戶體驗質量(quality of experience,QoE)[1]成為IPTV業務能否可持續發展的必要條件。視頻播放的流暢性和頻道切換延時是衡量QoE的關鍵指標。因此,降低節目卡頓概率、提升頻道切換響應速度是目前急需解決的問題。
對于節目播放卡頓問題,運營商一般通過分段排查的方式定位故障原因,解決網絡設備、平臺服務器軟硬件故障或優化線路質量。故障從申告到解決需要一定時間,影響了用戶感知。目前采用的糾錯機制主要是傳統的差錯控制技術,包括依靠TCP本身所具備的丟包、超時重傳機制,或在UDP之上擴展出丟包、超時重傳機制等。在網絡擁塞嚴重的網絡中,可能導致視頻圖像質量更加惡化。
對于頻道切換延時問題,運營商一般通過優化業務認證流程、使用靜態組播樹代替動態組播樹[2]、提升設備性能[3]等方式降低響應延時。但由于IPTV業務流程、組播技術特點、費用投資等方面的原因,頻道切換延時仍較數字電視長。
如何以較小的投入成本、較短的時間提高IPTV業務對網絡質量的容忍度、提升頻道切換延時使其與數字電視相當,是運營商要解決的重點問題,也是實現IPTV業務質量突破的關鍵。
直播服務作為IPTV業務中的一項重要業務,一般采用基于UDP的組播方式進行傳送。而對于采用TS over RTP格式的IPTV媒體傳輸過程中的容錯糾錯,目前國際國內都沒有正式的規范,相關的建議和標準草案中主要提到兩種措施:丟包重傳和前向糾錯(FEC),兩者的簡單對比見表1。

表1 丟包重傳和前向糾錯技術對比
可見,FEC技術更適合于直播業務,其單向無交互的特點,使其適用于基于組播方式的直播服務場合。
IPTV領域中的FEC算法大多基于異或運算的原理。假設有2 bit的信息A和B,對A與B進行異或運算作為FEC數據,表2列出了FEC分別與A和B進行異或運算的結果。
從表2可以看出,FEC XOR A的值與B相等,而FEC XOR B的值則與A相等。如果在發送數據時,除了發送原始比特位A和B外,將A與B作異或的值作為一個額外的比特位加以發送,則這3個比特位中的任意一個比特位丟失,都可完全恢復原始信息。表2針對的是2 bit的情況,3個或更多的比特位進行異或運算,也可得到同樣的糾錯效果。

表2 異或運算結果
確定了FEC的核心算法后,還要確定一種模式從原始媒體包中選擇合適的媒體包參與FEC運算,如圖1所示(參與同一次FEC計算的媒體包和FEC包外框表示相同)。

在圖1中,A的做法是每連續5個包作一次FEC編碼,而B的做法則是奇數包和偶數包分別作FEC編碼。假設網絡因素導致媒體包1和2被丟掉了,則對于A來說,總共6個包(5個媒體包加一個FEC包)丟掉了1/3,可能恢復失敗,而對于B來說,6個包中只丟掉一個,恢復成功的可能性大很多。
編碼后的FEC數據必須采用合適的格式進行封裝,封裝后發送FEC數據的時機也很重要。假設FEC數據被封裝成單獨的數據包進行發送,圖2給出了兩種不同的發送模式。
從圖2可以看出,A的發送方式將FEC包均勻分布在輸出的碼流中,但在連續丟兩個包的情況下,如果剛好是圓圈中的兩個包丟失,則同一組6個包損失1/3,無法恢復。B的發送方式簡單地將兩個FEC包放在最后發送,能夠抵抗任意位置的兩個連續丟包。

除了上述FEC算法外,信息領域內還有一些其他的FEC算法,如常用的RS編碼,能夠識別出接收數據中的比特誤碼并加以糾正,但由于IP網絡上的數據錯誤在應用層通常表現為整個數據包的丟失,在視頻業務領域內鮮有應用。
圖3為江蘇電信在IPTV業務中應用FEC技術的解決方案之一,具體如下。
·在省中心和區域中心分別部署直播服務節點。
·中心直播節點和區域直播節點間采用單播方式傳輸直播碼流,同時部署FEC,FEC數據與原始碼流共用一個RTP通道。
·區域直播節點從中心直播節點接收直播碼流,進行FEC解碼和糾錯。
·區域直播節點再次對直播碼流進行FEC編碼,并將碼流以組播方式發送給區域中心、邊緣節點和機頂盒。
·區域中心發出的FEC數據采用單獨通道傳輸,以兼容各廠商機頂盒。
直播頻道切換流程如圖4所示。
·首先機頂盒需獲取頻道的組播地址,耗時一般約幾百毫秒。
·根據組播地址,加入該頻道對應的組播組,耗時0.1~1 s,與承載網數據設備有關,IPoE較快,PPPoE較慢。
·獲取碼流的PSI信息,與PAT和PMT的重復間隔有關,耗時約為50 ms。
·等待碼流的第一個I幀,通常I幀間隔為2 s,等待I幀的時間平均約為1 s。
·傳輸I幀耗時一般在300 ms以內,機頂盒接收到I幀后即開始播放。

由圖4可以看出,等待和傳輸I幀的時間占據頻道切換時間的絕大部分,應該作為重點優化對象。
FCC技術是在現有架構基礎上,部署獨立的硬件設備,采用單播方式向機頂盒發送以I幀開頭的碼流,消除等待I幀的時間,加快頻道響應速度。
因此,可在用戶側就近部署頻道緩存服務器接收來自組播源的碼流,并實時緩存到內存中,緩存數據量與頻道碼率有關,始終保證緩存中有最近的一個完整塊組。當用戶進行頻道切換時,機頂盒在向組播設備發出加入組播組請求的同時,一并向緩存服務器發送快速切換請求,緩存服務器則將最近一個塊組的媒體數據發送給機頂盒。塊組以I幀開頭,機頂盒收到后可立即進行解碼并顯示,從而提高用戶的體驗質量。如果緩存服務器由于負荷過高等原因無法處理機頂盒的請求,則不向其發送任何碼流,原有的頻道切換流程不受任何影響,機頂盒仍然可以正常進行頻道切換。一個塊組的數據發送完畢后,緩存服務器停止此次發送行為,機頂盒隨后開始處理來自組播設備的實時碼流。


圖5為江蘇電信在IPTV業務中應用FCC技術的解決方案之一。
FCC方案部署后,頻道快速切換的流程如下。
·緩存服務器事先加入所有組播組,從組播設備接收各頻道的碼流進行緩存。
·機頂盒在切換頻道時向緩存服務器發起請求,緩存服務器采用單播方式向其發送最新的一個GOP,機頂盒接收并進行解碼顯示。
·機頂盒接收來自組播設備的頻道組播碼流,轉入常規的處理流程。
實際組網時組播設備可能有多個,緩存服務器和機頂盒可以分別部署到不同的組播設備下,建議在滿足容量的前提下盡量靠近機頂盒部署。緩存服務器的處理能力相對固定,其用戶容量則受頻道數量、頻道碼率、塊組大小和用戶觀看習慣等因素的影響。
江蘇電信對應用于上述方案的FEC和FCC技術進行了實驗室測試和現網用戶試點。
實驗室測試結果表明,10%左右的FEC冗余數據能容錯2%的丟包。
選取江蘇電信2個地市分公司的用戶進行試點,試點結果見表3。
試點情況表明,FEC技術在解決直播卡頓問題中發揮了明顯的作用,但在部分極端場景(如丟包率超過糾錯閾值)下無法發揮效果。
實驗室測試結果表明,在頻道視頻碼率為2 Mbit/s、GOP值為2 s的情況下,頻道切換速度降至1 s以內。

表3 江蘇電信用戶試點情況
選取江蘇電信1個地市分公司進行試點,FCC緩存服務器為該地市IPTV平臺區域中心節點的一臺流媒體服務器,測試結果如下。
·機頂盒在EPG主頁,通過頻道+/-切換到直播頻道,頻道切換時長在1 s以內。
·機頂盒直播狀態,通過頻道+/-切換到直播頻道,頻道切換時長在1 s以內。
·機頂盒在點播狀態,通過頻道+/-切換到直播頻道,頻道切換時長在1 s以內。
·機頂盒在回看狀態,通過頻道+/-切換到直播頻道,頻道切換時長在1 s以內。
試點情況表明,FCC技術在提升頻道切換速度中發揮了明顯作用,部署后IPTV直播頻道切換速度與數字電視切換速度相當。
從信息學角度看,FEC的實質就是在傳輸層產生冗余信息,顯然,冗余碼率越高,糾錯能力就越強,但消耗的系統資源也就越多。而IPTV用戶接入的網絡帶寬是有限的,冗余碼率越高,則用于傳輸媒體碼流的有效帶寬就越小。在實施時,應實事求是地確定FEC的糾錯指標,在保證指標的前提下盡量控制冗余碼率。同樣地,FCC的效果與I幀間隔有直接關系,提高I幀間隔,可提高FCC設備的容量,降低帶寬消耗,但又會影響節目播放效果,實際中應綜合權衡。
從電信運營商的資源優勢、運營能力角度考慮,視頻業務將是電信運營商的業務拓展重點。隨著視頻應用的日益增多和視頻業務種類的拓展,視頻業務的競爭也將日益激烈。只有不斷提升用戶感知,才能在競爭中立于不敗之地。
1 姚良,奚溪.三網融合下視頻業務質量評估體系的研究.電信科學,2011(3)
2 于婧,賈鳳根,張興明等.組播技術在IPTV中的應用.電信科學,2005(5)
3 張鵬,楊乾斌,張興明等.支持IPTV用戶擴容的頻道快速切換設計.計算機工程,2009(2)