WebRTC手记

一、协议和流程

WebRTC是HTML5支持的重要特性之一，有了它，不再需要借助音视频相关的客户端，直接通过浏览器的Web页面就可以实现音视频对聊功能。而且WebRTC项目是开源的，我们可以借助WebRTC源码快速构建自己的音视频对聊功能。无论是使用前端JS的WebRTC API接口，还是在WebRTC源码上构建自己的对聊框架，都需要遵循以下执行流程：

上述序列中，WebRTC并不提供Stun服务器和Signal服务器，服务器端需要自己实现。Stun服务器可以用google提供的实现stun协议的测试服务器（stun:stun.l.google.com:19302），Signal服务器则完全需要自己实现了，它需要在ClientA和ClientB之间传送彼此的SDP信息和candidate信息，ClientA和ClientB通过这些信息建立P2P连接来传送音视频数据。由于网络环境的复杂性，并不是所有的客户端之间都能够建立P2P连接，这种情况下就需要有个relay服务器做音视频数据的中转，本文本着源码剖析的态度，这种情况就不考虑了。这里说明一下， stun/turn、relay服务器的实现在WebRTC源码中都有示例，真是个名副其实的大宝库。

上述序列中，标注的场景是ClientA向ClientB发起对聊请求，调用描述如下：

• ClientA首先创建PeerConnection对象，然后打开本地音视频设备，将音视频数据封装成MediaStream添加到PeerConnection中。
• ClientA调用PeerConnection的CreateOffer方法创建一个用于offer的SDP对象，SDP对象中保存当前音视频的相关参数。ClientA通过PeerConnection的SetLocalDescription方法将该SDP对象保存起来，并通过Signal服务器发送给ClientB。
• ClientB接收到ClientA发送过的offer SDP对象，通过PeerConnection的SetRemoteDescription方法将其保存起来，并调用PeerConnection的CreateAnswer方法创建一个应答的SDP对象，通过PeerConnection的SetLocalDescription的方法保存该应答SDP对象并将它通过Signal服务器发送给ClientA。
• ClientA接收到ClientB发送过来的应答SDP对象，将其通过PeerConnection的SetRemoteDescription方法保存起来。
• 在SDP信息的offer/answer流程中，ClientA和ClientB已经根据SDP信息创建好相应的音频Channel和视频Channel并开启Candidate数据的收集，Candidate数据可以简单地理解成Client端的IP地址信息（本地IP地址、公网IP地址、Relay服务端分配的地址）。
• 当ClientA收集到Candidate信息后，PeerConnection会通过OnIceCandidate接口给ClientA发送通知，ClientA将收到的Candidate信息通过Signal服务器发送给ClientB，ClientB通过PeerConnection的AddIceCandidate方法保存起来。同样的操作ClientB对ClientA再来一次。
• 这样ClientA和ClientB就已经建立了音视频传输的P2P通道，ClientB接收到ClientA传送过来的音视频流，会通过PeerConnection的OnAddStream回调接口返回一个标识ClientA端音视频流的MediaStream对象，在ClientB端渲染出来即可。同样操作也适应ClientB到ClientA的音视频流的传输。

二、框架与接口

一提到框架，本能地不知道从什么地方入手了。曾经直接从Chromium项目对WebRTC的源码的集成方面入手，后来发现这个步子迈的太大了，看的越多，概念越混乱，看了半个月感觉也没啥沉淀。还是从WebRTC提供的示例工程peerconnection_client入手比较轻便。先抛开音视频流的构建和渲染流程，示例工程核心的代码结构如下：

从面向对象的视角来看，WebRTC的设计还是非常棒的，真正地做到了接口编程的概念，对WebRTC功能的使用都通过接口来进行，这样最大程度上保证了WebRTC模块的可定制性，这样就可以让WebRTC更多地回归到描述协议的本质。如果WebRTC对这些接口的实现不能满足你的业务需求，理论上你可以提供自己的实现逻辑。本图中的PeerConnectionFactoryInterface和PeerConnectionInterface没有这种定制的代表性，因为重新提供它们的实现逻辑的需求场景基本上不存在（即便不用重写，但也支持参数的定制，具体请参见CreatePeerConnectionFactory的重载方法）。但是音视频相关的接口定制的场景就很普遍了，比如Chromium浏览器集成WebRTC，但是音视频采集需要走Chromium自己的音视频模块，所以Chromium对WebRTC音视频的采集接口重新做了实现适配，以后有机会肯定非常乐意分享下Chromium源码对WebRTC的集成，不过那也是在对WebRTC熟悉完之后的工作了。

图中Conductor是该示例工程提供的核心业务类，整个WebRTC的使用都浓缩在这个类中。Conductor通过CreatePeerConnectionFactory方法创建了一个PeerConnectionFactoryInterface接口的实现对象，通过这个接口，可以创建关键的PeerConnectionInterface接口，PeerConnectionInterface接口是WebRTC的协议核心。此外，PeerConnectionFactoryInterface接口还提供了创建本地音视频流的功能接口，这个部分稍后再述。根据图中PeerConnectionInterface接口的成员方法可以看出，WebRTC通信流程的交互接口基本上都在这里面了，给Conductor的回调通知是通过PeerConnectionObserver接口来完成。具体的交互流程请参见上一篇博文。

接下来分析本地音视频的相关接口，由于音视频内容较多，这里先介绍下接口概念，不谈具体实现（下一节专门讲解WebRTC原生的音视频采集），还是以peerconnection_client工程为例：

这里涉及到非常多的音视频相关接口，基本上都是概念性的，最怕遇到新的设计概念，主要是怕自己理解有误差，下面谈一下我对这些接口概念的理解：

MediaStream概念： 表示媒体流，由MediaStreamInterface接口抽象，每个媒体流都有一个唯一的标识（通过label成员方法返回），它由一系列的音频Track（由AudioTrackInterface接口抽象）和视频Track组成（由VideoTrackInterface接口抽象）。

Track概念：具体指上图结构中AudioTrackInterface和VideoTrackInterface接口，Track表示的是在媒体流中轨的概念，AudioTrackInterface标识的是音频轨，VideoTrackInterface标识的是视频轨，一个MediaStreamInterface标识的媒体流中允许携带多个媒体轨数据，它们之间是独立的，在编码渲染的流程中各自处理。如果概念还很模糊，轨的概念就相当于音频数据中的声道概念（左声道、右声道）、视频数据中的YUV场的概念。Track既然封装了媒体轨数据，那就必然有个媒体源做为数据的提供者，如音频Track由AudioSourceInterface接口作为数据源提供者，视频Track由VideoSourceInterface接口作为数据的提供者。有输入接口就必然有输出接口，这部分在该图中只展示了视频数据的输出接口VideoRendererInterface，这里的Render命名的意思并不是仅限于将视频和音频数据渲染出来，应该理解成输出接口。

VideoSourceInterface：抽象视频源接口供VideoTracks使用，同一个源可以被多个VideoTracks共用。视频源接纳了一个VideoCapturer接口，抽象视频采集的逻辑，我们可以提供自己的VideoCapturer实现做为视频数据的采集源。VideoCapturer是个关键的定制接口，比如Chromium源码就是自己实现了VideoCapturer接口而没用原生的WebRTC采集实现，但Chromium的音视频采集都在browser进程，因此它对VideoCapturer接口的实现要比想象的复杂，它需要从主进程接收到视频帧数据然后触发VideoCapturer的SignalFrameCaptured信号。

AudioSourceInterface：概念上同VideoSourceInterface类似，抽象音频源接口供AudioTracks使用，但是从源码中理解，这是个伪概念，因为没有提供一个类似于VideoCapturer的AudioCapturer接口，这里没有音频的采集逻辑，实际上WebRTC的音频采集接口使用的是AudioDeviceModule，在创建PeerConnectionFactory的时候可以由外界定制，如果没有，则内部创建AudioDeviceModuleImpl来实现此接口完成音频设备的采集工作。可能是功力不够，反正我是不太理解音频采集和视频采集这种设计的不对称性。如果也封装一个AudioCapturer接口的概念，这样可定制性是不是可以更高。

构建媒体流的过程基本上就是构建Video Track和Audio Track，并将其添加到Media Stream里。在peerconnection_client工程中，Conductor依赖DeviceManagerInterface接口的CreateVideoCapturer方法创建一个当前可用的视频设备采集对象VideoCapturer，将它作为视频采集源中的数据来源（通过挂接VideoCapturer的SignalVideoFrame信号来接收视频数据），此外MainWnd还创建了一个内部类VideoRenderer从VideoRendererInterface接口派生，并将其添加到Video Track中， VideoRenderer的实现就是将接收到的视频帧数据渲染到窗口上。

三、WebRTC视频采集

这里先分析视频采集流程。分析的时候先分析WebRTC原生的视频采集流程，再捎带提一下Chromium对WebRTC视频采集的适配，这样能更好地理解WebRTC的接口设计。

1. WebRTC原生视频采集

在介绍视频设备的采集之前，首先要分析一下WebRTC的DeviceManager结构，因为视频采集的抽象接口VideoCapturer的WebRTC原生实现就是通过它来创建的。这个类的功能还包括枚举音视频设备的相关信息等。结构如下：

限于篇幅，该UML中没有标出DeviceManagerInterface接口的所有功能接口，具体包括：获取音频输入/输出设备列表、获取视频输入设备列表、根据设备信息创建VideoCapturer视频采集对象等。由于获取硬件设备列表，涉及到平台相关的调用，在Windows平台下的实现是Win32DeviceManager类（可以调用DeviceManagerFactory的静态方法Create()返回当前平台相应的DeviceManager对象）。关注一下DeviceWatcher，顾名思义，它的功能在于监控设备的变化。在Windows平台下的实现Win32DeviceWatcher通过API函数RegisterDeviceNotification监控视频类设备和音频类设备的变化。当有监视的类型设备发送变化时，会通过DeviceManagerInterface接口的SignalDevicesChange信号向外投递通知。最后分析一下创建VideoCapturer的流程。DeviceManager创建VideoCapturer对象时通过VideoDeviceCapturerFactory接口来完成的。VideoDeviceCapturerFactory接口的默认实现是WebRtcVideoDeviceCapturerFactory类，该类创建WebRtcVideoCapturer对象做为VideoCapturer接口的实现。可以理解成WebRtcVideoCapturer就是WebRTC原生的视频采集的实现，但这种说法不确切，因为视频采集涉及到跨平台，没这么简单。下面再细扒一下WebRtcVideoCapturer：

由于平台相关性，WebRtcVideoCapturer仍然不是视频采集的真正实现，它创建一个VideoCaptureModule接口对象来完成真正的视频采集工作。该抽象接口是视频采集的实现接口，最终在Windows平台下由VideoCaptureDS（传统的DirectShow方式）和VideoCaptureMF（Vista之后的Media Foundation API实现方式）来实现采集工作。这里要说明一下VideoCaptureMF在WebRTC中还是个空架子，还未真正实现，如果读者对Media Foundation API实现视频采集感兴趣，可以参考Chromium的media库中VideoCaptureDeviceMFWin类实现。

接下来分析一下VideoSourceInterface和VideoCapturer是如何结合，以及采集由谁驱动开始的。

VideoSource是WebRTC对VideoSourceInterface接口的实现, 它容纳一个VideoCapturer对象做为视频采集源，VideoRenderer是供外部从VideoSource中获取视频帧数据。此外VideoSource还依赖ChannelManager对象，使用它所包含的CaptureManager来负责视频的采集任务。VideoSource在创建的时候就会调用 Initialize方法中调用ChannelManager的StartVideoCapture方法开始采集视频数据。CaptureManager内部为每个VideoCapturer对象维护了一个CaptureRenderAdapter，CaptureRenderAdapter在创建的时候将OnVideoFrame成员方法挂接上VideoCapturer的SignalVideoFrame信号来实时接收采集源传送过来的视频帧数据，OnVideoFrame内部将接收到的视频帧数据分发给向其注册的VideoRenderer对象（VideoRenderer对象的注册的流程是VideoSource到ChannelManager，再到CaptureManager，最后注册到CaptureRenderAdapter与特定的VideoCapturer关联）。

至此，VideoSourceInterface在WebRTC中的实现已经很清晰了，视频采集的流程和时机也很明了，接下来顺便稍等地简单分析一下WebRTC中VideoTrackInterface接口的实现：

WebRTC创建了一个VideoTrack实现VideoTrackInterface接口，在此之前我一直有个疑问，VideoTrackInterface对外暴露的视频输出接口是VideoRendererInterface，而视频源接口VideoSourceInterface对外暴露的视频输出接口是VideoRenderer，两套接口是如何适配的。看到这里，我发现原来VideoTrack新建了一个VideoTrackRenderers对象来完成VideoRendererInterface接口到VideoRenderer接口的适配工作。VideoTrackRenderers一方面从VideoRenderer接口派生，这样就可以将自己通过VideoSourceInterface的AddSink方法挂接进去来接收视频帧数据，另一方面将接收到的视频帧数据分发给外部挂接给VideoTrackInterface的VideoRendererInterface接口。

2. Chromium对WebRTC的视频采集适配

Chromium创建WebRtcVideoCapturerAdapter类来实现VideoCapturer接口，相关结构如下：

Chromium自己也封装了Track、Source概念，所以当初看这块的时候脑袋不容易转弯费了不少心思。WebRtcVideoCapturerAdapter需要接收Chromium的视频采集模块传输过来的帧数据，通过一层层的挂接，最终挂接到MediaStreamVideoSource类中。MediaStreamVideoSource接收到视频帧数据时，再一层层地通知回来，最终通知到WebRtcVideoCapturerAdapter的OnFrameCaptured方法，该方法内部触发SignalFrameCaptured信号。

MediaStreamVideoSource封装了Chromium视频采集的入口，这块结构就复杂了，牵涉到跨进程的架构，如下：

这部分不打算细说，如果细说就很可能混淆到目前为止建立的仅有的一点点概念了，本节主要是介绍的是Chromium对WebRTC视频采集接口的定制。

四、webrtc音频采集

先介绍WebRTC原生的音频采集，再介绍Chromium源码对它的定制。

1. WebRTC原生音频采集

先介绍一下WebRTC中与音频采集貌似相关的接口概念：

结构上看起来是不是和视频Track的结构类似？不过前面提过，如果你以对称的思维，在此结构中找出与视频track相似的采集源和输出源，那就肯定无功而返了，LocalAudioSource对AudioSourceInterface的实现就是一个空实现，没有了音频源，那音频处理接口AudioProcessorInterface和输出接口AudioRenderer都成了无米之炊了。这些接口先摆在这，可能类似于AudioCapturer的框架正在实现的途中，也可能这些接口有别的用处，比如远程音频流的抽象等，这里就暂且搁置，先记下有这回事吧。这里只谈WebRTC本地音频的采集处理。前面介绍音视频接口的时候也提到的，本地音频的采集由AudioDeviceModule接口统一封装:

AudioDeviceModule是个大而全的接口，恨不得将所有音频相关的接口都封装在里面（实际也差不多了），具体包括：枚举音频采集设备（Record）和播放设备（Playout）、设置当前的采集设备/播放设备、开始/停止音频的采集/播放、设置音频增益控制开关（AGC）等。AudioTransport是个关键的对外接口，负责音频数据的传入（调用NeedMorePlayData方法，供Playout使用）和输出（调用RecordedDataIsAvailable方法，数据由Record采集操作产生）。

AudioDeviceModuleImpl实现了AudioDeviceModule接口，创建的时候调用CreatePlatformSpecificObjects方法创建平台相关的AudioDeviceGeneric接口实现。该接口抽象了音频的采集和播放逻辑，在Windows平台下有两种实现方案：

•   AudioDeviceWindowsWave实现的是传统的Windows Wave APIs方案。
•  AudioDeviceWindowsCore实现的是Vista之后才支持的Windows Core Audio APIs方案。

此外，AudioDeviceModuleImpl还维护了一个AudioDeviceBuffer对象来管理音频数据的缓冲区，由它直接与对外接口AudioTransport交互。比如：

•  当AudioDeviceWindowsWave或者AudioDeviceWindowsCore需要播放音频数据的时候，会调用AudioDeviceBuffer的RequestPlayoutData方法请求播放数据，然后通过GetPlayoutData方法来获取刚请求到的数据。AudioDeviceBuffer的RequestPlayoutData就是调用AudioTransport接口的NeedMorePlayData方法来请求待播放的音频流数据。
•  当AudioDeviceWindowsWave或者AudioDeviceWindowsCore采集到音频数据后，会调用AudioDeviceBuffer的SetRecordedBuffer方法将采集到的音频数据传递进去，然后调用DeliverRecordedData方法来派发出去，该派发方法就是通过调用AudioTransport接口的RecordedDataIsAvailable来实现。

总之，音频采集模块处处都透露出大而全的结构设计。如果可以，真的应该细化一下概念设计，比如将音频采集和音频播放逻辑分离、音频输入和输出的接口拆分等等，那样才能谈得上结构设计。

2. Chromium对WebRTC的音频采集适配

根据WebRTC的本地音频接口设计，Chromium提供了一个WebRtcAudioDeviceImpl类来实现AudioDeviceModule接口，该类对象由PeerConnectionDependencyFactory负责创建和维护，结构如下：

如图所示，WebRtcAudioDeviceImpl摒弃了原生的AudioDeviceModuleImpl实现中大而全的设计，而是将音频采集和音频渲染逻辑分开，分别对应于WebRtcAudioCapturer和WebRtcAudioRenderer。WebRtcAudioRenderer通过WebRtcAudioRendererSource接口的RenderData方法向WebRtcAudioDeviceImpl请求音频流数据来渲染，WebRtcAudioDeviceImpl将该请求转发给前面提到的对外交互接口AudioTransport。WebRtcAudioCapturer封装音频采集逻辑，它将采集到的数据通过WebRtcLocalAudioTrack对象所持有的PeerConnectionAudioSink接口派发出去，WebRtcAudioDeviceImpl正是实现了该接口来接收音频采集数据，然后也是通过AudioTransport接口往外传递。至于WebRtcAudioCapturer对象的持有者MediaStreamAudioSource和WebMediaStreamTrack，这里暂时有个概念就行，它们是Chromium对HTML5媒体流的实现接口。接下来仔细分析一下WebRtcAudioCapturer和WebRtcAudioRenderer两个关键类，毋庸置疑，它们都涉及到了特定平台实现，而且在Chromium中还跨越了Render和Browser进程。和介绍Chromium视频采集的模式一样，由于不是本文重点，这里只列出结构图，不打算详解，如果你有开发上的需要，可以照着该结构图细看源码。

这是WebRtcAudioCapturer采集音频数据的结构，牵涉到跨进程通信，结构还是非常复杂的。WebRtcAudioRenderer的结构就不准备介绍了，因为Chromium的这块设计非常具备对称性，基本上图中类命名中的Input改成Output就差不多是WebRtcAudioRenderer的架构了。