（二）WebRTC手记之框架与接口

转自：http://www.cnblogs.com/fangkm/p/4370492.html

 

转载请注明出处：http://www.cnblogs.com/fangkm/p/4370492.html

上一篇文章简单地介绍了下WebRTC的协议流程，这一篇就开始介绍框架与接口。

一提到框架，本能地不知道从什么地方入手了。曾经直接从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原生的音视频本地采集模块。