首頁>>廠商>>交換機/ACD系統(tǒng)平臺廠商>>H3C

H3C視訊會議NAA技術(shù)解決方案

2008/08/18

方案相關(guān)內(nèi)容概述

　　由于IP網(wǎng)絡(luò)不斷普及，所以客戶在建設(shè)視訊會議系統(tǒng)時都會考慮通過IP網(wǎng)絡(luò)進行承載。在IP視訊會議系統(tǒng)中實時的視頻和音頻信息采用承載在UDP協(xié)議上的RTP通道進行傳輸，而RTP不提供任何機制來確保數(shù)據(jù)的按時發(fā)送或保證服務(wù)的質(zhì)量，甚至不能保證分組數(shù)據(jù)的順序遞交，一旦中間傳輸網(wǎng)絡(luò)出現(xiàn)點異常如網(wǎng)絡(luò)擁塞、震蕩等就會導致接收端接收到的數(shù)據(jù)產(chǎn)生丟包、亂序、延時等現(xiàn)象，使得接收終端不能解碼出流暢聲音與圖像，出現(xiàn)聲音停頓、圖像馬賽克等現(xiàn)象。

　　在視訊會議中由于RTP通道不能為視音頻數(shù)據(jù)提供良好的Qos保障，導致視訊會議在實際應(yīng)用中效果受到很大影響，杭州華三通信技術(shù)有限公司（簡稱“H3C”）在充分分析問題的基礎(chǔ)上，依靠自身在IP領(lǐng)域技術(shù)雄厚積累與視音頻技術(shù)深入研究，提出了視訊會議NAA（NetworkAuto-Adaptability，網(wǎng)絡(luò)自適應(yīng)）技術(shù)解決方案（以下簡稱“NAA”），為視訊會議提供端到端良好的Qos保障。NAA在傳輸層面與編解碼層面對視音頻的質(zhì)量進行了特性保障。

傳輸層技術(shù)體現(xiàn)

　　1、PQ隊列

　　視訊會議端點設(shè)備支持IPDiffServe服務(wù)模型。在視音頻報文發(fā)送之前把報文優(yōu)先級設(shè)置為高優(yōu)先級（如下圖中的“緊急報文”），當路由設(shè)備接收到這些視音頻報文會優(yōu)先轉(zhuǎn)發(fā)，報文的丟失率和時延這兩個性能指標在網(wǎng)絡(luò)擁塞時也可以有一定的保障。

圖1PQ隊列處理過程示意圖

　　在報文到達路由設(shè)備接口后首先對報文進行分類，然后按照報文所屬的類別讓報文進入所屬隊列的尾部，在報文發(fā)送時按照優(yōu)先級總是在所有優(yōu)先級較高的隊列中的報文發(fā)送完畢后再發(fā)送低優(yōu)先級隊列中的報文，這樣在每次發(fā)送報文時總是將優(yōu)先級高的報文先發(fā)出去，保證了屬于較高優(yōu)先級隊列的報文有較低的時延與丟失率。

　　2、冗余糾錯

　　在傳輸帶寬允許的情況下，在發(fā)送端對重要的宏塊進行冗余編碼，發(fā)送給對端，這樣的話當網(wǎng)絡(luò)出現(xiàn)異常出現(xiàn)丟包時，可以最大限度保護重要的編碼宏塊不丟失。如下：

圖2冗余糾錯處理過程示意圖

　　當?shù)?個包在傳輸過程中丟失時，由于包“3”被冗余編碼到第4個傳輸包中，在對端接收到碼流后還可以正常重構(gòu)出包“3”。

　　3、丟包重發(fā)

　　利用實時傳輸控制協(xié)議RTCP反饋信息提供丟包重發(fā)功能，當接收端檢測到有丟包時，判定對端是否來得及進行重發(fā)，可以的話通過RTCP控制信道向發(fā)送端請求重發(fā)。

圖3丟包重發(fā)處理過程示意圖

　　圖中包“2”在傳輸過程中丟失，接收端根據(jù)包往返時間及包解碼等待時間判定包“2”可以在容許的時間內(nèi)重新傳送到接收端，所以通過RTCP通道向發(fā)送端請求包“2”重發(fā)。

　　4、帶寬自適應(yīng)

　　在RTP會話期間，各會議參與者周期性地傳送RTCP包，RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料。因此，發(fā)送端可以利用這些信息動態(tài)地改變傳輸速率以適應(yīng)網(wǎng)絡(luò)的異常變化，當出現(xiàn)網(wǎng)絡(luò)擁塞時降低發(fā)送速率，當網(wǎng)絡(luò)恢復正常時恢復正常發(fā)送速率。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率達到最佳化。

圖4帶寬自適應(yīng)處理過程示意圖

　　5、抖動重整

　　由于收到中間路由交換時延抖動、擁塞影響，導致數(shù)據(jù)包到達接收端產(chǎn)生亂序現(xiàn)象，這樣直接把數(shù)據(jù)包進行解碼的話會導致圖像出現(xiàn)停頓、馬賽克等現(xiàn)象，接收端會進行一次抖動重整，按照接收到包的時戳恢復數(shù)據(jù)包原來的順序。

圖5抖動重整處理過程示意圖

編解碼層技術(shù)體現(xiàn)

　　1、錯誤恢復編碼

　　編碼器采用多描述編碼（MDC），多描述編碼是一種有效的錯誤恢復編碼方式，多描述編碼將同一個源編碼成多個獨立的子流，稱為描述，各個描述是相關(guān)的，有著同樣的重要性，每個描述符可以獨立被解碼并重構(gòu)出可用的原始信號，提供一個基本級別的視頻質(zhì)量，多描述符間存在關(guān)聯(lián)的互補信息，隨著正確地接收到的描述符數(shù)量的增加，解碼出的圖像質(zhì)量也逐步提高，多個描述一起提供改善的質(zhì)量。

　　采用多描述編碼還可以利用其他描述符中未受損害的幀來修復本描述符中受損的幀，即使是兩個描述符都遭受了分組丟失，只要這兩個描述符遭受的分組丟失不是同時發(fā)生的，他們?nèi)匀豢梢跃S持有用的視頻質(zhì)量。

　　2、錯誤隱藏

　　采用包括幀內(nèi)宏塊更新、多片(slice)、片交織、數(shù)據(jù)分割、靈活排序等錯誤隱藏和控制技術(shù)，在存在IP網(wǎng)絡(luò)丟包和無線網(wǎng)絡(luò)誤碼的情況下，盡可能的提供視頻數(shù)據(jù)的恢復，降低對圖像質(zhì)量的影響。如下示例中，當接收端發(fā)覺包“2”傳輸過程中已經(jīng)丟失而無法彌補或者出現(xiàn)不可恢復的錯誤時，接收端根據(jù)圖像時間與空間關(guān)聯(lián)性，預測出包“2”，插入到正常圖像序列中，保證圖像流暢性。

圖6錯誤隱藏處理過程示意圖

　　3、可選的H.264

　　視訊會議產(chǎn)品中集成H.264編解碼技術(shù)，其編碼效率比傳統(tǒng)的H.263、MPEG4等編碼方式提高了30％到50％，在同等圖像效果下可以大大節(jié)省傳輸帶寬。H.264除了具有高效編碼的特性，還引入了一些新工具用于提高錯誤恢復能力，特別是參數(shù)集、NAL（網(wǎng)絡(luò)抽象層）上的NALU的概念、視頻編碼層的FMO（靈活的宏塊順序）和數(shù)據(jù)分割等都歷史性地提高了在盡力而為的IP網(wǎng)絡(luò)環(huán)境下視頻通信的性能。

技術(shù)應(yīng)用

　　NAA技術(shù)廣泛地應(yīng)用到H3C的視訊會議設(shè)備中：

圖7NAA技術(shù)應(yīng)用意圖

　　應(yīng)用NAA技術(shù)，H3C視訊會議產(chǎn)品在實際網(wǎng)絡(luò)中驗證效果如下：


　　 通過在設(shè)備中承載NAA技術(shù)，H3C視訊會議系統(tǒng)更加能夠適應(yīng)于以下運行環(huán)境：

　　Internet視訊會議：由于Internet網(wǎng)絡(luò)是一個不可靠無連接網(wǎng)絡(luò)，只提供一種承載業(yè)務(wù)-盡力傳送(besteffort)業(yè)務(wù)。也就是說，網(wǎng)絡(luò)并不保證向應(yīng)用數(shù)據(jù)流提供所需的帶寬，也不保證數(shù)據(jù)流的傳送時延和丟失率等質(zhì)量指標。對于數(shù)據(jù)業(yè)務(wù)等非實時業(yè)務(wù)，盡力傳送能夠滿足要求，但是對于視訊會議等實時通信應(yīng)用，網(wǎng)絡(luò)必須能提供端到端承載業(yè)務(wù)的Qos保障能力，而NAA技術(shù)剛好能夠滿足這種要求。

　　帶寬有限，業(yè)務(wù)繁忙網(wǎng)絡(luò)：一些企事業(yè)單位帶寬有限，同時在有限的帶寬中承載了視訊會議與其它業(yè)務(wù)如OA，導致其它業(yè)務(wù)與視訊會議爭搶網(wǎng)絡(luò)資源的情況，運用NAA技術(shù)，提高視訊會議包的轉(zhuǎn)發(fā)優(yōu)先級，通過包冗余糾錯與重發(fā)特性，保證包丟失率達到最少，加上動態(tài)調(diào)整帶寬能力與解碼前包前處理保障，可以比較好得保證視訊會議的視音頻效果。

飛象網(wǎng)


相關(guān)鏈接:
鑫苑置業(yè)選擇H3C IToIP 實現(xiàn)無障礙溝通 2008-12-25
H3C高清視頻會議系統(tǒng)亮相安博會 2008-12-12
內(nèi)蒙古農(nóng)信聯(lián)社采用H3C的視頻會議系統(tǒng) 2008-12-08
H3C助力撫順網(wǎng)通承建平安城市監(jiān)控系統(tǒng) 2008-10-22
H3C獲中國IP通信大會兩項大獎 2008-10-09

分類信息: