1. 程式人生 > >FEC改善UDP(RTP)傳輸音視訊的問題

FEC改善UDP(RTP)傳輸音視訊的問題

1 FEC概念

前向糾錯也叫前向糾錯碼(Forward Error Correction,簡稱FEC),是增加資料通訊可信度的方法。在單向通訊通道中,一旦錯誤被發現,其接收器將無權再請求傳輸。前向糾錯編碼(FEC)技術通過在傳輸碼列中加入冗餘糾錯碼,在一定條件下,通過解碼可以自動糾正傳輸誤碼,降低接收訊號的誤位元速率(BER)FEC 是利用資料進行傳輸冗餘資訊的方法,當傳輸中出現錯誤,將允許接收器再建資料。其基本原理是:在傳送端,通過將k bit資訊作為一個分組進行編碼,加入(n-k)bit的冗餘校驗資訊,組成長度為nbit的碼字。碼字經過通道到達接收端之後,如果錯誤在可糾範圍之內,通過譯碼即可檢查並糾正錯誤bit,從而抵抗通道帶來的干擾,提高通訊系統的可靠性。

2實時音視訊UDP傳輸

在Internet上進行音視訊實時互動採用的傳輸層方案有TCP(如:RTMP)和UDP(如:RTP)兩種。

TCP協議能為兩個端點間的資料傳輸提供相對可靠的保障,這種保障是通過一個握手機制實現的。當資料傳給接收者時,接收者要檢查資料的正確性。傳送者只有接到接收者的正確性認可才能傳送下一個資料塊。如果沒有接到確認報文,這個資料塊就得重傳。儘管這種機制對傳送資料來說是非常合理的,但當用它在Internet傳輸實時音視訊資料時就會引發很多問題。首先就是延遲問題,在傳輸通道丟包率較高時,TCP的傳輸質量下滑嚴重,重傳擁塞導致音視訊延時非常大,失去實時互通的意義。特別是無線通道(WIFI、4G、3G)下,使用TCP做雙向互通通訊穩定性欠佳,易出現音視訊長時間卡住不動然後快放的現象。 更多的產品選擇採用的協議是UDP(一般上層應用層協議為RTP,以提供序號和音視訊同步的服務)。

UDP同TCP相比能提供更高的吞吐量和較低的延遲,非常適合低延時的音視訊互動場合。

2.1 UDP傳輸存在的問題

UDP效能的提高是以不能保障資料完整性為代價的,它不能對所傳資料提供擔保,常見的問題有包亂序、包丟失、包重複。無線通道(WIFI、4G、3G)下,UDP包亂序和包丟失可以說是常態。

亂序原因:

(1)路由器的儲存佇列導致的包亂序。

(2)UDP包據經過不同的路由造成了傳送資料的混亂。

丟包原因:
(1) 當路由器和閘道器發生擁塞時,某些包可能被丟棄,發生這種情況一般是由於網路中傳輸的資料包大於網路通道的承載能力。

(2) 分組資料在傳送時有生存時間限制以避免路由中死迴圈的出現,網路狀況惡劣時,分組可能超時丟失。
(3) 接收端工作超載執行時可能因排程困難而不能及時處理網口資料。

視訊碼流的少量丟失都會導致解碼後的視訊出現花屏的現象。H264、HEVC這樣的高壓縮率視訊壓縮標準使得壓縮的冗餘度非常低,碼流的丟失除了影響本幀的解碼外,還將影響以此為參考的視訊幀解碼,導致花屏的累積擴散,直至下一個關鍵幀的到來視訊畫面方能恢復。雖然解碼器內部會做一定的錯誤掩蓋處理,但效果並不理想,特別是採用ffmpeg這類開源的解碼器,其錯誤掩蓋演算法做得比較簡單。為此,在很多產品中不得不採用較小的GOP(較小的I幀間隔),以期在出現丟包花屏後能儘快的用I幀碼流重新整理畫面。這種方法副作用較大,而且某些場合下甚至會適得其反。因為I幀壓縮效率遠不如P幀、B幀,I幀往往比P幀、B幀大很多,頻繁的I幀將給傳輸通道帶來持續的波動壓力,造成更嚴重的丟包、亂序。另外,因為編碼器位元速率控制的緣故,I幀佔用較多的碼流後,緊接著的P、B幀將不得不採用較大的QP量化引數(較差的影象質量)以保證位元速率的區域性可控,這樣帶來的直觀感受是影象隨著I幀間隔週期性的發虛、馬賽克。亂序的UDP包不經過順序恢復直接送解碼器同樣會導致解碼花屏,因為解碼器內部會將遲到的資料包丟棄。

綜上所述,工程中急需一種抗丟包、抗亂序的增強型UDP方案來提升實時音視訊傳輸效果,目前基於RTP並採用FEC前向糾錯和後端QOS處理的完整解決方案,效果非常明顯。

3 FEC/QOS

對於丟包,我們採用改進型的vandermonde矩陣FEC(Forward Error/Erasure Correction)前向糾錯技術來進行丟包恢復,由傳送方進行FEC編碼引入冗餘包,接收方進行FEC解碼並恢復丟失的資料包。

對於包亂序和包重複,我們採用QOS亂序恢復處理,該QOS方案特點是在沒有丟包的情況下,不引入任何系統延時,並且可以通過可控的丟包等待時延來適應不同的通道亂序程度。QOS需要在接收端進行FEC解碼前進行,確保送FEC解碼模組的資料包序號是正確的(不存在亂序,僅存在丟包)。

眾多產品案例表明:採用FEC+QOS+RTP的組合,能顯著提升UDP傳輸的丟包、亂序抵抗力,為上層音視訊服務提供有力保障。下圖1是各模組在系統中的位置說明。

需要說明如下幾點:

(1)從差錯控制角度看,傳輸通道可以分為隨機通道、突發通道和混合通道。在隨機通道中,丟包出現是隨機的,且相互統計獨立,滿足正態分佈。在突發通道中,丟包是集中出現的,在一些短促的時間區間會出現大量的丟包,而在這些時間區間之外又存在較長的無丟包區間。混合通道則是上述二者的合體。本方案側重於對具備隨機通道特性的傳輸鏈路進行改進優化。

對Internet通道的丟包特性研究發現,大多數情況下其滿足隨機通道的特點,丟失的都是單個包。連續兩個或以上包同時丟失的概率雖然比純隨機過程要高,但發生的概率還是要比單包丟失低,發生連續丟失10個以上包的概率就更低了。由於單包丟失出現的最頻繁,我們的抗丟包方案主要側重於對單包丟失的修復,同時也應該兼顧連續丟失的少量包的修復。對大量連續丟失的包的修復相對來說就顯得不那麼重要了(出現概率低,修復的代價大)。

(2)當然,任何差錯控制方案都是有其最大糾錯能力限制,當丟包率超出當前系統的糾錯能力時,丟包無法恢復,對於視訊應用來說意味著視訊將出現花屏

為了改善系統在高丟包率下的使用者體驗,避免長時間花屏無法重新整理的現象,我們建議使用者採用ARQ(自動請求重發)+FEC機制,這裡的ARQ請求並不是請求遠端重發丟失的資料包,因為那樣相當於走了TCP這類內嵌ARQ功能協議的老路,必然引入不可控的延時。這裡的ARQ只是請求遠端即刻編碼視訊關鍵幀避免長時間花屏無法重新整理的現象,ARQ請求一般通過額外的TCP通道發出(在絕大多數的系統中,通訊雙方一般會有TCP的信令通道,用於雙方業務層信令的互動)。ARQ的發起是根據FEC解碼輸出視訊碼流是否丟包作為判斷依據,傳送端和接收端都需要對ARQ的頻率做一定的保護措施,避免頻繁的發起和響應,造成過多的I幀。