基于内容关键性的高效 FEC 抗网络丢包算法

导语 VoIP是基于Internet实时音视频传输的通信业务。丢包是普遍现象，也是影响主观体验最主要的因素。常规方法是构造更多的冗余以便能在丢包后用冗余信息进行恢复，更多冗余带来带宽的增加，带宽增加会加重网络负载，导致更多的丢包。 有没有更好的办法呢？

一、丢包对通话主观体验的影响

很多人问我，到底丢多少个包才会影响语音通话主观体验呢？

我从两个维度来谈谈我的看法：

1. 丢包位置：

如果是丢在非语音帧（不具备语音有用信息量），且声源环境比较安静，丢多少个包可能你都察觉不到；如果声源环境比较嘈杂，丢了非语音帧，有可能你会听到背景噪声不连续不自然，但由于不是丢重要信息，所以也不会太影响通话信息的传递。

如果是丢在语音帧（具备语音有用信息量），则丢包数越多影响就越大，轻则卡顿、重则整句话都没了，那不用说影响有多大大家都明白。

2. 连续丢包个数

我将丢包影响程度分三个级别：

1）零散随机丢包（丢1~2帧，一帧20ms），由于语音信号具有短时平稳性，大部分解码器通过PLC（丢包隐藏）功能可以较好的恢复丢包，所以一般情况下，主观体验还影响不太大。plc就是利用丢包帧相邻帧的有用信息对丢包位置进行补偿，这种补偿有参数域和时域的不同方法（这里就不细说了）。

2）连续丢包（丢3~8帧，一帧20ms），连续丢包个数在3帧以上，plc就开始失效了，因为语音是短时平稳不是长时平稳。这种情况下，如果都丢在语音帧上，我们就会感觉到声音断断续续，如果频繁丢包就挺难受的！

3）连续大丢包（丢8帧以上，一帧20ms），这种情况下很可能通话内容里面的一个字，多个字，甚至整句话都没了，例如你在电话一端说”没有“，偏偏”没“字丢包丢掉了，而你不知道，这时对方接收到的信息就完全相反了。

二、解决连续丢包的方法

1. 业界怎么做

facetime大家有用过吧，体验还不错吧，那我们看看facetime怎么解决丢包的，由于包数据都是加密的，我们不能确定具体内容，但通过抓包分析，我们可以尝试推敲一下其中的奥秘。当我们将iphone自带的开发者选项中的丢包设置为20%，抓包如下：

解释一下，从包长度可以看到每隔一个包后就有两个长度一致的包（红框位置），我们再看看这些长度一致的包有什么区别，下图是相邻两个长度为180的包（重点看下面红框蓝色部分信息，代表‘Data’内容），有没有发现这两个包的内容是完全一致的（我们也发现有个别长度一致的包，中间有一个字节的细微差异）。

而这种长度相同而Data内容基本一致的包，在配置iphone丢包率为0的时候是很少看到的，也就是说当丢包率上去后，facetime就会触发发送这种长度一致、内容相同的包，而且发包时间间隔极短，不会是丢包重传。我们理解为冗余信息，facetime自动检测网络丢包率（接收端很容易统计到并反馈给发送端），在丢包恶劣情况下启动冗余信息包发送，冗余信息里面包含了历史帧信息，接收端解析冗余信息对丢包位置进行恢复。

由于数据加密了，无法更深入地分析facetime具体如何做冗余，但用的是冗余抗丢包的技术。

2. 常规解决方法

开篇我们提到了PLC，而解决网络丢包用的更广的是FEC（Forward Error Correction，前向纠错）和ARQ（Automatic Repeat Request，自动重传请求）。FEC是通过对历史帧信息进行冗余编码，在发送正常帧后发出相应冗余帧，当接收端检测到丢包就可以利用收到的冗余帧进行恢复。ARQ是实现接收端检测丢包后通知发送端重传的协议。为了告知发送端有没有丢包，需要接收端给发送端发送ACK确认帧，ARQ的短板是易见的，丢包确认->ACK帧发送接收->发送端重发，来回一次时延较大，如果ACK帧、重发帧又丢包了，这就白费力气和时间了，而且网络负载也加大。所以常规实时通讯业务用的更多的是FEC。

三、基于内容关键性的高效FEC

在VoIP应用中，常规FEC做法是基于整包数据帧进行冗余，即将历史帧经冗余编码，例如RS（Reed-solomon codes，里德-所罗门码）编码，然后单独发出或与后续语音包捆包发出。冗余率越高丢包恢复能力越强，但高高冗余导致的带宽增加，加重网络负载导致更多的丢包。为避免问题恶化，有些抗丢包策略采取比较绅士的做法，即自动检测到当前网络负载程度，当过载则降低冗余率，目的是避免丢包率上升，是一种对FEC冗余率和丢包率平衡折中的方法。当然也有些霸王做法：），无视网络状况，我就要高冗余。

我们反思一个问题，影响语音通话体验的是哪些因素，是不是所有数据帧和所有的码流数据都要做FEC冗余呢？

好，那我们就以G.729为例看看，不按常规做是不是更好 ：）

1. 内容关键性识别

语音内容的关键性，从两个层级来描述：语音帧关键性、帧参数关键性。

1）语音帧关键性

显然语音帧比非语音帧关键，语音起始帧比较关键（声学参数发生突变）等等；

对于非关键帧（如静音帧）可以采取不做冗余的策略（整帧带宽可以省下来了）。

2）帧参数关键性

以G.729为例，其编码码流参数如下：

通过模拟丢包测试以及PESQ测试，在丢包情况下分别保留下列14种码流参数组合信息，经解码后对比MOS情况发现，LSP（线谱对），PITCH（基音周期）、GAIN（增益）的性价比最高（MOS影响大而bit占用少），可视为关键参数。同时，例如PITCH是具有较好的稳定性，所以必要时可以隔帧抽样，这样可以进一步节省带宽。

2. 基于内容关键性的高效 FEC

如上图，接收端统计丢包、检测网络拥塞并把结果信息反馈给发送端，发送端根据网络状况反馈结果配置的FEC冗余率以及关键性级别，其中关键性级别直接影响语音内容关键性识别结果，级别越高则冗余压缩越厉害（只保留最关键的码流参数），级别越低则压缩低（能保留的码流参数越多），所以通过关键性级别自适应配置可以得到FEC带宽和语音质量的平衡。最后对关键参数进行FEC编码，接收端检测到丢包则利用FEC关键参数进行丢包恢复。

本方案可以节省FEC 55%~100% 的带宽，也就是同等带宽情况下我们可以做更多的丢包恢复，本方案不追求精确恢复丢包帧，但这是一种性价比高的方案，而且对于连续丢包较多的网络，可以实现更多帧数的恢复，比无法恢复而出现丢字、卡顿现象好很多。

下面对比序列是20%丢包（最大连续丢包10个），请下载附件听：

传统fec

高效fec

四、总结

网络是传输数据的管道，数据所承载的信息能否有效传递给接收方，取决于网络传输策略与网络特性间是否匹配，本文描述的是一种思考问题的方法，仅供参考 ：）

附件：