架构
-
整理分为两层：
应用层、核心层 -
绿色部分是核心部分，
是WebRTC提供的核心功能； -
紫色部分是浏览器提供的JS的API层；
即
浏览器对WebRTC核心层的C++ API 做了一层封装，
封装成了JS接口； -
最上面的箭头是
上层应用了，
上层应用可以在 浏览器中 直接访问 浏览器提供的API； -
最终调用到核心层【蓝色虚线框、可重载！！】
WebRTC核心层
-
C++ API：API数量较少，主要是PeerConnection；
（PeerConnection的API又包含传输质量、传输质量报告、各种统计数据、各种流等）
【设计技巧：
对于上层来说，提供的API简单，方便应用层开发；
内部比较复杂；】 -
Session层【上下文管理层】：
如应用创建了音频、视频、非音视频的数据传输，
都可以在Session层做处理，做管理相关的逻辑； -
【最重要】引擎层/传输层【核心】
-
音频、视频、传输 解耦
-
音频引擎：【Voice Engine】
ISAC/ILBC 编解码；
NetEQ 【Buffer】 网络适配、防止网络抖动；
回音消除（echo canceler）：
音视频重点，决定产品质量，
WebRTC里提供了相关非常成熟的算法，开发时只需要调节参数即可；
降噪（Noise Reduction）、自动增益； -
视频引擎：【Video Engine】
VP8、openH264 编解码；
Video jitter buffer：防止视频抖动；
Image enhancements：图像增强； -
传输【Transport】
底层用的UDP，上层用的SRTP【即安全的、加密后的RTP】；
Multiplexing：多个流复用同一个通道；
P2P层【包括 STUN+TURN+ICE】；
所有的
音频视频的接收与发送，
都是通过传输层去做的，
传输层包括了泄漏的检测、网络链路质量检测，
根据情况估算网络带宽，根据网络带宽进行音视频、文件等非音视频的传输；
-
- 硬件层
视频采集、渲染；
音频采集；
网络IO等；
WebRTC的核心层中是没有视频的渲染的，
所有的渲染都需要 应用层 或者 浏览器层 自己做；
WebRTC目录结构
- WebRTC代码量大，目录多
-
实际开发中，可能需要我们修改WebRTC的代码，
所以，我们必须知道每个目录的功能、作用是什么；
补充说明
-
call，一个端一个call，多个端多个call；
-
module目录很大，也特别重要，
里边有很多子模块，
每个子模块也都非常重要；
-
pc：【重要目录，上层的一个统一接口层】
Peer Connection，代表一个连接，
连接下边就要有很多相关API了，
如，
Stream 流；
chain 轨【音频轨、视频轨、桌面轨】
【轨 即 一系列永不相交的平行线（线程），
即音频与视频与桌面处理，都是各自处理，互不交叉的】；
所以在Peer Connection中我们可以拿到流，
通过流我们可以拿到每一个多媒体，
还可以拿到所有媒体的统一信息、传输的统一信息等 -
p2p：
端对端的传输时，需要先检查p2p是否能打通；
相应的协议、工具、API等，放在这里； -
rtc_base：
不同操作系统，如Window和Linux，之间的系统函数差别就特别大；
但是rtc_base都封装好了，
上层按照规范编写调用逻辑即可，
框架会判断是在哪个平台运行，并执行相应的代码； -
rtc_tool是音视频相关的测试；
tool_webrtc是整个框架的测试； -
system_wrappers，
存放操作系统等操作代码，
不同系统不同文件存放；
以上是WebRTC最外层的目录，
下面看WebRTC目录下的Modules子目录
WebRTC Modules 目录
-
audio_coding：
上面的WebRTC架构图中
提到的 ISAC/ILBC、VP8等编解码器逻辑，
都是放在这个目录下的； -
audio_device：
现在的WebRTC文件中关于Android、IOS的部分都放在sdk目录下了，
而之前的话，
所有的设备类型包括Android、IOS、Window、Mac、Linux的逻辑都是在audio_device目录下的；
现在的话Android、IOS被提取出去，
这里放的是关于Window、Mac、Linux的文件； -
audio_mixer：
混音的概念：
比如现在有几个用户同时在说话，
这样子会产生多个音频流，
WebRTC则会把这几个音频流混合在一起，
这样子在传输的时候就比较方便，
减少了音频流总数；
那这个混音相关的逻辑文件，就放在audio_mixer这里； -
audio_processing：
音频前后处理：指回音消除、降噪、增益等处理操作； -
bitrate_controller：码率、码流控制；
-
congestion_controller：
当我们检测到网络流量比较高的时候，
我们要做一些流量控制，
防止网络包把带宽打死；
相关处理逻辑 则 放在本文件夹下；
-
探测码率之后，对码率做一个均衡的平滑的处理，再发送交互；
-
video_processing：
视频前后处理：指回音消除、降噪、增益等处理操作；
如增加人脸识别功能也可以放在这个目录下；
WebRTC的运行机制
轨
- Track
- 视频与音频是不相交的，单独存放；
- 两路音频也是两路轨，不相交；
流
- MediaStream
- 借鉴了传统媒体流的概念；
传统媒体流中也包括了音频轨、视屏轨等；
WebRTC重要的类
-
MediaStream
传输媒体数据； -
RTCPeerConnection【核心】
这个WebRTC中最为重要的类，
是一个大而全的类，包含了很多重要的功能；
设计优势：
在应用层应用时方便，
只需要创建一个RTCPeerConnection连接，
然后把一个MediaStream媒体流搭载上去，
随后的细节就不用管了，
其中所有的传输、寻路等细节，
都由RTCPeerConnection内部封装实现了，底层封装做了很多相关的工作； -
RTCDataChannel
非音视频的数据（如文本文件、二进制数据等），都通过RTCDataChannel来传输；
RTCDataChannel是通过RTCPeerConnection获取的；
传输非音视频的数据时，
应用层要做的，
就是拿到一个RTCDataChannel对象，把数据搭载上去即可；
PeerConnection调用过程
-
Worker 线程、Signaling线程，
创建PeerConnectionFactory，
PeerConnectionFactory可以
创建PeerConnection、LocalMediaStream、LocalVide/AudioTrack等； -
多方进行通讯时，
每一方（每一个参与单位）都是对应一个Stream；
调用时序图
-
首先应用层
Application【注意这里Application本身就是一个PeerConnectionObserver】，
创建出一个PeerConnectionFactory【CreatePeerConnectionFactory】； -
PeerConnectionFactory触发CreatePeerConnection、
CreateLocalMediaStream、CreateLocalVideoTrack、CreateLocalAudioTrack
创建了PeerConnection、MediaStream等等实例； -
然后通过
AddTrack，
把各种轨（track）加到流（LocalMediaStream）中去，
然后通过AddStream，
把流加到PeerConnection中； -
流加到连接之后，
会通过CommitStreamChanges提交流的变化；
当流发生变化的时候，
会触发OnSignalingMessage事件，创造出一个offer【SDP描述信息】； -
有了
offer【SDP描述信息】之后，
就会通过应用层【Application】，通过信令，
发送到远端【Send offer to the remote peer】；
【SDP描述信息】内容：
有哪些音视频数据，音视频数据的格式分别是什么，传输地址是什么等；
-
远端收到数据后，则根据
offerSDP，
回复一个answerSDP【Get answer from the remote peer】，
交给本地信令； -
信令收到远端的
answerSDP之后，
会把信息传给本地PeerConnection【ProcessSignalingMessage】，
本地PeerConnection就会拿到对方的媒体流信息、传输端口、传输地址；
至此，远端和本地就打通连接，
可以相互传媒体数据；
-
远端数据来的时候，
PeerConnection还会将远端的流添加到Application中去；
【OnAddStream（注意区分AddStream）】
参考自：
网友评论