webrtc发送端-pacing发送

github：https://github.com/bigonelby/webrtcUml/tree/master/latest

webrtc-new-发送端-pacing发送.drawio.png

1. 这张图继续介绍pacing，即pacing发送包的过程

2. 前面已经介绍编码后的数据，最终打包成rtp包后，缓存在RoundRobinPacketQueue中，这里介绍一下从缓存中提取包并发送的过程

3. 发送的时机是由PacedSender这个模块决定的，PacedSender本身继承自Module，因此其主要工作在周期性的Process中，在这个Process里，主要调用了PacingController的ProcessPackets方法。这个方法从RoundRobinPacketQueue中拿到优先级最高的packet，即GetPendingPacket方法，然后交由PacketSender将其发送

4. PacketSender是一个接口，实现这个接口的，是PacketRouter，PacketRouter中通过AddSendRtpModuleToMap方法注册rtp模块，因此管理了send_modules_map_，map的key值为ssrc。PacketRouter的起名也是符合自身的功能，是packet的router路由器，因此作用就是将每个packet路由给相应的RtpModule

5. PacketRouter根据packet的ssrc，找到对应的RtpRtcpInterface，交由这个RtpRtcpInterface继续完成发送packet的任务。实现这个interface的，就是ModuleRtpRtcpImpl2了。每个ModuleRtpRtcpImpl2，又有成员RtpSenderContext，记录发送的context。其中成员packet_sender专门负责发送，即RtpSenderEgress

6. RtpSenderEgress的SendPacket方法，会进一步调用SendPacketToNetwork方法将包发送到网络。真正执行这个发送操作的，是Transport接口。实现这个接口的，是WebrtcVideoChannel，于是最终的发送是由WebrtcVideoChannel完成的。这个角色隐藏的很深，通过webrtc::VideoSendStream::Config进行包装，这是一个比较上层的结构体，最终赋值给底层的结构体Configuration作为RtpRtcpInterface的参数，这个参数最终传到了RtpSenderEgress层，这就是为何这么底层的结构体还能持有WebrtcVideoChannel的原因。之前讨论过，后面的数据从WebrtcVideoChannel，进一步传递给VideoChannel这个BaseChannel并最终由rtptransport发送出去，这里不做更多介绍

7. RtpSenderEgress中的一些统计数据，会经由若干Observer返回给统计模块，绝大部分Observer都是SendStatisticsProxy，因此SendStatisticsProxy可以拿到需要的数据，并最终整理上报，具体上报的过程前面业已讨论过

8. 最后，PacedSender和PacketRouter均由RtpTransportControllerSendInterface创建，可见这个类的重要性