音视频会议在音频混音过程中，如何使用rfc4588和音频编解码的fec功能

前言：由于之前的项目都是在pc端进行，网络基本稳定，音视频会议系统基本稳定。

但随着需求的增加，移动端开始运营，发现移动端在弱网环境下，根本无法使用。于是开始研究rfc4588协议（webrtc支持）和opus的fec的功能。

改进前，没有开启fec和rfc4588，opus在丢包超出15%的情况下，出现明显的卡顿，无法使用。

若单独开启fec，提高5个百分点，20%，正常。

开启nack，经过我们的测试，丢包率达到60%，依然能听到对方声音，70%开始出现卡顿。

接下来要详细描述一下，如何将nack与fec结合，达到最好的抗丢包效果。

首先简单介绍一下混音两个流程：

1、我们的音视频会议系统音频是混音，每隔若干个20毫秒，将每个参会者音频数据按rtp序列号排序且按顺序混音，混音好的结果为sum；

2、将sum减去各个参会者的的声音，发送给各自的参会者，

 

在以上第一个步骤，每个参会者的音频包必须是按顺序排序，如何中间出现丢包，发送nack，请求重发，这个过程需要等待，且未收到丢包重发之前，必须将后续数据放入新的一个队列中，关键的两个动作请求重发，等待

如何平衡这两个动作，等待过长，延时越大。

经过我们的实验等待的时间最好不要超出10个音频包的时间，如果过长，时延也会过大，

当我们收到重发包：一类是忽略：包已过的包和收到的包与期望相差太大（即gap过大），另一类:正是我们需要的，进行fec，进行音频前向纠错。