WebRTC源码研究(1)WebRTC架构
文章目录
- WebRTC源码研究(1)——本节主要探讨WebRTC架构的相关内容
- 1.1 WebRTC简介
- 2.2 WebRTC能力
- 2.2.1 聚焦于当前5G时代对WebRTC的支持
- 2.2.2 大厂商技术生态的完善与布局
- 2.2.3 WebRTC典型应用场景解析
- 2.2.3(一):教育行业解决方案
- 2.2.3(二):互动电商解决方案
- 2.1.3.3 企业视频协作/OA办公解决方案
* 2.1.3.4
-
3. WebRTC架构设计
-
- 3.1 Web应用开发
- 3.2 Web API接口设计
- 3.3 C++语言下的原生WebRTC API实现
- 3.4 数据传输与会话管理机制
- 3.5 音频引擎模块API设计
-
- 3.5.1 音频、视频图像处理的主要数据结构
-
3.5.2 基于VoiceEngine的音频引擎模块API设计
- 3.6 VideoEngine
-
- 3.6.1 视频引擎(VideoEngine)模块 APIs
-
-
4. webrtc代码架构
-
- 4. 1 目录组织
- 4.2 核心组件
-
- 4.2.1 peercnommit:
-
peercnommit模块
-
4.2.3 网络传输组件:libjingle
- 5 WebRTC学习资料
-
- 5.1 书籍
- 5.2 大神博客
- 5.3 Demo实例代码
WebRTC源码研究(1)WebRTC架构
本人最近主要专注于音视频领域。研习了大量相关的配套书籍。现在仍在深入研究中。阅读的这些博客大多内容源自慕课网李超老师的视频课程。强烈推荐您购买李超老师的高质量课程。讲解非常清晰易懂。价格不贵且性价比较高。
本人最近主要专注于音视频领域
WebRTC 是一个集音视频通信功能于一身的强大工具,在音视频处理和即时通讯领域提供了完善的解决方案。核心在于其源代码是公开 accessible 的,并且你可以有机会深入研究这些源码库来探索其中如何解决各种技术难题的方法。此外,在理解这些算法的基础上应用它们到你的项目中将能够显著提升项目的效率与效果。无疑是一个功能强大的多媒体传输方案具备跨平台支持特性
更多详情请参考:
1. WebRTC简介
WebRTC作为一种网络实时通信技术(英文:Web Real-Time Communication),即为一种专为网页浏览器设计的技术接口。该技术自2011年6月1日起开源,并被收入万维网联盟W3C推荐标准中。
WebRTC弥补了Web端无法实时捕捉音视频的缺陷,并不仅实现了跨浏览器的实时视频传输
WebRTC整合了多种先进的实时通信技术功能集合体
- WebRTC基于网页环境下的实时视频会议服务遵循WHATWG协议,在浏览器中只需编写简单的JavaScript代码即可轻松实现Real-Time Communications (RTC)功能。
- WebRTC项目的最终目标是帮助Web开发者快速利用浏览器(Chrome、Firefox等)开发出各种丰富的实时多媒体应用,并避免安装任何插件;同时使开发者无需深入关注复杂的数字信号处理过程即可完成功能实现;目前项目处于W3C等组织制定相关JavaScript标准API的阶段(已进入第1.0版本 Draft阶段),此外项目还希望构建一个多互联网兼容性下的健壮实时通信平台,并促进开发者与浏览器厂商之间的良好生态发展;Google也致力于将WebRTC技术纳入HTML5标准体系中。
- WebRTC提供了音视频采集与编解码技术支撑网络传输与显示效果,并支持多种主流操作系统及移动设备场景:包括Windows操作系统、Linux系统、MacOS以及Android设备。
2. WebRTC的能力
根据最初的定义,WebRTC被指定为P2P(peer-to-peer)技术。
自建立以来, WebRTC已经大幅降低了Web开发人员无需复杂Java API即可构建实时通信应用程序所需的开发难度
目前来看,WebRTC在电视会议和直播领域有很大的潜力。
尽管WebRTC最初设计为纯粹的 peer-to-peer 技术,在实际应用中的一些日常业务需求则需要引入集中式媒体服务功能,并基于 peer-to-server 架构来提升系统的可靠性和性能。在构建 WebRTC 应用程序的过程中,在分析并解决 peer-to-peer 和 peer-to-server 架构之间的相关问题至关重要。
WebRTC 旨在不局限 servers 的技术发展路径,并未制定 server-side technologies like SDP 的统一标准框架;开发者可以根据具体情况进行选择。
WebRTC 是一种结合音视频处理与即时通讯功能的开源库工具,在多媒体领域展现出卓越的能力,并具备跨平台特性。该库在音视频处理领域具有重要地位的开源工具,在多个关键子领域均表现出色。其中FFmpeg则侧重于多媒体编辑与编码解码等核心功能对视频文件进行深度处理;而WebRTC 则负责整个网络中的音视频传输过程,并对其可能遇到的问题进行专门优化以解决回音消除、降噪等问题等网络层面的技术支持工作
总的来说,WebRTC能做下面这些事情:
- 实时音视频交流
- 游戏、即时通讯应用及文件传输服务
- 作为一个多功能套件,它不仅支持数据传输,还具备音频处理功能,包括去噪和降音效果
2.1 抓住属于WebRTC的5G时代风口
2.1.1 浏览器的支持情况
到目前为止,在全球范围内几乎所有的主流网页浏览器都已经支持WebRTC技术。尽管IE浏览器例外,在全球范围内WebRTC已经获得了 overwhelming majority of mainstream browsers 的认可与采纳。这一技术如今不仅在谷歌Chrome、苹果Safari以及Mozilla Firefox 等主流网页浏览器中得到应用,并且还涵盖了QQ浏览器、360浏览器以及Microsoft Edge等多种产品线

2.1.2 大厂的加入
威胁传统音频与视频服务提供商的是声网(跨国/跨印度/南亚地区)、即构科技以及融云等公司。一批新兴的会议服务供应商正利用WebRTC技术深入拓展互联网业务,在直播和短视频平台等音频与视频内容的实时传输领域中占据了重要地位,并直接对其造成了毁灭性的打击。
WebRTC可靠性和易用性(声网在web端调用的是标准的API(WebRTC api) W3C)
WebRTC已被推广至广泛使用于互联网会议中,并通过让操作者只需点击开始即可进行会议交流的方式减少了对复杂软件的操作,从而使得会议体验更加便捷。
2.1.3 WebRTC应用案例
2.1.3.1 教育行业解决方案

2.1.3.2 互动电商解决方案

2.1.3.3 企业视频协作/OA办公解决方案

2.1.3.4
3. webrtc架构
让我们先了解网上广为传播的Webrtc架构图,这张图表自WebRTC官网发布,同时也可以访问WebRTC中文网获取更多信息

从图中可以看出,整个浅绿色区域全部属于WebRTC的核心架构模块,它整合了为Web端用户提供的一系列Web API接口功能。而紫色的部分则代表了应用层面,这些区域通过调用核心模块提供的API来实现功能交互。在应用层面扩展相关API是可行的。
WebRTC核心层又分为四层:
- WebRTC C C++ API (PeerConnection): 这层的API相对比较少,最主要就是实现P2P连接。在PeerConnection里面又包含了很多接口,如传输质量,传输质量报告,统计数据,各种流都是封装在PeerConnection模块里面。除此之外主要有音视频采集,音视频传输,非音视频数据传输等。
- Session Management/ Abstract signaling (Session): 会话层,用来管理音视频,非音视频数据传输,处理相关逻辑。
- 最核心的第三层,包含:音频引擎,视频引擎,传输,3大核心模块。
- 最底层是与硬件相关的硬件适配层:这层包含:音频的采集和渲染,视频的捕捉,网络IO。注意到上图中底层的这个三个模块都是画的虚线,表示这些模块是可以自己去实现的,可以重载的,这样大大增加WebRTC的灵活性,为跨平台提供了基础。
WebRTC的核心模块体系主要包括三个关键组件:语音编码器、视频编码器以及传输层。在该体系中语音编码器专注于完成音频相关的技术处理,在该体系中语音编码器专注于完成音频相关的技术处理,在该体系中语音编码器专注于完成音频相关的技术处理。而视频编码器则负责 video 相关的技术实现。值得注意的是,在整个架构中并未集成音视频同步技术这一重要功能点。
Voice Engine 音频引擎包含3大模块:
- iSAC/iLBC Codec : 这个模块主要是编解码,
iSAC/iLBC是jips公司开发的,另外有我们熟悉的音频G711, G726,AAC, Opus目前使用的最多也是Opus,几年前AAC也是很火的,你可以自己把AAC模块加入到WebRTC里面.其中WebRTC中使用的是Opus,后面的会详细讲解这块的知识。 - NetEQ for voice :
NetEQ实际上是一个音频缓冲的buffer,用于做网络的适配。如我们做防止音频抖动,这里面涉及了很多相关的算法。 - Echo Canceler/ Noise Reduction : 这里面解决了很多做音频头疼的问题:回音消除,降噪等问题处理算法。回音消除是困扰很多公司的一个头疼的技术,但WebRTC里面提供了非常成熟,稳定的回音消除算法,值得好好研究,应用到自己的产品中。其实很多算法工程师做的也是利用像WebRTC一样的开源代码,自己调一些参数,来提高音频质量。
Video Engine 视频引擎包含3大模块:
- Video codec: 该核心功能主要负责视频编码解码工作。
H.265/HEVC和Ongoing development for H.267/HEVC++均源自Google团队。最初是由自家团队开发VP8编码技术,并随后扩展至支持H.264、H.265以及开放源代码(Open H.264)等标准。此外,在官方WebRTC环境中并未支持xh.264模块(若需使用可自行引入相应的开放源代码模块)。 - Video jitter buffer: 视频抖动防止技术与音频缓冲机制类似。
- Image enhancement: 该功能涉及基础图像处理工作。该模块提供了丰富的接口供开发者实现美颜、贴图滤镜等功能。其中包含人脸检测接口。
该传输模块划分为三个核心组件:在数据传输层面采用的是UDP协议,在实时性要求上更为严格的情况下能够容忍部分数据包丢失,并且WebRTC系统巧妙地利用了UDP无控制特性的优势来实现高质量音视频通信功能。所有音视频数据的发送与接收均通过传输层完成这一过程,并且从架构图中可以看出整个体系层次分明、逻辑清晰。
- SRTP : 通常在视频传输中采用的是RTP协议, 为了解决浏览器对安全性需求较高的问题, 现在转向使用SRTP协议以提高传输的安全性。此外, RTCP协议在控制流传输中起到了关键作用:发送方会发送相应的数据块, 接收方则会发送确认报告给对方, 这样双方就能实现有效的流控管理。
- Multplexing : 主要是为了通过多路复用技术将多个数据流整合到同一个传输通道中进行高效传送。
- P2P (STUN + TURN + ICE) : 其中STUN用于建立连接状态信息表(SIP), TURN负责建立实时通信会话(RAS), 而ICE则用于身份认证和加密(ICE)。这些技术共同构成了WebRTC的核心机制。
传输层涉及线路检测、网络数据包丢失、数据抖动以及流量控制等技术,并且这些技术都已经实现了非常成熟的应用方案。掌握这一块的技术是非常有价值的。
WebRTC传输层还实现了借助计算估算你的网络带宽,并不仅能够稳定地实现音视频传输,并且还能传输包括文件、文本在内的其他二进制数据
需要注意的一点是,在WebRTC的核心层面,并没有直接进行视频渲染操作;相反,视频渲染操作需要由应用层负责处理。
在之前的讲解中, 我们对WebRTC具备哪些核心功能有了一个基本的认识, 接下来我们将深入探讨各个功能模块的具体实现, 并详细介绍了相关技术和理论基础. 最后我们将通过深入分析源码来进一步理解其工作原理, 这样我们就可以自己编写代码, 在项目中进行实际应用.
3.1 Your Web App
由Web开发者构建的应用程序中包含实时通信功能;通过利用集成于现代浏览器中的WebRTC技术提供的API接口,能够开发视频和音频实时通信系统。
3.2 Web API
面向第三方开发者提供的WebRTC标准API(JavaScript),旨在帮助开发者轻松构建与网络视频通话功能相似的Web应用。这些API可划分为Network Stream API、 RTCPeerConnection以及Peer-to-peer Data API三个类别,并可在WebRTC 标准官方文档中找到详细说明。
- Network Stream API
MediaStream:用来表示一个媒体数据流。MediaStreamTrack: 在浏览器中表示一个媒体源。
- RTCPeerConnection
RTCPeerConnection: 一个RTCPeerConnection对象支持两个浏览器之间的实时通信。RTCIceCandidate:一个参与者的角色对应于相关协议的一个候选者。RTCIceServer: 是一个参与者的角色对应于相关协议的一个服务器。
- Peer-to-peer Data API
DataChannel: 数据通信通道( DataChannel)接口用于实现两个节点之间数据传输的通信通道。
3.3 WebRTC Native C++ API
本地开发的C++接口使得浏览器厂商能够轻松地遵循WebRTC标准并开发相应的Web API,并将数字信号处理抽象为一个统一的过程。提供了给浏览器开发者一个便捷的方式来构建JavaScript应用接口
3.4 Transport / Session
Session 组件由libjingle库(包括会话协商与NAT穿透组件库)开发;传输/会话层: 该层采用libjingle部分组件实现,并不依赖于xmpp/jingel协议
- RTP Stack协议栈:实现实时通信的多级协议架构。
- P2P(ICE + STUN + TURN):用于实现端到端通信,并支持跨不同网络之间的呼叫连接。
- Session Management:负责会话的创建与管理。该层协议允许应用开发者自定义实现细节。

3.5 VoiceEngine
音频处理引擎包含了多个音频多媒体处理组件,并涵盖了从摄像头接口到网络传输模块的完整解决方案。\n\nVoiceEngine是WebRTC中一个非常重要的组成部分,并且它是Google收购GIPS公司后所开源的项目之一。在VoIP应用领域中处于领先地位。\n
-
iSAC :
Internet Speech Audio Codec
针对VoIP和音频流的宽带和超宽带音频编解码器,是WebRTC音频引擎的默认的编解码器
采样频率:16khz,24khz,32khz;(默认为16khz)
自适应速率为10kbit/s ~ 52kbit/s;
自适应包大小:30~60ms;
算法延时:frame + 3ms -
iLBC :
Internet Low Bitrate Codec
VoIP音频流的窄带语音编解码器
采样频率:8khz;
20ms帧比特率为15.2kbps
30ms帧比特率为13.33kbps
标准由IETF RFC3951和RFC3952定义 -
NetEQ for Voice: 是一种基于音频软件开发的语音信号处理组件。
-
NetEQ算法是一种自适应抖动抑制算法和一种语音包丢失隐匿技术结合运用。
-
该系统设计使其实现了快速适应并维持高保真度的网络环境变化。
-
它通过动态优化机制确保了声音质量优美同时尽量减少延迟。
-
PS:这种技术不仅在GIPS公司内部独步天下,在WebRTC领域也发挥着至关重要的作用。
-
Acoustic Echo Canceler (AEC) : 该系统采用软件实现的信号处理模块(Acoustic Echo Canceler (AEC)),具备实时去噪功能;该模块能够有效去除麦克风捕获到的声音回响(echo signals)
-
Noise Reduction (NR) :
噪声抑制是一种在电子设备中使用的软件信号处理模块,在语音通信系统中用于消除多种类型的声音干扰源(如机器运转产生的嗡嗡声、风扇产生的噪音等)。
WebRTC的音频部分涵盖设备及各项核心功能(包括编码与解码模块(采用iLIBC/iSAC/G722/PCM16/RED/AVT等技术和NetEQ),加密技术以及相关的音频处理流程),并支持对音频文件(如语音文件)进行处理;同时具备声音输出功能以实现音量调节;此外实现了对音视频信号的同步管理以及基于RTP和RTCP协议的网络传输与流量控制机制
音频设备—audio_device:位于webrtc\modules\audio_device\main目录下,并主要包含了接口层设计以及各平台的具体实现细节。针对Windows平台而言,在其解决方案中采用了基于Windows Core Audio与Windows Wave的技术组合来实现音频设备的高效运行,并为开发人员提供了混音管理功能。通过使用相关的音频设备模块,在应用中可轻松实现声音输出与音量调节功能。
音频编码模块的源代码位于webrtc\modules\audio_coding目录中。WebRTC运用i\texttt{LIBC/iSAC/G722/PCM16/RED/AVT}的编解码技术。WebRTC额外配置了NetEQ功能——一种用于减少抖动和处理丢包的缓冲器模块,在提升音质的同时将延迟降至最低水平。另一个关键功能是实现语音会议中的混音处理过程
声音加密–voice_engine_encryption :与视频类似,在使用WebRTC时也能实现声音加密功能。对于声音文件而言,在这种情况下该功能允许使用本地音频源,并支持的格式包括PCM与Wave两种类型。此外,在这种情况下还可以通过WebRTC来捕获并存储来自本地设备的声音数据。
声音处理–audio_processing:源代码位于webrtc\modules\audio_processing目录中。声音处理模块对音频数据执行相关处理功能包括回声消除(AEC)、AECM(AEC Mobile)、自动增益(AGC)、降噪(NS)以及静音检测(VAD)等功能旨在提高语音质量。
网络传输与流控 : 和视频一样,WebRTC采用的是成熟的RTP/RTCP技术。
3.5.1 音频、视频图像处理的主要数据结构
| 定义类型 | 头文件 | 简介 | 路径 |
|---|---|---|---|
| Structures | common_types.h | 列出VoiceEngine & VideoEngine常见的结构 | |
| Enumerators | common_types.h | 列出VoiceEngine和VideoEngine通用的枚举数 | |
| Classes | common_types.h | 列出VoiceEngine和VideoEngine常见的类 | |
| class VoiceEngine | voe_base.h | 如何使用VoiceEngine类中的工厂方法为VoiceEngine分配和释放资源。它还列出了将文件跟踪和/或跟踪作为回调消息启用所需的api | |
| class VideoEngine | vie_base.h | 如何使用VideoEngine类中的工厂方法为VideoEngine分配和释放资源。它还列出了将文件跟踪和/或跟踪作为回调消息启用所需的api |
3.5.2 音频引擎(VoiceEngine)模块 APIs
下表列的是目前在 VoiceEngine中可用的sub APIs
| 定义类型 | 头文件 | 简介 | 路径 |
|---|---|---|---|
| VoEAudioProcessing | voe_audio_processing.h | 增加对噪声抑制(NS),自动增益控制(AGC)和回声控制(EC)的支持。也包括接收方VAD。 | |
| VoEBase | voe_base.h | 启用全双工VoIP使用G.711。注意:必须始终创建此API | |
| VoECallReport | voe_call_report.h | 增加对呼叫报告的支持,该报告包含心跳检测的数量、RTT度量和Echo度量。 | |
| VoECodec | voe_codec.h | 增加非默认编解码器(例如iLBC, iSAC, G.722等),语音活动检测(VAD)支持。 | |
| VoEDTMF | voe_dtmf.h | 增加电话事件传输,DTMF音频生成和电话事件检测。(电话事件包括DTMF。) | |
| VoEEncryption | voe_encryption.h | 增加外部加密/解密支持扩展。 | |
| VoEErrors | voe_errors.h | 声音引擎的错误代码 | |
| VoEExternalMedia | voe_external_media.h | 添加对外部媒体处理的支持,并允许利用外部音频资源。 | |
| VoEFile | voe_file.h | 添加文件回放、文件录制和文件转换功能。 | |
| VoEHardware | voe_hardware.h | 增加声音设备处理,CPU负载监控和设备信息功能。 | |
| VoENetEqStats | voe_neteq_stats.h | 添加缓冲区统计功能。 | |
| VoENetwork | voe_network.h | 增加外部传输,端口和地址过滤,窗口QoS支持和包超时通知。 | |
| VoERTP_RTCP | voe_rtp_rtcp.h | 增加支持RTCP发送者报告,SSRC处理,RTP/RTCP统计,前向错误纠正(FEC), RTCP应用,RTP捕获和RTP保持活着。 | |
| VoEVideoSync | voe_video_sync.h | 添加RTP头修改支持,播放延迟调优和监控。 | |
| VoEVolumeControl | voe_volume_control.h | 添加扬声器音量控制、麦克风音量控制、静音支持和其他立体声缩放方法。 |
3.6 VideoEngine
VideoEngine充当WebRTC视频处理系统。
VideoEngine整合了多个环节的系统架构,在涵盖从摄像头采集、到网络传输、再到显示展示各环节的过程中提供完整的解决方案。
- VP8
视频图像编码解码工具,在WebRTC视频引擎中被默认采用以实现视频传输功能。
该编码解码方案特别适用于实时通信场景因为其设计着重于极低延迟特性。
值得注意的是:VPx编码解码方案是由Google收购ON2公司后所推出的开放源代码项目现已成为WebM项目的组成部分而后者则是Google积极主导制定的关键HTML5标准之一。
Video Jitter Buffer
- Image enhancements
图像质量优化模块
对来自网络摄像头的图像数据进行处理,并涵盖明暗度检测、色彩增强以及降噪等技术,旨在提高视频质量。
WebRTC的视频组件包括视频捕获、I420/VP8编解码、多媒体文件的加密处理、图像运算、显示效果优化以及RTP/RTCP网络传输与流控机制等多种功能模块。
视频采集—video_capture : 源代码位于webrtc\modules\video_capture\main目录中,并不仅包括接口功能还包含了各个平台的具体实现。对于Windows平台上的WebRTC而言,则主要依赖dshow技术来进行视频设备信息的枚举与数据采集工作。这种设计使得该方案能够覆盖大部分主流的视频采集设备;然而对于那些仅通过驱动程序完成配置的专用摄像头(如海康WDR系列),则无法提供相应的支持。相比而言,在处理多种数字媒体格式方面表现更为出色,并且还具备灵活调节帧尺寸和帧率的能力。
视频编解码—video_coding :该模块中的源代码位于webrtc\modules\video_coding目录中。采用I420/VP8编码解码技术。它是由Google收购ON2后所推出的开源库,并且也被用于WebM项目的开发。相比传统的H.265/MPEG-4 AVC codec(占用约16倍于 VP8),该编码器仅需1/16的数据量即可达到同样画质甚至更好的效果。
特别适用于对画质要求较高的场景如网络会议、高清视频通话等。
Video Encryption ( video_engine_encryption ) :作为WebRTC框架中的一个组成部分, video_engine负责进行视频数据的安全处理,类似于在应用程序层面上完成的任务.它确保了两端通信中数据的安全性,从而防止了网络上出现敏感信息泄露的问题.该功能会在发送方与接收方分别执行编码与解码操作,而这种操作会对...产生一定的性能消耗.具体来说,如果选择开启该功能则会导致资源占用增加;反之,若不启用则能显著提升系统效率.需要注意的是, video_encryption的数据源既可以来自原始的数据流,也可来自经过编码后的流.根据实际情况分析后发现采用压缩过的流程更适合当前场景——这样做能有效降低相关操作的成本.
视频媒体文件–media_file :其代码实现位于webrtc\modules\media_file目录中。该功能允许使用本地文件作为视频来源,并类似于虚拟摄像头的功能;支持的音频和视频格式包括AVI格式。
此外,WebRTC还具备将音视频记录至本地存储的能力,并提供一种实用的技术特性。
视频图像处理–video_processing 的源代码位于该目录中:webrtc\modules\video_processing。该系统对每个画面进行分析与调整,并涉及亮度校正、色彩优化以及去噪技术以实现画面质量的提升。
视频显示–video_render : 该模块的源代码文件位于webrtc\modules\video_render目录中。对于Windows平台用户而言,WebRTC主要依赖于Direct3D 9和DirectDraw技术来实现视频展示功能。而在Mac平台上,则采用了Metal API来进行图形渲染工作。至于移动设备上的iOS系统以及Android系统,则采用了相应的OpenGL ES 3.0技术完成视频展示任务。
网络传输及流量管理 : 在线视频服务中, 确保数据传输过程中的管理与调节对于提升用户体验至关重要. WebRTC系统则采用基于成熟可靠的技术架构, 以实现高效的实时通信.
3.6.1 视频引擎(VideoEngine)模块 APIs
| 定义类型 | 头文件 | 简介 | 路径 |
|---|---|---|---|
| ViEBase | vie_base.h | 创建VideoEngine实例、通道和VoiceEngine交互的基本功能。 | |
| 注意:必须始终创建此API。 | |||
| ViECapture | vie_capture.h | 添加对捕获设备分配以及捕获设备功能的支持。 | |
| ViECodec | vie_codec.h | 增加非默认编解码器,编解码器设置和包丢失功能。 | |
| ViEEncryption | vie_encryption.h | 增加外部加密/解密支持。 | |
| ViEErrors | vie_errors.h | 视频引擎的错误代码 | |
| ViEExternalCodec | vie_external_codec.h | 增加了对使用外部编解码器的支持。 | |
| ViEFile | vie_file.h | 增加对文件记录,文件播放,背景图像和快照的支持 | |
| ViEImageProcess | vie_image_process.h | 增加效果滤镜,缩小,去噪和色彩增强。 | |
| ViENetwork | vie_network.h | 增加发送和接收功能,外部传输,端口和地址过滤,窗口QoS支持,包超时通知和改变网络设置。 | |
| ViERender | vie_render.h | 增加了渲染功能。 | |
| ViERTP_RTCP | vie_rtp_rtcp.h | 处理RTP/RTCP统计,NACK/FEC,保持活动功能和关键帧请求方法。 | |
4. webrtc源码结构
在 Chromium 系统中,WebRTC 源码运行速度极快。这得益于 Google 对音视频通信领域的重点支持。架构发生了快速的变化,并主要体现在以下几个方面:
- 对比源码版本 m50 和 m66,在编译工具上进行了调整。
- 旧版本采用 GYP 生成 ninja 文件的方法已经不再使用;新版本则采用了 gn 直接生成 ninja 文件的方式。
- 目录结构发生了变化;旧版本支持的一些功能在新版本中被移除。
- 随着 c++11、c++14、c++17 等新标准的发布……
由于WERTC技术的特点,在各个具体平台上所对应的源代码呈现多样性特征:虽然它们共享着相似的基本架构体系(即底层协议架构相同),但在具体实现细节上却各有特色:Android系统、iOS系统以及JavaScript环境等均遵循相同的协议规范:但在编码过程中充分考虑了各平台特有的开发规范
下面看通过知乎大神陈子兴的一个图来了解一下整体结构图如下:

4. 1 目录结构
如果按照通常层次化的思维来组织,从下到上,大概分以下几个层次:
-
OS 跨平台适配与硬件设备的接入与访问 :包括网络层、操作系统 API 的跨平台封装设计与实现;第三方库的封装层设计与实现 ,涉及音频设备、视频设备封装设计;音频 codec 、视频 codec 的实现;DTLS 协议的安全通信机制等
-
网络传输层 :
该层涉及候选节点收集(candidate collection),以及stun/TURN机制的执行(protocol implementation),基于DTLS与RTP的连接创建(connection establishment)以及sctp通道的创建(channel setup)等操作。 -
通道层 :
主要由传输介质以及媒体传输组成。其中BaseChannel层主要负责与PeerConnection层及Transport层的数据传递连接。而MediaChannel层则在音视频引擎内部起到中介作用。 -
RTP_RTCP :主要实现流层控制功能。
-
Audio Engine 和 Video Engine 是负责音视频数据处理与编码/解码的组件。
-
音视频编码/解码组件也是 WebRTC 的核心组成部分之一。
-
PeerConnection 和 MediaStream 对象主要用于实现 JSEP 协议的标准功能。
-
PeerConnectionInterface 被定义为对外提供抽象接口的类结构。
m66 版本的代码为例,目录如下:
| 目录名 | 模块内容 | 简介 | 路径 |
|---|---|---|---|
| api | 提供了对外的接口,音视频引擎层和 Module 直接的接口。 | – | – |
| audio | 音频流的一部分抽象,属于引擎的一部分逻辑。 | – | – |
| base | 这一部分还没有学习到,属于 Chromium 项目的一部分,貌似 WebRTC 中用的并不多。 | – | – |
| build | 编译脚本。这里需要注意的是,不同平台的代码在下载的时候,获取的工具集是不一样的。 | – | – |
| build_overrides | 编译工具。 | – | – |
| buildtools | 编译工具链。 | – | – |
| call | 主要是媒体流的接口抽象。为媒体引擎和 codec 层提供桥接。这里说的媒体流是 RTP 流。pc 层也抽象了媒体流,那是编码前、或者解码后。 | – | – |
| common_audio | 音频算法实现,比如 fft。 | – | – |
| common_video | 视频算法实现,比如 h264 协议格式。 | – | – |
| data | 测试数据 | – | – |
| examples | WebRTC 使用的例子。提供了 peerconnection_client、peerconnection_server、stun、turn 的 demo。 | – | – |
| help | 帮助信息。 | – | – |
| infra | 工具。 | – | – |
| logging | WebRTC 的 log 库。 | – | – |
| media | 媒体引擎层,包括音频、视频引擎实现。 | – | – |
| modules | WebRTC 把一些逻辑比较独立的抽象为 Module,利于扩展维护。 | – | – |
| ortc | 媒体描述协议,类似 sdp 协议。 | – | – |
| out | build 输出目录,这是 webrtc 官方编译指导中示范目录。 | – | – |
| p2p | 主要是实现 candidate 收集,NAT 穿越。 | – | – |
| pc | 实现 jsep 协议。 | – | – |
| resources | 测试数据 | – | – |
| rtc_base | 包括 Socket、线程、锁等 OS 基础功能实现。 | – | – |
| rtc_tools | 网络监测工具、音视频分析工具。很多工具都是脚本实现。 | – | – |
| sdk | 主要是移动端相关实现。 | – | – |
| stats | WebRTC 统计模块实现。 | – | – |
| style-guide | 编码规范说明 | – | – |
| system_wrappers | OS 相关功能的封装,比如 cpu、clock 等。 | – | – |
| test | 单元测试代码实现,用 gmock | – | – |
| testing | gmock、gtest等源码,属于整个 Chromium 项目。 | – | – |
| third_party | 第三方库依赖。比如,boringssl,abseil-cpp,libvpx等 | – | – |
| tools | 公共工具集,整个 Chromium 项目依赖的。 | – | – |
| tools_webrtc | WebRTC 用到的工具集。比如代码检查 valgrind 的使用。 | – | – |
| video | 视频 RTP 流的抽象接口,属于视频引擎的一部分。 | – | – |
4.2 核心模块
4.2.1 PeerConnection:
PeerConnection 的主要实现逻辑就是在 WebRTC 源码的 pc 目录下。
所有事情都始于PeerConnectionFactory和PeerConnection这两个核心组件,并向外界提供两个接口类:PeerConnectionFactoryInterface和PeerConnectionInterface。其中Factory类的作用就是为创建这些连接服务,在此之后我们将专注于讨论这些连接本身。
如果已经非常熟悉WebRTC的JavaScript接口的话
基于 WebRTC 的终端之间通信采用了 ICE 协议,并且以书包格式遵循 SDP 格式进行数据传输。PeerConnection 支持建立和管理会话描述。
PeerConnection 建模 RtpTransceiver、RtpSender 和 RtpReceiver 模型来映射 SDP 描述的媒体实现。
4.2.2 Module
WebRTC 会将那些具备独立性、内部 cohesion 和高重用潜力的部分提取出来并封装成单独的模块。这些模块位于 WebRTC 源码中的 modules 目录中,并主要包含与视频会议相关的组件(如音视频设备)、编码解码功能库(codec)以及实时传输控制模块(flow control)。
4.2.3 网络传输模块:libjingle
WebRTC重用了libjingle的一些组件,主要是network和transport组件
5 WebRTC学习资料
5.1 书籍
- 《WebRTC权威指南》: 该书适合初学者阅读,并能帮助他们掌握WebRTC的相关理论知识。
本书由艾伦B.约翰斯顿(Alan B.Johnston)与丹尼尔C.伯内特(Daniel C.Burnett)合著。
第三版详细描述了通过浏览器之间直接发送实时文本建立数据通道的功能。
此外,在浏览器媒体协商过程中涉及了完整的描述(包括Firefox和Chrome基于SDP的会话描述),并强调了如何利用Wireshark来监控WebRTC协议及其注意事项,并附有实例捕捉过程分析。
另外一项新增内容是也支持NAT和防火墙穿透 的TURN服务器功能。

这本书特别适合开发者作为入门读物。
其中关于传输层的具体实现细节则建议读者深入研究相关的技术文档和参考资料。
这本教材的作者是丹·里斯蒂克(Dan Ristic),并标注为(作者)。此外,在书中还添加了关于如何实现文件共享功能的具体示例,并引导开发者逐步创建一个基础的应用程序。

《Introduction to webrtc technology: English edition》:


图书《WebRTC Cookbook》的购买链接

The real-time communication system utilizing WebRTC technology enables peer-to-peer interaction within the browser.

A comprehensive guide on Multimedia Session Negotiations using SDP, focusing on the integration of SIP and WebRTC for IP Telephony.

《WebRTC Blueprints (English Edition)》:

5.2 大神博客
5.3 Demo实例代码
下面几个是WebRTC开发者社区的:
- STUN服务器与客户端:基于Node.js平台开发的该项目实现了Windows、Linux及Solaris系统上的简单STUN服务器及客户端应用。该协议(通过NATs进行简单遍历UDP)由IETF RFC 3489标准定义(详情请参考http://www.ietf.org/rfc/rfc3489.txt)
- Mac端实现的Framework一个Demo:
- WebRtcRoom Server:该服务采用Node.js进行开发,在信令服务器层主要依赖Socket.IO框架,并支持多平台部署包括Android、iOS、HTML界面以及独立服务器环境
几个跨平台开发中可用的 WebRTC Demo:
Flutter与WebRTC联合开发平台: Flutter插件 ,适用于iOS和Android系统。 获得了较高的评价哦!

React Native + Webrtc Demo:该WebRTC模块是一个基于React Native的应用,在iOS和Android平台上运行良好;它不仅支持视频流、音频传输及数据通道等功能(已有2,800+星的高用户评价)。

- Xamarin + WebRTC : 一个由 .NET平台上的开发团队利用Xamarin进行开发的基于WebRTC设计的iOS视频通话应用。该开发者本身就是微软所属的Xamarin团队成员。目前该类应用的数量相对较少。本项目的开发团队利用Xamarin平台实现了WebRTC支持下的本地iOS视频通话功能。

webrtc-uwp PeerCC-Sample:这个例子旨在实现WebRTC UWP(Universal Windows Platform)应用。该示例包含基于PeerConnection的WebRTC示例,并依赖于WebRTC UWP NuGet库以实现快速部署与运行。该方案特别适用于需要在两台等价设备之间建立音频/视频通话的应用场景,并支持Unity框架及针对HoloLens及混合现实开发的支持特性。对于需要完全基于源代码而非NuGet库版本的情况,请参阅webrtc-uwp PeerCC项目。其开发基础来源于https://webrtc.org上的原始PeerConnection示例。

RTCStartupDemo:一个简单易用的RTCPQPServing实现,在多个平台上(Web/Android/iOS/Windows)提供了完整的源码示例。该开源项目旨在帮助初学webrtc的技术人员快速上手并完成基础应用开发。项目包含一个基于socket.io协议的RTCPQPServing实例,并附带详细的使用文档和示例代码以促进学习和实践操作。

meething-ml-camera :为基于 Web 的视频通话,通过机器学习生成虚拟形象

ShareDrop 是一种采用 WebRTC 技术实现的 Airdrop 方案,在该方案中我们特别适用于文件在端到端设备之间直接传输。其中主要采用了 WebRTC 系统中的 peer-to-peer 文件传输机制以及相关的通信协议,并结合 Firebase 提供的相关服务功能

ShareDrop借鉴了苹果AirDrop服务的思想打造了一个Web应用程序。
该应用无需将文件上传至任何服务器即可实现直接设备间传输。
采用WebRTC技术实现安全的点对点文件传输,并利用Firebase进行文件存在管理以及相关通信。ShareDrop无需任何设置即可实现本地网络中相同IP地址设备之间的文件共享——所有设备访问https://www.sharedrop.io后即可互相识别并共享文件。
此外,在不同网络间传输文件也十分便捷——只需点击右上方加号创建独特链接并邀请他人访问即可;当他们通过浏览器访问该链接时, 您将能够看到彼此的头像。
- 声网 Agora Web Demo :
