webrtc 的 PacedSender 模块

1.模块结构图

2.模块输入输出

2.1模块输入

（1）目标码率
平滑发送模块通过外部设置的目标码率，来决定数据包发送的速度，一般在网络条件发生改变的情况下会更新设置的码率。

（2）数据包
编码模块在完成编码后会将视频帧数据传递到 rtp_rtcp 模块的 RtpSenderVideo 中进行数据包组装，然后传递到 pacing 模块进行平滑发送处理。

2.2模块输出

pacing 模块的输出同样是数据包，只是在 pacing 模块对发送速度进行了控制。

3.模块处理过程

3.1模块做了什么处理

将数据包存入缓冲队列中，根据目标码率计算发送预算，如果在 5ms 周期内可以进行发送处理，就发送数据包，同时将数据包存入 RtpPacketHistory 中。

3.2 数据包缓存过程

数据包缓存过程从 RtpSenderVideo 开始，因为在此之前还没有产生数据包，编码后的视频帧还是原始未组包的压缩视频数据。
在 webrtc 中，平滑发送是否开启是可选的，如果不开启平滑发送，那么数据包会到达 NonPacedPacketSender 然后直接通过网络发送出去，否则会发送到 PacedSender 被缓存起来，根据设置的目标码率进行发送。

3.3数据包周期处理过程

数据包周期处理过程主要涉及两个类，分别是 PacedSender 和 PacingController，PacedSender 是一个 Module 的子类，因此可以实现周期处理。

这里重点分析周期模式下媒体数据包的发送过程，对于填充包和动态模式暂时不考虑。

PacingController 有两种数据包处理模式，一种是周期模式，一种是动态模式，周期模式下根据发送预算按照 5ms 间隔处理数据包，动态模式下根据数据包发送债务来决定需要等待多久再进行下一次发送。（发送债务是指当前进行一次 m 字节的数据发送后，就增加了 m 字节的债务，目标发送码率为 v，那么需要等待的时间为 m/v，之后才可以进行下一次发送。）

在 PacedSender::TimeUntilNextProcess () 函数中，如果是周期发送模式，那么就会在 5ms 后进行下一次数据包发送处理。

在 PacedSender::Process() 函数中，会调用 PacingController::ProcessPackets() 函数进行具体的数据包处理。

在 PacingController 中有一个 drain_large_queues_ 变量，从字面上来理解是将大的队列排空，也就是迅速将队列中的数据包发送出去。如果这个变量为真，那么就会根据队列中的数据量和发送时间限制，计算一个发送码率，如果这个计算结果大于根据拥塞控制设置的码率，就用这个较大的码率来指导后续数据包发送过程。

在周期模式下，当进入 PacingController::ProcessPackets() 时会调用 PacingController::UpdateTimeAndGetElapsed() 函数，更新 last_process_time_ 值为 now，也就是当前时间，并返回两次调用的时间间隔 elapsed_time，这个值用于更新周期模式下的发送预算，在周期发送模式下，只有发送预算 bytes_remaining_ 为正值，才能发送数据包。

PacingController::GetPendingPacket() 函数用于从缓存队列里获取数据包，如果 media_budget_ 的 bytes_remaining_ 大于零，就可以拿到一个有效数据包，否则拿到一个空指针，如果拿到有效数据包就可以调用发送接口进行发送处理，发送完成后就再次判断发送预算和取数据包发送，直到发送预算耗尽。如果因为发送预算耗尽，无法拿到数据包发送就可以退出循环了，等待下一次 PacingController::ProcessPackets() 被调用。

3.4数据包发送过程

数据包从平滑发送模块的缓存中发送，起点是 PacingController::ProcessPackets()，在这个函数中调用 PacedSender::SendRtpPacket() 函数进行发送，用类图来描述发送过程如下：
数据包发送过程基本按照类图从左到右发送，数据包传到 RtpSenderEgress 时，一方面发送到网络，一方面对数据包做缓存，以备响应 nack 模块的重传请求。

4.小结

平滑发送模块在 webrtc 众多模块中相对比较简单，没有很复杂的算法，理解起来相对比较容易，不过还是有些细节需要仔细揣摩其实现意图。