WebRTC 弱网测试分析

Posted 2022-10-18 unclerunning

文章目录

• • 影响观看体验的是什么？
  • 网络差的具体表现
  • 弱网网络模型
  • • 带宽受限型网络
    • 信道差错型网络
    • WebRTC视频接收处理流程
    • • Why Fec？
      • • Nack的特点
        • • Jitter buffer
        • 拥塞控制
        • FEC
    • Buffer？
  • 实验

影响观看体验的是什么？

$$影响观看体验的主观因素\{\begin{array}{l}卡顿\\ 延迟\\ 马赛克\\ 绿屏+花屏\\ 爆音\\ 变频音\\ ...\end{array}$$
一般出现这种情况，我们就认为网络差。

网络差的具体表现

$$网络差的具体表现\begin{array}{l}抖动大\\ 丢包高\end{array}$$

网络抖动大，往往是发生了拥塞，包在路由中的排队延时随着拥塞程度呈现波动变化。

丢包高，往往和网络模型相关。

弱网网络模型

$$弱网网络模型\{\begin{array}{l}带宽受限型\begin{array}{l}固定带宽\\ 拥塞\end{array}\\ 信道差错型\{\begin{array}{l}wifi\\ 移动网络\\ 设置主动丢包策略网络\end{array}\end{array}$$

带宽受限型网络

这种网络的丢包率会随着网络过载的严重度增长。越是过载，丢包越严重。

$$对策\{\begin{array}{l}simulcast\\ svc\\ buffer\end{array}$$

信道差错型网络

在带宽允许范围内，这种网络的丢包率是信道的一个属性，与网络流量无关。

$$对策\{\begin{array}{l}nack\\ fec\\ buffer\end{array}$$

WebRTC视频接收处理流程

Why Fec？

Nack的特点

当接收端检测到丢包，他会向发送端发出nack，请求重传丢失的数据包。这就意味着nack对rtt十分敏感。在rtt较大的情况下，nack能起到的作用与jitter buffer的策略息息相关，最差的情况下，nack的作用微乎其微。

Jitter buffer

class FrameBuffer
    VCMJitterEstimator* const jitter_estimator_ ;
    std::map<VideoLayerFrameId, FrameInfo> frames_;
    int num_frames_history_
    int num_frames_buffered_    
    FrameMap::iterator last_decoded_frame_it_;
    FrameMap::iterator last_continuous_frame_it_;
;
/*
num_frames_history_:
Decoded frame holes[without video frame] that remains in frames_ that can be used as a reference by incoming frames to know whether they can be decoded [e.g.:their dependencies can be found in frames_].

num_frames_buffered_:
Holes in frames_ that have a video frame reside in.
*/

InsertFrame:
NextFrame:

在webrtc中，jitter buffer攒齐一个可以解码的帧之后，会将其送去渲染，它会等待一个std::max(jitter delay, av sync delay)，然后被解码显示。解码之后的帧的序列号会反馈到数据包的接收模块，接收模块接着就会清除jitter buffer中的"old stuff"。所以，如果rtt很大，nack反馈触发的重传会大量的失效，因为默认情况下，jitter buffer耐不住性子等待重传的包，所以你就看到了卡顿和跳帧。

从这里可以知道，如果不改变接收端jitter buffer的策略，单独改变发送端的缓存队列大小是起不到多大作用的，一般保证100ms的队列大小就行了。如果网络的jitter较大，可以适当的增大发动端的缓存队列大小。

拥塞控制

webrtc的拥塞控制算法基于GCC，它的特点是带宽估计由两个大的算法模块组成:

$$GCC\begin{array}{l}delay-based\\ loss-based\end{array}$$

一个基于延迟模型，一个基于丢包模型，然后取一个最小的估算值。

这么看来，GCC算法对信道差错型网络很不友好，总是给它一个过低的带宽估计值。

FEC

上面提到的nack和gcc的问题，我们发现FEC可以很好的解决。

FEC，即前向纠错编码，利用亦或(xor)运算获得，可以调节冗余度和mask来应对不同程度以及不同模型的丢包[主要是随机丢包和突发的连续丢包]。

1. 如果rtt很大，jitter buffer又不愿意等待，那就只好给接收端发送FEC包，让他自己实时的去恢复。
2. FEC能够帮助GCC评估网络模型，如果是信道差错型网络，FEC能够有效地降低丢包反馈，若不是信道差错型网络，FEC能起到的作用微乎其微，甚至是负面的，从而使得GCC的带宽评估更加鲁邦。

Buffer？

我们总是能够通过增大buffer来极大地改善卡顿情况，但它会带来延迟。可以考虑在不同的场景下使用它:
$$场景\begin{array}{ll}连麦互动& \text{低延迟，默认jitter buffer算法}\\ 无互动观看& \text{修改默认jitter buffer算法，适当地增大buffer}\end{array}$$

实验

点我