webrtc QoS -服务质量总结

什么是QOS

QoS（Quality of Service，服务质量）指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力，是网络的一种安全机制， 是用来解决网络延迟和阻塞等问题的一种技术。QoS的保证对于容量有限的网络来说是十分重要的，特别是对于流多媒体应用，例如VoIP和IPTV等，因为这些应用常常需要固定的传输率，对延时也比较敏感。

webrtc 的QoS 的方法

NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）、AVSync（音视频同步）、动态分辨率调整。

核心的思想主要有几类

• 冗余：FEC
• 丢包重传： NACK
• 快速恢复：IDR 请求
• 拥塞控制：降码率、降帧率、降低分辨率等措施就是为了减少数据报从而减少丢包。平滑发送数据报，避免突发性数量导致拥塞。
• 显示体验：JitterBuffer、音视频同步

1、 NACK

Negative Acknowlegment Packet， 否定确认包，N - ACK。

• ack 是如果收到数据，发送确认包
• NACK ，没有收到数据，通知对方没有收到

如果是ack ，一般采用的策略是超时重传，或者快重传。是tcp 常用的机制，但是同时带来的问题就是实时性，和大量的ack 报文增加了网络拥塞。NACK 是可以解决上面的2个问题。

在webrtc 中是使用 rtcp 作为通知。2种的重传类型

1）RTPFB：rtp报文丢失重传。

2）PSFB：指定净荷重传，指定净荷重传里面又分如下三种：

• 1、PLI (Picture Loss Indication) 视频帧丢失重传。
• 2、SLI (Slice Loss Indication) slice丢失重转。
• 3、RPSI (Reference Picture Selection Indication)参考帧丢失重传。

2、FEC

前向纠错 Forward Error Correction，简称FEC
通过增加冗余的方式，避免在丢包的情况，可以通过剩余的数据恢复出原理的数据，这样就可以减少网络重传。

1、RED就是RFC2198冗余。将前面的报文直接打入到新包里面，在接收端解析主包和冗余包。

2、ULPFEC，目前webrtc仅将SVC编码的Level 0视频帧打包成FEC。其余层有丢包，就逐步将帧率，保证视频相对流畅。用到的协议是：RFC5109。

3、FLEXFEC较ULPFEC，增加纵向OXR运算。增加网络抗丢包能力。

3、SVC

SVC（可适性视频编码或可分级视频编码）是传统H.264/MPEG-4 AVC编码的延伸，可提升更大的编码弹性，并具有时间可适性（Temporal Scalability）、空间可适性（Spatial Scalability）及质量可适性（SNR/Quality/Fidelity scalability）三大特性，使视频传输更能适应在异质的网络带宽。

4、JitterBuffer

Jitter指的是数据一会儿快、一会儿慢，很不稳定。如果不加处理的话，你看到的视频效果就是一会儿快播了、一会儿又慢动作，给人一种眩晕的感觉，时间长了会非常难受。不过对于 WebRTC 来讲，它通过内部的 JitterBuffer（可以简单地理解为一块缓冲区）就能很好地解决该问题。

5、IDR 请求

关键帧也叫做即时刷新帧，简称IDR帧。对视频来说，IDR帧的解码无需参考之前的帧，因此在丢包严重时可以通过发送关键帧请求进行画面的恢复。关键帧的请求方式分为三种：

• RTCP FIR反馈（Full intra frame request）、
• RTCP PLI 反馈（Picture Loss Indictor）
• SIP Info消息，具体使用哪种可通过协商确定。

6、PACER

PACER，是网络报文平滑策略。一个视频帧有可能分别封装在几个RTP报文，若这个视频帧的RTP报文一起发送到网络上，必然会导致网络瞬间拥塞。以25fps为例，若这帧视频的RTP报文，能够在40ms之内发送给接收端，接收端既可以正常工作，也缓冲了网络拥塞的压力。PACER就是实现把RTP同一时刻生产的若干包，周期性的发送，防止上行流量激增导致拥塞。

7、Sender Side BWE或REMB（Receiver Estimated Maximum Bitrate）

根据丢包率，降低发送端码率， 这种情况是增加压缩比qp 等参数，主要修改的编码器的参数。

这个算法的思路是根据接收端的丢包率或延时情况维护一个状态机。以根据丢包率为例，在判断为overuse时，就根据一定的系数减少当前发送端的码率值，当判断为underuse时又根据增加系数来增加发送端的码率值；然后将这个值通过rtcp包发送给发送端，发送端根据该值来动态的调整码率。

8、动态帧率调整策略

降低码率的方法，除了降低码率，还是降低帧率。

视频发送端根据Sender Side BWE或REMB等参数调整出一组比较合适的码率值，当网络条件好的时候，码率值会比较大，当网络条件比较差的时候，码率值会比较低。但是若是发送端仅调整码率，不调整帧率，当网络条件比较好的时候，仅仅提升了视频质量，没有充分利用网络条件，提升实时性。当网络条件比较差的时候，码率降的比较低，若不降低帧率，视频质量会大幅度下降。所以需要增加一种机制，根据发送端的码率值，动态调整发送端的帧率值。

9、动态帧率调整策略

如果上方2个方法都没有办法的情况下，可以考虑降低分辨率。目前webrtc 还在测试阶段。

动态分辨率调整策略设计思想是，在网络传输质量变差、CPU占有率过高，编码器编码质量QP值过大等情况下，动态降低视频传输分辨率，缓解当前异常。反之则动态增加分辨率，提供高质量的视频传输。目前webrtc这块还处于调测阶段。实现核心函数是：

10、AVSync音视频同步

解决音视频同步

由于音视频处理的系统路径不同，并且音视频媒体流是分开以RTP over UDP报文形式传输，UDP报文对网络丢包延时敏感，若不进行特殊平滑处理，会导致实际播放时音视频的渲染相对延时与采集延时有偏差，这样就容易产生音视频不同步现象。音视频同步的基本思想是，以RTCP报文的NTP时间为参考，在接收端渲染前，对音视频分别进行不同长度的适当缓冲，尽量保证音视频渲染different time = 音视频采集different time。保证音视频同步。