WebRTC中弱网优化可以考虑的点

弱网场景：一般指流媒体传输过程中出现的丢包、乱序、抖动等网络现象，进而影响流媒体传输质量，造成声音画面卡顿、甚至花屏等现象。

 

优化思路要结合具体的应用场景：

重视用户的体验延时：此时注重快速重传，重传的次数要少，网络差一点救不回来就算了，可以直接丢弃，用户可以容忍一些卡顿。

重视卡顿率指标：可以增大用户接收缓存，通过缓冲对抗网络的抖动，让卡顿率下降，但是可能会带来延时的增加。

重视用户的带宽需求：用户网络带宽贵，就尽可能减小FEC包的量。

 

一、带宽估计

核心：尽可能快速跟踪网络带宽变化，准确估计。

GCC中，基于丢包的拥塞控制遇到丢包就下降带宽，可以根据场景需求，不要一下子就降低很多带宽，可以先降低编码输出码率；

限制网络带宽变化的时候带宽变化的上下幅度。

 

二、带宽分配

媒体包与重传包、FEC包的比例调整。

 

三、重传和FEC

重传时机优化

WebRTC中的NACK，重传的间隔默认是100ms（待进一步确认），重传效率低，实际场景中不同的网络环境，RTT应该是不一样的，可以根据实际的RTT进行调整。

重传的时机，按照RTO来算。

 

重传优先级优化

重传的包优先级应该大于视频包。

重传的包中，优先传包序号小的。

 

重传次数的优化

如何定义包的生存周期。

有了丢包率之后，就可以算出大概传几次可以将包重传到对端。

 

FEC的冗余数量

根据RTT和丢包率来分配。

冗余包的比例根据带宽来分配。

 

四、抖动缓冲

根据应用场景看是优先保证延时或者是保证流畅度。

尤其在低延时场景中，需要较低延时的场景，例如云游戏云手机场景，尽可能不缓冲数据，缓冲也可能缓冲一两帧的数据，保证接收端接收到数据之后就送解码器解码播放。这种方式可能带来卡顿，通过牺牲流畅度来保证延时。

webrtc中有个可以设置缓冲的参数，RTP包头部扩展字段playout_delay，通过sdp进行通信双方协商，或者视频包添加RTP头部扩展时设置。

默认值是-1，根据官网文档的描述，设置成0是让接收端尽快播放，100-200ms应用于交互式的媒体流，400ms就是确保对抗一些微小的网络抖动。

这个值就是典型的在延时和卡顿率之间做平衡。