糾刪碼在實時視頻流中的應用丨Dev for Dev 專欄

語言: CN / TW / HK

本文為 「Dev for Dev 專欄」 系列內容,作者為聲網網絡體驗團隊 王瑞。

0 1

背景

在實時音視頻通話中,音視頻質量受網絡丟包影響較大,特別是對於視頻。

為什麼視頻對丟包更敏感呢?通常來説, 音頻的原始碼率相對視頻來説比較小,因此音頻編碼器的壓縮率比視頻編碼器要小很多。 音頻幀通常都是獨立編碼和解碼的,因此任何一幀數據的丟失,都不會影響其他幀的解碼。

而對於視頻來説,為了達到較高的壓縮率,通常會採用殘差編碼的方法來去除大量的空間和時間宂餘信息,這就導致了在解碼時,需要依賴參考幀才能正確解碼,任何一幀數據的丟失,都會導致後續互相關聯的一些幀無法解碼。由於視頻幀之間的這種相關性就導致了視頻對傳輸丟包更加敏感。

常見的丟包包括 IP 傳輸網絡的擁塞丟包,以及靠近用户側的無線丟包。擁塞丟包一般是由於網絡中處理能力比較小的瓶頸節點導致的,可能表現為隨機或連續丟包,無線丟包一般是由於信道干擾導致的,經常表現為連續丟包。當然,在實際網絡的丟包原因很多,表現也都不一樣。

通過擁塞控制算法可以一定程度避免擁塞丟包的產生,但無法解決所有場景的丟包問題。

丟包發生後,通常會採用以下兩種補救方法:

(1)重傳 (Automatic Repeat-reQuest, ARQ)

重傳是一種高效的補救手段,但它依賴反饋信道,同時重傳效率對網絡RTT非常敏感。在高丟包下可能需要多次重傳。

(2)糾錯編碼 (Forward Error Correction, FEC)

糾錯編碼無需反饋信道,同時網絡RTT的大小也不會影響它的效率。

在一對一的互聯場景中,如果網絡RTT較低,重傳是一種合適的選擇。但在RTT較大的時候,重傳的效率會明顯降低。另外在大規模的多播和廣播應用中,過多的重傳請求可能會加劇網絡擁塞和丟包。

在這些情況下,採用FEC技術是更合適的選擇。FEC在編碼端進行宂餘編碼,在接收端通過宂餘數據自動恢復出丟失的數據包,其優勢在於不依賴反饋信道,且糾錯效率不受RTT影響。因此,在高RTT環境中,可以有效避免重傳導致的高延遲。本文主要對實時視頻傳輸中的FEC技術做簡要介紹,並介紹聲網的最佳實踐。

0 2

基本概念介紹

1、刪除信道

如果發送端發送的一組數據,經過特定信道傳輸,其丟失數據的位置對接收端是已知的,那麼這種信道模型就稱之為刪除信道。基於互聯網的包交換網絡是一種典型的刪除信道,在這種信道模型下,所有已接收到的數據都被認為是正確的。

2、檢錯碼,糾錯碼與糾刪碼

在信道編碼中,差錯控制編碼根據編碼用途不同,可以分為檢錯碼、糾錯碼和糾刪碼三種。

檢錯碼是為了校驗數據經過信道傳輸後是否出現了錯誤,常用的檢錯碼包括簡單奇偶校驗碼、循環宂餘校驗碼等。糾錯碼不僅可以識別到信道傳輸是否出現了錯誤,還能糾正傳輸錯誤。在糾錯碼看來,經過差錯信道傳輸後,接收端收到的數據都是不可靠的,需要通過解碼來發現和糾正錯誤。常見的糾錯碼包括漢明碼、BCH碼等(見參考資料5)。

糾刪碼可以認為是一種特殊的糾錯碼,對於糾刪碼來説,其差錯信道是一種刪除信道,對接收者來説錯誤的位置是已知的,並且收到的數據都認為是正確的,因此其編譯碼會比糾錯碼更容易一些。

傳統糾錯碼技術的發展已經非常成熟,通常用在網絡協議的物理層和數據鏈路層,用於保障可靠的鏈路級信道。而糾刪碼大部分是基於糾錯碼的理論發展而來,常用於應用層的FEC編碼。

3、RS碼

在視頻傳輸的應用層FEC編碼算法中,RS碼是一種常見的算法。RS碼是一類重要的線性分組碼,也是一種性能優異的短碼,工作在有限域上。線性分組碼通常用(n,k)碼來表示,對於位編碼來説,k和n表示比特數,其中k為信息位個數,n為碼長;而在應用層FEC領域,FEC編碼採用包編碼方式,在包編碼中,k和n都表示包數。對於碼長為n的RS糾刪碼來説,只要收到任意k個信息位,就可以解碼出所有n個數據。

對於一個(n,k)線性糾刪碼,可以表示為如下的矩陣運算:  Y = x * G

其中,x是信息位向量,y是碼字向量,G是生成矩陣。

在RS碼中,常見的生成矩陣有範德蒙矩陣和柯西矩陣,分別如下圖所示,這兩種矩陣的特點是任意子矩陣均可逆,因此總能利用任意k個接收碼字來解碼出剩餘n-k個碼字。

  

■範德蒙矩陣

 

柯西矩陣

4、有限域運算

域是一個可以在其上進行加、減、乘、除運算而結果不會超出域的集合,如果域中的元素個數是有限的,就稱為有限域,或伽羅華域。有限域在密碼學、編碼理論中有着廣泛的應用。

RS碼是一種工作在有限域GF(2^q)上的多進制糾刪碼,RS碼的全部碼元取自有限域GF(2^q)上。通常,我們可以用以下兩種方法來構造有限域:

定理一: 對於集合Zp={0,1,…,p-1},如果p為素數,那麼在Zp上進行模p的加法和乘法運算就構成一個有限域。

即  Z 2 ,Z 3 ,Z 都是有限域,但是  Z 不是,因為8不是素數。 為了能夠在非素數上構造有限域,就需要藉助於本原多項式。

定理二: 如果p為素數,m為正整數,那麼在GF(p^m)上模一個m階本原多項式也構成有限域。

本源多項式就是首項係數為1的不可約多項式,在實際算法實現中,考慮到性能與算法複雜性,RS算法常實現在GF(2^8)域上,本原多項式可以有多個,如下就是一個8階本源多項式的例子:

P(x) = x 8 + x 4 + x 3 + x 2 + 1

0 3

實時視頻流的FEC編碼方案

1、卷積碼與分組碼

所謂分組碼是指編碼器需要預先把輸入數據分組,達到分組長度才能編碼。而卷積碼的輸入是連續的,輸出也是連續的,不需要進行預分組。

分組碼的輸出只與當前編碼的分組數據有關,例如(n,k)分組碼以k個輸入為一組,編碼出n個輸出,輸出僅與k個輸入有關。而(n,k,L)卷積碼的編碼輸出不僅與k個輸入有關,還與歷史的L個輸入有關。L為約束長度,或記憶深度。

為了增強對抗連續丟包的能力,通常會增加分組碼的分組長度(即k),但是由於分組碼的解碼延遲是線性的,k值的增加會導致解碼延遲的增加。這就帶來了分組長度的選擇問題,較長的分組長度能提供更好的糾錯能力,但同時增大了系統延遲。而卷積碼不需要考慮分組長度問題,可以實現on-the-fly coding,更適合實時流傳輸場景使用。

2、常見的幾種編碼方案

對實時視頻流來説,常見有以下幾種編碼方案,幀級編碼、GOP級編碼、擴窗編碼、滑窗編碼。其中前兩種是分組碼,後兩種是卷積碼的應用。

幀級FEC編碼以單幀為分組單位(如下圖),在這種編碼方案中,FEC可以實現最小解碼延遲,但在低碼率下由於分組太小,導致在連續丟包時很容易出現無法解碼的情況。GOP級編碼以GOP為分組單位,這種編碼方案的好處是大幅提高了連續丟包下的解碼穩定性,但是也帶來了較大的解碼延遲,在實時場景中難以應用。

擴窗和滑窗編碼是卷積碼的具體應用,由於不存在分組問題,所以理論上可以在視頻流的任意位置進行編碼。兩者的區別是,對幀X進行編碼時,擴窗編碼會編碼所在GOP範圍內的第1至第X幀,而滑窗編碼只會編碼第X-T到X幀,其中T為最大窗口長度。這兩種編碼方式都能很好的提高連續丟包場景下的解碼概率,同時不會額外增加解碼延遲。但由於擴窗編碼在大GOP下存在性能問題,因此滑窗編碼是一個更為實際的方案。下圖是一個T=3的滑窗FEC編碼的例子。

3、信源與信道聯合卷積編碼

在聲網的實踐中,我們不僅大規模應用了卷積碼方案,驗證了卷積碼在實時視頻流傳輸中的優勢,同時,我們將信源編碼與信道編碼結合,創造了一種新的編碼方案,並命名為DMEC(Dense Matrix Erasure Coding),DMEC真正發揮了卷積碼的最大性能優勢,能夠實現在不同場景下的最優視頻QoE。

在信息論中,對信息的編碼分為信源編碼和信道編碼,信源編碼是為了去除宂餘信息,提高通信效率,例如常用的視頻編碼器H.264就是一種信源編碼器。而信道編碼是為了對抗信道中的噪聲和衰減,通過增加宂餘,來提高抗干擾和糾錯能力,例如上面講到的RS碼就是一種信道編碼算法。

對於視頻信源編碼器來説,以H.264為例,通常視頻幀是逐幀參考的,即後一幀總是參考同GOP內的前一幀。但在分層編碼的情況下則不然,在分層編碼時,視頻幀會分為基礎層和一個或多個增強層。在多下行的場景中,分層編碼可以為不同設備和不同網絡情況的終端提供不同等級的自適應視頻流。但與此同時,分層編碼使得視頻幀的依賴關係變得複雜,如果仍然套用簡單的滑窗FEC編碼,視頻質量將無法達到最優。  

相比於傳統的滑窗方案,DMEC將信源編碼器輸出的視頻幀參考關係作為卷積編碼器的編碼約束,排除了非參考幀對於解碼概率的影響,使得視頻可播放幀率(Playable Frame Rate, PFR)達到最優(該方案的理論依據見參考文獻1)。

在DMEC編碼時,當前幀的編碼窗口僅包含當前幀以及其參考幀,越重要的幀被參考的概率就越大,那麼在FEC編碼時被編碼次數就越多,在解碼側被恢復的概率就越高,通過這種機制,DMEC自動實現了非對等保護(UEP),而不需要為高優先級的幀分配更多的FEC碼率。

僅以下圖所示的兩層時域、兩層空域SVC為例説明,當T=6時,幀 P 31 的編碼窗口中包含了 I 00  , I 01  , P 20  , P 21  , P 30  ,  P 31

4、性能對比

下圖是不同FEC方案在實驗室採用標準序列的PFR測試結果,PFR即可播放幀率,是評估FEC算法對最終視頻體驗的直觀指標。其中紅色是幀內FEC,藍色是滑窗FEC,紫色是聲網的DMEC。可以看出DMEC相較於另外兩種方案的明顯優勢。

除了實驗室數據,我們還通過對線上進行大規模的A/B Test,並通過數據挖掘獲取了大量的對比數據(下表為部分客户的A/B Test對比數據),同樣驗證了聲網自研的DMEC相比傳統FEC方案對於降低視頻卡頓率的效果。

場景

灰度分鐘數

卡頓率降幅

客户A

1v1

1.3 百萬

22.22%

客户B

會議

5.6百萬

10.94%

客户C

直播

0.4 百萬

12.73%

參考文獻

1,R. Wang, L. Si and B. He, "Sliding-Window Forward Error Correction Based on Reference Order for Real-Time Video Streaming," in IEEE Access, vol. 10, pp. 34288-34295, 2022, doi: 10.1109/ACCESS.2022.3162217.

<https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9741773>

2, [RFC8680]  Roca, V. and A. Begen, "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes", RFC 8680, DOI 10.17487/RFC8680, January 2020,

< https://www.rfc-editor.org/info/rfc8680 >.

3, Vincent Roca, Belkacem Teibi, Christophe Burdinat, Tuan Tran-Thai, Cédric Thienot. Block or Convolutional AL-FEC Codes? A Performance Comparison for Robust Low-Latency Communications. 2017. ffhal-01395937v2

< https://hal.inria.fr/hal-01395937v2/document >

4, Sliding Window Selective Linear Code (SLC) Forward Error Correction(FEC) Scheme for FECFRAME draft-wang-tsvwg-sw-slc-fec-scheme-03

< https://datatracker.ietf.org/doc/html/draft-wang-tsvwg-sw-slc-fec-scheme-03 >

5,Department of Electrical and Computer Engineering - University of New Brunswick, Fredericton, NB, Canada

(正文完)

READING

近期好文

安全合規 SDK 教程 音頻的價值

軟件亂象 質量體系建設 聲網VQA

依圖 百度飛槳 數美

自動化測試 語音識別SDK 黑盒測試

關於 Dev for Dev

Dev for Dev 專欄全稱為 Developer for Developer,該專欄是聲網與 RTC 開發者社區共同發起的開發者互動創新實踐活動。

透過工程師視角的技術分享、交流碰撞、項目共建等多種形式,匯聚開發者的力量,挖掘和傳遞最具價值的技術內容和項目,全面釋放技術的創造力。

關注「聲網開發者」

關注實時互動領域的

技術實踐 行業洞察 人物觀點

☟☟