webrtc发送端-采集和encoder建连

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

webrtc-发送端-采集和encoder建连.drawio.png
  1. 这张图的内容比较多,主要涉及了:① 视频通道建立;② 传输通道建立;③ VideoRtpSender;④ 核心三剑客;⑤ pipeline下游encoder;⑥ pipeline上游track;⑦ pipline应用层

  2. 首先看看视频通道建立。也就是VideoChannel的创建。之前的图中已经知道,webrtc中的各种channel,最核心的是BaseChannel,每个BaseChannel都有一个MediaChannel。这里谈论的就是BaseChannel的创建。创建的时机实际上就是sdp协商时,对端回送answer后,本端会将answer通过SetRemoteDescription设置给webrtc底层。在这个函数中,实际上完成了很多架构上的初始化。这种offer / answer的处理,PeerConnection有个重要的助手专门处理这个事情,这个助手就是SdpOfferAnswerHandler,即会调用这个类的SetRemoteDescription进行进一步的处理。在解析sdp的过程中,如果发现有新的通道,则会通过ChannelManager进行通道的创建,即CreateVideoChannel

  3. 再来看看传输通道的建立。刚才介绍了,已经将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

  4. 再进一步向后分析之前,我们必须再熟悉一下三剑客:即VideoMediaChannel,WebrtcVideoChannel和VideoChannel。实际上VideoChannel是一个BaseChannel,每个BaseChannel都有一个MediaChannel,实现这个MediaChannel接口的,为VideoMediaChannel,WebrtcVideoChannel实现了VideoMediaChannel的接口。因此可以理解为VideoChannel有一个成员是WebrtcVideoChannel。为什么是MediaChannel呢?即媒体通道,显然这个通道和媒体相关,因此其职责就是接收采集的数据,进行编码,打包,最后通过网络层发送。如何通过网络层发送,上面已经介绍了,最终通过rtp_transport_。下面我们看看采集数据是如何流入到这个MediaChannel中的。

  5. 到这里就需要介绍一下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)绑定到一起。

  6. 至此,我们重要可以看看数据流的整个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中的采集数据,就流到了编码器中,从而进行进一步的编码。

  7. 我们再看看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中,从而进行编码了

  8. 最后看看pipline应用层。上层RTCVideoSource实现了RTCVideoCapturerDelegate,采集的视频帧将会通过这个delegate,源源不断的流入到RTCVideoSource中,RTCVideoSource进一步将数据送给了底层类ObjCVideoTrackSource,通过其OnCapturedFrame方法,将视频帧送入。而ObjVideoTrackSource其本质就是一个AdaptedVideoTrackSource,因此,可以进一步通过VideoAdapter将采集的视频帧进行adapter,并将adapter后的帧通过OnFrame进一步处理,这个视频帧由此进入到VideoBroadcaster中,并最终流入到VideoStreamEncoder

你可能感兴趣的:(webrtc发送端-采集和encoder建连)