奔向火星的博客

PeerConnection

我们看下Call里面的两个成员module_process_thread_和 pacer_thread_，从名字可看出他们是跟线程运行有关的，具体看下他们的类图： 实际上，当我们要运行一个任务时，会将它打包成一个Module, 然后放到一个新的线程里面去运行，我们先来看下ProcessThread的Start()函数里面执行了什么： 由图可见，调用Start()后会创建一个新线程，在线程中循环

我们前面说了Call中有两个跟线程有关的成员module_process_thread_和pacer_thread_，我们看在Call构造函数中，跟这两个成员相关的代码：Call::Call(){//... module_process_thread_->Start(); module_process_thread_->RegisterModule(call_stats_.get());

我们首先来看下RTCP的RR报文的格式： 接着上一篇，我们来到ModuleRtpRtcpImpl的IncomingRtcpPacket函数中，如下：int32_t ModuleRtpRtcpImpl::IncomingRtcpPacket( const uint8_t* rtcp_packet, const size_t length) { RTCPUtility::RTCPPa

画了一个相对完整的类图，以备查看： videochannel的创建过程为： 由上图可知，当本地媒体的sdp准备好后，会调用Conductor::OnSuccess()（OnSuccess()在接口CreateSessionDescriptionObserver中）。然后为本地媒体创建一个videochannel（还有audiochannel没写出来）。

同样，先附上报文图： 首先我们看下RFC3550中，LSR的说明： last SR timestamp (LSR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in Section 4) received as part of the most recent R

先附上RR报文的图： 这节我们看下RR报文的fraction lost字段，它占8位，RFC_3550中对他的解释为： The sender of the receiver report estimates the fraction of the RTP data packets from source SSRC_n that it assumes to be lost since it sen

我发现这篇文章写得比我好：http://blog.youkuaiyun.com/mercy_pm/article/details/71474264

在WebRtc中，与消息机制有关的类主要有MessageQueue, Thread, SocketServer，类图如下：主循环在MessageQueue的Get()中循环处理消息：下面介绍一下Thread多线程的消息传递：

PeerConnectionFactory简化的类图如下： 其中，它内部有两个代表线程的对象：signaling_thread_线程和worker_thread_线程，其中signaling_thread_线程是主线程（也是当前线程），而大部分真正的工作其实是在worker_thread_线程中执行的。创建PeerConnectionFactory及其初始化大概如下： 注意第3步， 在此创建音视

MediaEngineInterface是Webrtc中的音视频引擎接口，重要性不言而喻，先看下它在类图中位置： 它的实现为： 可见MediaEngineInterface接口实际上包含了音频引擎WebRtcVoiceEngine和视频引擎WebRtcVideoEngine2。

在《PeerConnection中的Channel相关类图及创建过程》的类图中我们看到，在WebRtcVideoChannel2中有一个map<uint32_t, WebRtcVideoSendStream*>send_streams_, 它实现了VideoSinkInterface<VideoFrame>接口，是视频帧发送的开始，同时它还拥有一个非常在总要的成员VideoSendStream* s

我们看下在VideoSendStream构造函数与线程有关的代码：VideoSendStream::VideoSendStream(ProcessThread* module_process_thread) :module_process_thread_(module_process_thread), encoder_thread_(EncoderThreadFunction, th

先看类图： 我们知道WebRtcVideoSendStream实现VideoSinkInterface, 并且已经注册到VideoTrack中，当一帧视频frame准备好的时候，Onframe会被调用，我们看下它干了什么：void WebRtcVideoChannel2::WebRtcVideoSendStream::OnFrame( const VideoFrame& frame) {

前面的分析我们知道，RR报文中主要包含丢帧率fraction loss, 通过它估算出目标发送码率，然后更新编码器和PacedSender, 本节记录一下它们的类图，以及总流程： 类图： 流程图：

前面文章分析过，通过反馈报文RR和REMB，可以得到对端期望的发送码率，发送端需要根据这个码率来动态调节自己的发送码率，发送码率的控制主要有两个模块，VieEncoder模块和PacedSender模块，本文章描述PacedSender模块如何调节发送码率。先看类图：

先看下与ViEEncoder相关的类图： 类图1： 然后我们看下一帧VideoFrame的编码流程： 流程图1： 类图2： 流程图2： 一帧videoframe经过编码后，经过层层传递，图的最后是到了PaceSender的InsertPacket函数，其实这顶多只进行到一半，离它被发送出去还很远，后面我们再说吧。后面是我一开始用手记录的，存起来以备查看： 这也够长的，写了三页纸（其实我

上一次我们分析到PaceSender的InsertPacket，他其实是向Packet队列插入了一个元素，在PaceSender的另一个线程中，运行着Process()函数，他是一个while循环，从packet队列中取出元素然后发出去，下面是类图： 流程图1： 流程图2：

先看下webrtc中跟接收rtcp包相关的类图： 上面的类图画的是VideoReceiveStream，对于VideoSendStream来说也是差不多的。流程如下：

Call在WebRtcVideoChannel2中，如下图： Call在什么时候创建的呢，我们看下面的代码：VideoChannel* ChannelManager::CreateVideoChannel_w( webrtc::MediaControllerInterface* media_controller, TransportController* transport_con

如下：

在webrtc中，许多重要的对象实际上都是“代理对象”，如PeerConnection， PeerConnectionFactory，等等，可以看下PeerConnectionFactory的源代码：rtc::scoped_refptr<PeerConnectionFactoryInterface>CreatePeerConnectionFactory() { rtc::scoped_refp

在webrtc中，MediaStream代表一个媒体流，AudioTrack，VideoTrack代表音频”轨道”和视频“轨道”，如同一个MP4文件可以包含许多音轨和视频轨一样，一个MediaStream中可以包含多个AudioTrack和VideoTrack，它们的关系如下图：

VideoTrack是webrtc中视频流最上层的接口，它内部其实是经过层层封装，对于本地的VideoTrack(远端的还没研究)，它最终通过VideoCaptureImpl完成本地视频的采集，VideoCaptureImpl实际上是通过DirectShow(windows平台上)与硬件打交道的。可以先看下它简化后的关系： 那么视频帧是如何通过ViedoTrack渲染出来的呢，先看另一个接口：

webrtc在windows平台上底层是通过调用DirectShow接口来捕捉摄像头的，我们先来看下VideoCapturer的一个简化的类图： 我们在上层使用的是VideoCapturer接口，它的实现类是WebRtcVideoCapturer，而WebRtcVideoCapturer拥有一个VideoCaptureModule对象，它实际上是VideoCaptureDS，从名字可以看出它通过D

在peerconnection_client的demo中，主要有三个类，MainWnd， PeerConnectionClient和Conductor，他们之间的简单的关系如下：

MainWnd中使用的就是MFC的消息机制，在此复习一下MFC吧在MainWnd::Create()中，调用RegisterWindowClass()：bool MainWnd::RegisterWindowClass() { if (wnd_class_) return true; WNDCLASSEX wcex = { sizeof(WNDCLASSEX) }; wcex.st

前两章为了简化分析，画的类图省略了很多，现在补上相对完整一点的类图，以备后面需要查看。 VideoTrack: VideoTrackSource: WebRtcVideoCapturer:

webrtc中大量使用信号与槽的机制，主要的类如下： has_slots包含有一个signal的集合，他主要有两个操作：void signal_connect(_signal_base_interface* sender){ lock_block<mt_policy> lock(this); m_senders.insert(sender); //将一个_signal_bas

webrtc中的socket接口如下：

本地视频要发送出去，需要将VideoTrack(包含在stream中)添加到PeerConnection中去，它添加进去的过程也挺复杂的，先看下与之相关的类图吧： 然后我们再看下创建的流程： 从前面文章的本地视频渲染可以知道，要想得到一帧图片，需要通过将一个“sink”通过AddOrUpdateSink()将自身注册到videotrack中去，这样当一帧图像准备好时，通过调用sink的OnFra

从前面文章的本地视频渲染可以知道，要想得到一帧图片，需要通过将一个“sink”通过AddOrUpdateSink()将自身注册到videotrack中去，这样当一帧图像准备好时，通过调用sink的OnFrame()来处理图片。同理，要想得到视频的图像，必须也要把它与PeerConnection内部的某个对象关联起来。我们再来看下面这个图： 看上图，其实VideoTrack被赋值给了WebRtcVi

PeerConnectionClient主要用来处理与信令服务器的tcp通讯，它有两个Win32Socket：control_socket_和hanging_get_，在PeerConnectionClient::DoConnect()中创建，并在PeerConnectionClient::InitSocketSignals()中连接好socket的信号。

Win32Socket类主要成员为：EventSink是用来干嘛的呢，其实他主要是为了接收socket事件用的，从图中可看出，EventSink继承自Win32Window类，Win32Window类对应着一个MFC窗口，通过Windwos API: WSAAPIWSAAsyncSelect( _In_ SOCKET s, _In_ HWND hWnd, _In_ u_in

总流程如下：

流程如下：

流程如下：

如下：

类图如下： ThreadManager是采用单例模式创建的：ThreadManager* ThreadManager::Instance() { RTC_DEFINE_STATIC_LOCAL(ThreadManager, thread_manager, ()); return &thread_manager;}#define RTC_DEFINE_STATIC_LOCAL(type,