实时网络音视频通讯qos的一种解决方案
一、前言
随着移动互联网的快速发展以及智能终端性能的逐步提高，智能终端间进行实时音视频通讯成为未来移动互联网
发展的一个重要方向。那么如何保证智能终端之间实时音视频通讯的服务质量成为一个必须加以重视的问题。实时音视频通讯包括采集、编码、网络传输、解码、播放等环节，其中采集、编解码和播放是不受网络条件影响的，只受限于编解码算法，播放策略等因素，网络传输的丢包、抖动和乱序对qos的影响最为重大，因此本文介绍的qos解决方案
要解决的是网络传输丢包、抖动和乱序因素对服务质量的不好影响。
二、发送端
对于实时音视频通讯，常采用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掉头时出现漏洞。
三、接收端
和发送端类似，接收端也开辟了一段节点数能被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）没来，则向发送端发送重传请求，请求发送端再发一次该包，试图能补上这些包。
四、结果分析
没加qos模块时，两个手机视频通信在有丢包情况下回出现视频帧不完整，播放出现马赛克的现象，加上qos模块后，视频播放流畅，效果大为改善。同时我们为了测试该方案的作用，在发送端人为地分别丢弃10%和20%的视频rtp包，接收端解码播放效果良好，没有出现马赛克现象。
作者介绍：
彭祖元，环信资深音视频技术专家。拥有多年音视频编解码开发经验，在Android,iOS等平台音视频采集，编码，传输，解码，播放等方面有着丰富的经验，熟悉流媒体服务器开发。
随着移动互联网的快速发展以及智能终端性能的逐步提高，智能终端间进行实时音视频通讯成为未来移动互联网
发展的一个重要方向。那么如何保证智能终端之间实时音视频通讯的服务质量成为一个必须加以重视的问题。实时音视频通讯包括采集、编码、网络传输、解码、播放等环节，其中采集、编解码和播放是不受网络条件影响的，只受限于编解码算法，播放策略等因素，网络传输的丢包、抖动和乱序对qos的影响最为重大，因此本文介绍的qos解决方案
要解决的是网络传输丢包、抖动和乱序因素对服务质量的不好影响。
二、发送端
对于实时音视频通讯，常采用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掉头时出现漏洞。
三、接收端
和发送端类似，接收端也开辟了一段节点数能被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）没来，则向发送端发送重传请求，请求发送端再发一次该包，试图能补上这些包。
四、结果分析
没加qos模块时，两个手机视频通信在有丢包情况下回出现视频帧不完整，播放出现马赛克的现象，加上qos模块后，视频播放流畅，效果大为改善。同时我们为了测试该方案的作用，在发送端人为地分别丢弃10%和20%的视频rtp包，接收端解码播放效果良好，没有出现马赛克现象。
作者介绍：
彭祖元，环信资深音视频技术专家。拥有多年音视频编解码开发经验，在Android,iOS等平台音视频采集，编码，传输，解码，播放等方面有着丰富的经验，熟悉流媒体服务器开发。
