webrtc QOS方法十（pacer实现）

1、背景介绍

若仅仅发送音频数据，不需要PACER模块：

1）一帧音频数据本身不大，不会超过以太网的最大报文长度。一个RTP报文可以搞定，按照打包时长的节奏发送就可以。但视频数据不能按照音频数据的思路发送，一帧视频可能很大，远大于以太网的1500byte，需要分别封装在几个RTP报文中，若这些视频帧RTP报文一起发送到网络上，必然会导致网络瞬间拥塞。产生丢包抖动等异常。

2）大多数编解码格式下，一帧音频数据长度固定，音频码率持续平稳。码率不会出现忽高忽低现象。但是一帧视频数据长度受内容影响严重。I、P、B帧间的长度相差非常大。直接发送网络波动幅度很大。尤其是WIFI环境下，受限WIFI的调度机制，媒体数据能否平稳发送，对弱网的WiFi环境对通话质量影响很大。

PACER的目的就是让视频数据按照评估码率均匀的在各个时间片发送出去。如下图所示：

2、实现原理

2.1 设计PACER模块主要解决三个问题

2.1.1 怎么发

音频，视频、NACK、FEC，PADDING报文都要统一从PACER模块发送。若不区分报文优先级，势必会对系统延时产生很大的影响。

所以音视频数据编码和RTP切分打包后，首先将RTP报文存在pace queue队列，并将报文元数据(packet id, size, timestamp, 重传标示)送到pacer queue进行排队等待发送，插入队列的元数据会进行优先级排序。

pace queue是一个基于优先级排序的多维链表，它并不是一个先进先出的fifo,而是一个按优先级排序的list。报文优先级规则是：