github:https://github.com/bigonelby/webrtcUml/tree/master/latest
这张图继续介绍pacing,即pacing发送包的过程
前面已经介绍编码后的数据,最终打包成rtp包后,缓存在RoundRobinPacketQueue中,这里介绍一下从缓存中提取包并发送的过程
发送的时机是由PacedSender这个模块决定的,PacedSender本身继承自Module,因此其主要工作在周期性的Process中,在这个Process里,主要调用了PacingController的ProcessPackets方法。这个方法从RoundRobinPacketQueue中拿到优先级最高的packet,即GetPendingPacket方法,然后交由PacketSender将其发送
PacketSender是一个接口,实现这个接口的,是PacketRouter,PacketRouter中通过AddSendRtpModuleToMap方法注册rtp模块,因此管理了send_modules_map_,map的key值为ssrc。PacketRouter的起名也是符合自身的功能,是packet的router路由器,因此作用就是将每个packet路由给相应的RtpModule
PacketRouter根据packet的ssrc,找到对应的RtpRtcpInterface,交由这个RtpRtcpInterface继续完成发送packet的任务。实现这个interface的,就是ModuleRtpRtcpImpl2了。每个ModuleRtpRtcpImpl2,又有成员RtpSenderContext,记录发送的context。其中成员packet_sender专门负责发送,即RtpSenderEgress
RtpSenderEgress的SendPacket方法,会进一步调用SendPacketToNetwork方法将包发送到网络。真正执行这个发送操作的,是Transport接口。实现这个接口的,是WebrtcVideoChannel,于是最终的发送是由WebrtcVideoChannel完成的。这个角色隐藏的很深,通过webrtc::VideoSendStream::Config进行包装,这是一个比较上层的结构体,最终赋值给底层的结构体Configuration作为RtpRtcpInterface的参数,这个参数最终传到了RtpSenderEgress层,这就是为何这么底层的结构体还能持有WebrtcVideoChannel的原因。之前讨论过,后面的数据从WebrtcVideoChannel,进一步传递给VideoChannel这个BaseChannel并最终由rtptransport发送出去,这里不做更多介绍
RtpSenderEgress中的一些统计数据,会经由若干Observer返回给统计模块,绝大部分Observer都是SendStatisticsProxy,因此SendStatisticsProxy可以拿到需要的数据,并最终整理上报,具体上报的过程前面业已讨论过
最后,PacedSender和PacketRouter均由RtpTransportControllerSendInterface创建,可见这个类的重要性