github：https://github.com/bigonelby/webrtcUml/tree/master/latest
这张图的内容比较多，主要涉及了：① 视频通道建立；② 传输通道建立；③ VideoRtpSender；④ 核心三剑客；⑤ pipeline下游encoder；⑥ pipeline上游track；⑦ pipline应用层
首先看看视频通道建立。也就是VideoChannel的创建。之前的图中已经知道，webrtc中的各种channel，最核心的是BaseChannel，每个BaseChannel都有一个MediaChannel。这里谈论的就是BaseChannel的创建。创建的时机实际上就是sdp协商时，对端回送answer后，本端会将answer通过SetRemoteDescription设置给webrtc底层。在这个函数中，实际上完成了很多架构上的初始化。这种offer / answer的处理，PeerConnection有个重要的助手专门处理这个事情，这个助手就是SdpOfferAnswerHandler，即会调用这个类的SetRemoteDescription进行进一步的处理。在解析sdp的过程中，如果发现有新的通道，则会通过ChannelManager进行通道的创建，即CreateVideoChannel
再来看看传输通道的建立。刚才介绍了，已经将VideoChannel创建出来了，这就意味着与之相关的MediaChannel自然也已经创建起来了。那么数据将如何传输到网络呢？就是调用VideoChannel的SetRtpTransport，从而设置发送到网络的rtptransport了。底层将采集数据编码，打包，发送时，最终调用到WebrtcVideoChannel的SendRtp和SendRtcp两个方法。这两个方法进一步调用了network_interface_的SendPacket方法。network_interface_是如何注册到VideoMediaChannel中的呢？就是用的接口SetInterface。由此可见，如果我们希望替换成自定义的transport，那么只要通过SetInterface，设置成自定义的network_interface_即可。对于原生的webrtc，实现这个接口的正是BaseChannel，因此会进一步调用BaseChannel的方法，从而通过其成员rtp_transport_进行进一步的发送，即SendRtcpPacket或SendRtpPacket。这里的rtp_transport_就是通过SetRtpTransport设置的。下面我们来看看这个rtp_transport_。这个transport实际上可以通过JsepTransport得到。关于jsep（JavaScript Session Establishment Protoco）的介绍，可以参考这篇文章：https://rtcweb-wg.github.io/jsep/。webrtc中的JsepTransport，是由控制类JsepTransportController创建的。这个transport_controller_是PeerConnection的另一名干将。其JsepTransport创建的时机，也是处理offer或answer的时候。在ApplyDescription_n的时候，会调用MaybeCreateJsepTransport，从而创建了JsepTransport
再进一步向后分析之前，我们必须再熟悉一下三剑客：即VideoMediaChannel，WebrtcVideoChannel和VideoChannel。实际上VideoChannel是一个BaseChannel，每个BaseChannel都有一个MediaChannel，实现这个MediaChannel接口的，为VideoMediaChannel，WebrtcVideoChannel实现了VideoMediaChannel的接口。因此可以理解为VideoChannel有一个成员是WebrtcVideoChannel。为什么是MediaChannel呢？即媒体通道，显然这个通道和媒体相关，因此其职责就是接收采集的数据，进行编码，打包，最后通过网络层发送。如何通过网络层发送，上面已经介绍了，最终通过rtp_transport_。下面我们看看采集数据是如何流入到这个MediaChannel中的。
到这里就需要介绍一下VideoRtpSender了。这个类是连接采集数据和媒体通道的关键。不过，这个对象也不是独立存在的，类似的，还有VideoRtpReceiver，这两个组员统一归RtpTransceiver管理，而管理RtpTransceiver的，自然也是一个Manager，就是RtpTransmissionManager，这又是PeerConnection的得力助手。应用可以通过AddTransceiver增加新的transceiver。PeerConnection的这个方法接收一个MediaStreamTrackInterface，这是一个mediastreamtrack，这个track非常重要，实际上这个track就是数据的源头，比如track里可以包含一个camera的采集数据。注意到MediaStreamTrackInterface本身并不是一个source，但是通过其方法kind()就可以知道他的具体类型了。比如视频，那么他的多态子类就是VideoTrackInterface，这个VideoTrackInterface可是一个地地道道的VideoSourceInterface，也就是说这个track的本质就是一个source。这个对后面数据流pipeline的理解非常重要。好了，我们回过头来继续看PeerConnection的AddTransceiver，看看究竟做了什么事情。具体的工作由rtp_manager_完成，即RtpTransmissionManager完成。首先CreateSender，CreateReceiver，接着就可以CreateAndAddTransceiver。由此可见，VideoRtpSender实际上是由RTPTransmissionManager创建的。VideoRtpSender重要意义在于，他起到了承上启下的作用。左手边是数据源，即MediaStreamTrackInterface，通过SetTrack方法绑定；右手边是MediaChannel，通过SetMediaChannel绑定。最后通过调用WebrtcVideoChannel的SetVideoSend方法，将数据源(video track)和媒体通道(media channel)绑定到一起。
至此，我们重要可以看看数据流的整个pipeline了。首先看看pipeline下游encoder，通过WebrtcVideoChannel的SetVideoSend方法设置，这个方法实际上传入了一个VideoSourceInterface。我们已经知道，这个VideoSourceInterface实际上就是VideoTrack了，后面再详细介绍。WebrtcVideoChannel进一步通过WebRtcVideoSendStream的SetVideoSend方法，将此VideoSourceInterface设置到底层，这个指令，通过VideoSendStream，VideoStreamEncoder，最终到达了VideoSourceSinkController的SetSource。这个VideoSourceSinkController，顾名思义，是source和sink的控制器。因此管理了source和sink，并将source和sink相互绑定，数据流将会从source中流入到sink。对于VideoSourceSInkController而言，其sink_就是VideoStreamEncoder。而source就是通过SetSource接口设置下来的，即VideoTrack。这样，通过VideoSOurceSinkController的牵线，VideoTrack中的采集数据，就流到了编码器中，从而进行进一步的编码。
我们再看看pipeline的上游track。之前已经反复介绍了，传入到WebrtcVideoChannel的source，本质上就是VideoTrack。这个VideoTrack是通过PeerConnection的AddTransceiver方法设置进来的，并由VideoRtpSender设置到WebrtcVideoChannel中。上层传入的实际上是MediaStreamTrackInterface，其本身并不是VideoSourceInterface。但是根据其kind，可以判断出具体的类型，比如video，那么我们就知道这个子类就是VideoTrackInterface，而这个就是一个VideoSourceInterface了。我们看看图中有各种各样的VideoSourceInterface。实际上简单而言，就是三个对象，即VideoTrack，和其成员AdaptedVideoTrackSource，以及VideoBroadcaster。设置到底层的是VideoTrack，VideoTrack在进行sink绑定即AddOrUpdateSink时，也会通知其成员video_source_进行相应的sink更新，具体而言，子类就是AdaptedVideoTrackSource，而AdaptedVideoTrackSource也会将次重要事情告诉其成员broadcaster_，这是一个VideoBroadcaster，因此VideoStreamEncoder相当于最终绑定到了这个VideoBroadcaster的sinks_下。因此采集到的，并流入到AdaptedVideoTrackSource视频数据，就会通过VideoBroadcaster流入到编码器VideoStreamEncoder中，从而进行编码了
最后看看pipline应用层。上层RTCVideoSource实现了RTCVideoCapturerDelegate，采集的视频帧将会通过这个delegate，源源不断的流入到RTCVideoSource中，RTCVideoSource进一步将数据送给了底层类ObjCVideoTrackSource，通过其OnCapturedFrame方法，将视频帧送入。而ObjVideoTrackSource其本质就是一个AdaptedVideoTrackSource，因此，可以进一步通过VideoAdapter将采集的视频帧进行adapter，并将adapter后的帧通过OnFrame进一步处理，这个视频帧由此进入到VideoBroadcaster中，并最终流入到VideoStreamEncoder
