移动端多人视频通话软件开发（五）– 音视频质量

在完成DEMO之前，音视频质量的优化主要碰到如下问题，当然，优化过程无止境，现在还在不停的优化

此处由于涉及相关技术，解决问题方案不做具体深入参数

1. 使用的live555的底层source/sink框架+自己写的控制框架+doubango的音视频处理部分

2. 在内网调试，发现在画面变化的时候，容易出现花屏， 看抓包，有部分丢包，且丢一个包的次数较多（VGA）

尝试了几种办法：

1. 鉴于视频是流转发的，FEC在doubango也较为成熟， 移植过来工作量应该在1周左右，故准备上FEC。

最终花了3周时间，上了FEC之后，有一些效果，但效果不是特别显著

2. 通过IP头域的TOS字段修改，也未解决什么问题

3. 降低码率，原来要飙到1M，修改之后，在500-800K之间

4. 5个PAD，分散在不同的wifi上

5. 1s一个I桢

这样，解决了第一次内网演示的问题

3. PAD的码流压不下来，一直在500-800K之间，采用最新的X264库，恒定编码，能够压缩在256K，加上FEC和包头，带宽占用在400-500之间，较为正常

4. 丢包不做解码，增加I桢请求，I桢延长至10s一个，卡顿比花屏的效果好

5. 购买新的wifi设备，替换原有的TP-Link

6. 声音卡顿问题

下行丢包之后，没有做丢包补偿，导致缓冲空了，增加丢包补偿

服务器下行少包

7. 声音时延越来越长

PAD20ms取数据的时间，使用了锁，导致某些时候等待时间过长，整理代码，解决问题

server端20ms发包采用了sleep，没用timer，导致时间计算不正确，发包时间大于20ms

8. 大声说话有破音

PAD端增加增益控制，解决问题

9. 内网视频的时延在2-3s

某些模块缓冲时间过长， 取消之后，时延在1s左右

10. 唇音同步，通过对音视频的缓存长度的调整，达到了内网的唇音同步（即排除网络因素的唇音同步）

11. 出来视频的时候，画面出来时间较长

信令优化，时间控制在1.5s左右

12. FEC采用9:2的方式， 即11个包中有2个是冗余包

因为通过抓包发现， 丢包基本是在1-2个， 而且丢包间隔都较长

13. opus的引入（2周时间）

前期的调研看，音质还是不错的，对PLC效果也非常好，3个丢1个， 10个丢3个， 恢复的也都能听清楚声音

采样率使用16k，码率是32k，20ms一个包

鉴于包头太大，尝试改成40/60ms一个包之后， PLC效果下降很多，故还是20ms

服务器的PLC使用了新的插件