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创建,可见这个类的重要性

©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

友情链接更多精彩内容