关于视频:纠删码在实时视频流中的应用丨Dev-for-Dev-专栏

本文为「Dev for Dev 专栏」系列内容，作者为声网网络体验团队王瑞。

01 背景

在实时音视频通话中，音视频品质受网络丢包影响较大，特地是对于视频。

为什么视频对丢包更敏感呢？通常来说，音频的原始码率绝对视频来说比拟小，因而音频编码器的压缩率比视频编码器要小很多。音频帧通常都是独立编码和解码的，因而任何一帧数据的失落，都不会影响其余帧的解码。

而对于视频来说，为了达到较高的压缩率，通常会采纳残差编码的办法来去除大量的空间和工夫冗余信息，这就导致了在解码时，须要依赖参考帧能力正确解码，任何一帧数据的失落，都会导致后续相互关联的一些帧无奈解码。因为视频帧之间的这种相关性就导致了视频对传输丢包更加敏感。

常见的丢包包含 IP 传输网络的拥塞丢包，以及凑近用户侧的无线丢包。拥塞丢包个别是因为网络中解决能力比拟小的瓶颈节点导致的，可能体现为随机或间断丢包，无线丢包个别是因为信道烦扰导致的，常常体现为间断丢包。当然，在理论网络的丢包起因很多，体现也都不一样。

通过拥塞控制算法能够肯定水平防止拥塞丢包的产生，但无奈解决所有场景的丢包问题。

丢包产生后，通常会采纳以下两种补救办法：

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

重传是一种高效的补救伎俩，但它依赖反馈信道，同时重传效率对网络RTT十分敏感。在高丢包下可能须要多次重传。

(2)纠错编码(Forward Error Correction, FEC)

纠错编码无需反馈信道，同时网络RTT的大小也不会影响它的效率。

在一对一的互联场景中，如果网络RTT较低，重传是一种适合的抉择。但在RTT较大的时候，重传的效率会明显降低。另外在大规模的多播和播送利用中，过多的重传申请可能会加剧网络拥塞和丢包。

在这些状况下，采纳FEC技术是更适合的抉择。FEC在编码端进行冗余编码，在接收端通过冗余数据主动复原出失落的数据包，其劣势在于不依赖反馈信道，且纠错效率不受RTT影响。因而，在高RTT环境中，能够无效防止重传导致的高提早。本文次要对实时视频传输中的FEC技术做简要介绍，并介绍声网的最佳实际。

02 基本概念介绍

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的加法和乘法运算就形成一个无限域。

即Z2,Z3,Z5都是无限域，然而Z8不是，因为8不是素数。为了可能在非素数上结构无限域，就须要借助于本原多项式。

定理二：如果p为素数，m为正整数，那么在GF(p^m)上模一个m阶本原多项式也形成无限域。

根源多项式就是首项系数为1的不可约多项式，在理论算法实现中，思考到性能与算法复杂性，RS算法常实现在GF(2^8)域上，本原多项式能够有多个，如下就是一个8阶根源多项式的例子：

03 实时视频流的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码就是一种信道编码算法。

对于视频信源编码器来说，以H264为例，通常视频帧是逐帧参考的，即后一帧总是参考同GOP内的前一帧。但在分层编码的状况下则不然，在分层编码时，视频帧会分为根底层和一个或多个加强层。在多上行的场景中，分层编码能够为不同设施和不同网络状况的终端提供不同等级的自适应视频流。但与此同时，分层编码使得视频帧的依赖关系变得复杂，如果依然套用简略的滑窗FEC编码，视频品质将无奈达到最优。

相比于传统的滑窗计划，DMEC将信源编码器输入的视频帧参考关系作为卷积编码器的编码束缚，排除了非参考帧对于解码概率的影响，使得视频可播放帧率(Playable Frame Rate, PFR)达到最优（该计划的理论依据见参考文献1）。

在DMEC编码时，以后帧的编码窗口仅蕴含以后帧以及其参考帧，越重要的帧被参考的概率就越大，那么在FEC编码时被编码次数就越多，在解码侧被复原的概率就越高，通过这种机制，DMEC主动实现了非对等爱护（UEP），而不须要为高优先级的帧调配更多的FEC码率。

仅以下图所示的两层时域、两层空域SVC为例阐明，当T=6时，帧P31的编码窗口中蕴含了I00 , I01 , P20 , P21 , P30 ,和 P31 。

4、性能比照

下图是不同FEC计划在实验室采纳规范序列的PFR测试后果，PFR即可播放帧率，是评估FEC算法对最终视频体验的直观指标。其中红色是帧内FEC，蓝色是滑窗FEC，紫色是声网的DMEC。能够看出DMEC相较于另外两种计划的显著劣势。

除了实验室数据，咱们还通过对线上进行大规模的A/B Test，并通过数据挖掘获取了大量的比照数据（下表为局部客户的A/B Test比照数据），同样验证了声网自研的DMEC相比传统FEC计划对于升高视频卡顿率的成果。

参考文献

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

对于 Dev for Dev

Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区独特发动的开发者互动翻新实际流动。

透过工程师视角的技术分享、交换碰撞、我的项目共建等多种形式，汇聚开发者的力量，开掘和传递最具价值的技术内容和我的项目，全面开释技术的创造力。