Android IOS WebRTC 音视频开发总结（五七）-- 网络传输上的一种QoS方案

本文主要介绍一种QoS的解决方案，文章来自博客园RTC.Blacker，欢迎关注微信公众号blacker，更多详见www.rtc.help

QoS出现的背景：

而当网络发生拥塞的时候，所有的数据流都有可能被丢弃；为满足用户对不同应用不同服务质量的要求，就需要网络能根据用户的要求分配和调度资源，对不同的数据流提供不同的服务质量：

1、对实时性强且重要的数据报文优先处理；

2、对于实时性不强的普通数据报文，提供较低的处理优先级，网络拥塞时甚至丢弃。

为了满足上述需求，QoS出现了，定义如下：

QoS（Quality of Service）指一个网络能够利用各种基础技术，为指定的网络通讯提供更好的服务能力, 是网络的一种安全机制， 是用来解决网络延迟和阻塞等问题的一种技术。所以当网络过载或拥塞时，QoS 能确保重要业务量不受延迟或丢弃，同时保证网络的高效运行。

支持QoS功能的设备，能够提供传输品质服务；针对某种类别的数据流，可以为它赋予某个级别的传输优先级，来标识它的相对重要性，并使用设备所提供的各种优先级转发策略、拥塞避免等机制为这些数据流提供特殊的传输服务。配置了QoS的网络环境，增加了网络性能的可预知性，并能够有效地分配网络带宽，更加合理地利用网络资源。

在RTC开发中我们了解到实际网络状况非常复杂，如果需要保证通话必须先保证通讯质量，而实时音视频通讯包括采集、编码、网络传输、解码、播放等环节，其中采集、编解码和播放是不受网络条件影响的，只受限于编解码算法和播放策略等因素。但网络传输的丢包、抖动和乱序对qos的影响最为重大，因此下面介绍的qos解决方案要解决的是网络传输丢包、抖动和乱序因素对服务质量的不好影响，具体如下：

1、发送端原理：

对于实时音视频通讯，常采用UDP协议来传输多媒体数据，下面是采用基于udp的rtp协议来传输音视频数据。对于不同格式的编码数据，会有不同的rtp打包协议，比如对于H.264视频数据，文档rfc3984对NAL U的rtp打包封装进行了规范，详情请参考该文档。对于视频数据的打包封装，因为一帧视频数据的数据长度可能大于MTU，所以相关的打包协议都会规定将长度大于MTU的帧进行切割，分块封装到多个rtp包进行传输。为了避免丢包、抖动和乱序对服务质量的影响，本方案在发送端和接收端各建立了节点数相等的一段循环buffer，用于缓存发送端数据和接收端数据。

发送端在发送数据的时候，某个rtp包的seq为send_seq，发送端把这个包通过udp socket发送出去的同时，把这

个rtp包的数据拷贝到send_seq对应节点的buffer中去，以便这个rtp包接收方没收到时，发送方还能重发这个rtp包。

这里要注意的一点是，发送端和接收端的循环buffer节点数要能被65536整除，这样rtp seq增加到最大值65535时对应

最后一个节点，下一个rtp包的seq为0正好对应上第一个节点，避免rtp seq掉头时出现漏洞。

2、接收端原理：

和发送端类似，接收端也开辟了一段节点数能被65536整除的循环buffer，用于缓存接收到的rtp包。接收端收到rtp

包时，需要去解析rtp包头，取出接收到的rtp包的seq，对应下图中的received_seq。

当收到第一个包时，start_seq和end_seq都被设置为received_seq，并把收到的rtp包送到解码单元。后面收到rtp包时，有做两件事情：

第一、接收的模块将接收到的rtp包拷贝到received_seq指向的节点的buffer，并将这个节点的数据flag（用于标记该节点是否填充了数据）设置为true，同时要根据start_seq、end_seq和received_seq的关系来决定要不要将end_seq更新为received_seq的值，如果received_seq对应的包本来应该end_seq对应的包之前到达，则不更新end_seq的值，否则就更新。

第二、要每过一段时间都要去扫描start_seq到end_seq对应的每个节点，首先，若当前时间和start_seq对应的数据到达时间的差值超过一定阈值（比如500ms），则将start_seq和end_seq之间的每个节点的数据全部丢弃，将每个节点的数据flag设置为false，更新start_seq为end_seq。其次，若start_seq对应的节点的下一个节点的数据falg为true，则将该节点的数据送到解码单元，同时将start_seq更新为该节点的seq，并将该节点的数据flag设置为false；若flag为false，且当前时间和start_seq对应的数据到达时间的差值超过一定阈值（比如50ms），则将该节点的seq（lost_seq）发送给发送端，请求发送端将seq对应的rtp数据再发一遍。

这样，当有些包很久（大于500ms）都没收到，就认为它来不了，直接将它们丢弃；有些包短时间（小于50ms）没来，则向发送端发送重传请求，请求发送端再发一次该包，试图能补上这些包。

3、结果说明

3.1、没加qos模块时，两个手机视频通信在有丢包情况下回出现视频帧不完整，播放出现马赛克的现象，加上qos模块后，视频播放流畅，效果大为改善。同时我们为了测试该方案的作用，在发送端人为地分别丢弃10%和20%的视频rtp包，接收端解码播放效果良好，没有出现马赛克现象。

3.2、加入qos模块会带来一定的延迟和卡顿，因为丢包重传是需要时间的。

3.3、上述方案也就是webrtc里面的nack的具体实现方式。

上述方案由环信资深音视频技术专家彭祖元提供（部分内容有调整），kelly进行编辑和整理。

彭老师拥有多年音视频编解码开发经验，在Android,iOS等平台音视频采集，编码，传输，解码，播放等方面有着丰富的经验，熟悉流媒体服务器开发。