【腾讯】一文读懂腾讯会议在复杂网络下如何保证高清音频( 四 ) |腾讯QQ|运营商|技术|

那么它到底是怎么工作的呢？FEC 目前一般采用了 Reed Solomon 算法， Reed Solomon 算法的核心思想包含三个部分：

利用范德蒙德（Vandermonde）矩阵 F ，通过 FEC 控制参数生成冗余矩阵。冗余矩阵的上半部分是一个单位矩阵，分组数据矩阵和这部分计算完以后还是原来的数据，接下来这部分数据则是实际用来产生冗余数据的矩阵。图示相当于 4+2 的原始数据生成 2 个冗余数据， ENCODING 就是这样范德蒙德矩阵与原始数据相乘，分组的原始数据相当于数据源，根据 FEC 编码参数额外生成的数据包就是冗余数据。
利用高斯消元法（Gaussian elimination）恢复损坏的数据，即算冗余矩阵的逆矩阵。使用逆矩阵与接收端凑齐分组的数据矩阵进行行列式乘法计算，从而恢复丢失的数据包。
为了方便计算机处理，所有的运算是在伽罗华域（Galios）的基础上进行。伽罗华域的特点是大小为 n 的集合，其上的任何四则运算的结果仍在集合中。伽罗华域上的加减法实际上等同于异或 Xor 运算，伽罗华域上的乘除法则通过查表计算非常快。

本文插图
比如，传输过程中它可能会丢掉，比如 4+2 是 6 个包，任何顺序的 2 个包，还剩下 4 个包，就会去计算它的逆矩阵，这个逆矩阵去乘以接收端收到的任何顺序的，但是数量上凑够分组长度 4 个的数据包，通过矩阵算法可以恢复丢失的数据包。
从原理来讲很简单的，我们今天要讲 FEC ，它在实际落地过程中还有一些技巧。比如在算法实际落地的时候，怎么样去评价 FEC 算法的效果，首先会有量化数据，比如基于一个统计算法， FEC 的恢复率是多少？加不加常态 FEC？多少倍的冗余公式去加这个 FEC？最终的效果什么样的？这些都需要强大的基于大盘数据的分析和 ABTest 运维能力才能逐步获取到的最佳值。比如，在一开始的版本，在没有加常态的 FEC 下，动态 FEC 恢复其实不到 90% 。到再加常态 FEC ， FEC 恢复率可以爬升至 95% ，网络经常有小的丢包，那么指望系统、流控或者任何反馈机制，实际上不靠谱的，宁可去添加一些常态的 FEC 冗余。此外，对于实际的网络，突发的丢包是经常发生的， FEC 参数的设定也有融入控制论的相关思想，除了动态计算和下发 FEC 参数，还要考虑参数在一段时间的有效性，比如我们对 FEC 参数增加的缓降控制窗口逻辑，又进一步将 FEC 恢复率提升至最高的 99% 左右。

本文插图
右上角是大盘的数据，可以发现 FEC 整体会有明显攀升，这里就是常态 FEC 的一个效果。另外对于在这里的分组长度的确定，分组要兼顾整个系统延迟，以及你的系统规格要兼顾怎样的边界和指标，如果不通过大数据运营，你永远不知道分组多少是合适的。通过前面讲的大数据 ABTest 运营方式把数据放在真实用户的全网进行验证，找到合适分组、冗余倍率公式、控制相关的策略。下面这两张图就可以看到最终的结果，看似还是很不错的， FEC 恢复率从 95% 恢复到高的接近 99% 。
网络是有突发丢包的，可能时不时的来一下，或者丢包前后有一些持续的小丢包。 FEC 控制策略上的拖尾时间窗口的方式，可以 Cover 住这一类连续丢包。
如何做音频 ARQ 抗抖动处理 ARQ 也是一个比较成熟的技术，我们在做的过程中也是踩过一些坑的，所以今天也非常愿意跟大家分享。
如果这块做不好的话，实际上会有副作用，宁可不要这功能。在 QQ 时代，一个典型例子是应用层有个逻辑，在基于 RTT 小于多少毫秒的基础情况下，给音频数据包进行重传，主观上认为只要是把丢包重新传回来，这个效果肯定是好的，至于底层的 TRAE 音频引擎怎么处理，实际上不太关心。但这个是不够的，这就是今天讲的红箭头 5 和 6 比较细节的地方，重传算法主要关注的是对于缺失的数据包重传间隔以及最大重传次数，但是数据包重传回来的时候，这个包怎么合理利用它。同时，播放器则是按照时间轴不停播放的，数据没有来，是否还不停地要呢？这块有一个正反馈和负反馈的过程。