什么是WebRTC？

WebRTC是一个由Google发起的实时通讯解决方案，其中包含视频音频采集，编解码，数据传输，音视频展示等功能，我们可以通过技术快速地构建出一个音视频通讯应用。

虽然其名为WebRTC，但是实际上它不光支持Web之间的音视频通讯，还支持Android以及IOS端，此外由于该项目是开源的，我们也可以通过编译C++代码，从而达到全平台的互通。

从另一个角度来看，WebRTC 只是一个媒体引擎，上面有一个 JavaScript API，所以每个人都知道如何使用它（尽管浏览器实现仍然各不相同）。

WebRTC，网页即时通讯（英语：Web Real-Time Communication），是直接在 Web 浏览器内驱动实时通信（语音、视频和任意数据）方法的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准，并于 2011 年标准化。谷歌开源的一款产品。

简单的说：WebRTC 是一种 HTML5规范，他无需在浏览器中安装任何插件可以在网页内进行实时通信工作的开源技术，它直接在浏览器和设备之间添加实时媒体通信。

到 2016 年，估计安装了 20 亿个可以与 WebRTC 一起工作的浏览器。从流量的角度来看，仅浏览器通信就估计每周传输超过 10 亿分钟和 500 TB 的数据。

WebRTC的出现使实时通信技术得以广泛应用。 WebRTC制定、实现了一套统一且完 整的实时通信标准，并将这套标准开源。这套标准包含了实时通信技术涉及的所有内容， 使用这套标准，开发人员无须关注音视频编解码、网络连接、传输等底层技术细节，可以 专注于构建业务逻辑，且这些底层技术是完全免费的。

WebRTC统一了各平台的实时通信技术，大部分操作系统及浏览器都支持 WebRTC, 无须安装任何插件，就可以在浏览器端发起实时视频通话。WebRTC技术***初为Web打造，随着 WebRTC自身的演进，目前已经可以将其应用于各种应用程序。

---------------------------------------

webrtc推流和拉流

其实可以简要的理解为推流就是直播端，而拉流就是客户端哦

推流：将直播的内容推送至服务器的过程。即指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。“推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中***常用的流传输协议。***通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。

拉流：指服务器已有直播内容，用指定地址进行拉取的过程。即是指服务器里面有流媒体视频文件，这些视频文件根据不同的网络协议类型（如RTMP、RTSP、HTTP等）被读取的过程，称之为拉流，说的简单点，你观看优酷视频就可以看成是拉流，视频文件存储在优酷的服务器上面，你通过HTTP（或者RTMP/RTSP）协议，也就是网页的形式去获取视频观看，这就是拉流的过程，在这个过程中有三个要素：1-服务器【提供视频文件存储的地方】 2-传输协议【就是你要通过什么方式传输视频】3-读取终端【就是通过什么播放出来】

---------------------------------------

WebRTC 协议

传输层协议

WebRTC实时通信传输音视频的场景，讲究的是实时，当下，处理音频和视频流的应用一定要补偿间歇性的丢包，所以实时性的需求是大于可靠性的需求的。

如果使用TCP当传输层协议的话，如果中间出现丢包的情况，那么后续的所有的包都会被缓冲起来，因为TCP讲究可靠、有序，如果不清楚的朋友可以去看我上一篇关于TCP的内容讲解，web知识梳理。而UDP则正好相反，它只负责有什么消息我就传过去，不负责安全，不负责有没有到达，不负责交付顺序，这里从底层来看是满足WebRTC的需求的，所以WebRTC是采用UDP来当它的传输层协议的。

当然这里UDP只是作为传输层的基础，想要真正的达到WebRTC的要求，我们就要来分析在传输层之上，WebRTC做了哪些操作，用了哪些协议，来达到WebRTC的要求了。

RTCPeerConnection通道

RTCPeerConnection代表一个由本地计算机到远端的WebRTC连接。 该接口提供了创建，保持，监控，关闭连接的方法的实现，简而言之就是代表了端到端之间的一条通道。api调用上面代码里已经看到了，接下来我们就一点点的来剖析这条通道都用了哪些协议。

P2P内网穿透

上面我们也提到了UDP其实只是在IP层的基础上做了一些简单封装而已。而WebRTC如果要实现端到端的通信效果的话，必定要面临端到端之间很多层防火墙，NAT设备阻隔这些一系列的问题。之前我试过写了原生的webrtc 发现只要不在同一段局域网下面，经常会出现掉线连不上的情况。相同的道理这里就需要做 NAT 穿透处理了。

NAT穿透是啥，在讲NAT穿透之前我们需要先提几个概念：

公有IP地址是在Internet上全局***的IP地址，仅有一个设备可能拥有公有IP地址。

私有IP地址是非全局的***的IP地址，可能同时存在于很多不同的设备上。私有IP地址永远不会直接连接到internet。那私有IP地址的设备如何访问网络呢？

就是这个NAT（NetWork Address Translation），它允许单个设备（比如路由器）充当Internet（公有IP）和专有网络（私有IP）之间的代理。所以我们就可以通过这个NAT来处理很多层防火墙后那个设备是私有IP的问题。

路通了，那么就有另一个问题了，两个WebRTC客户端之间，大概率会存在A不知道B的可以直接发送到的IP地址和端口，B也不知道A的，那么又该如何通信呢？

这就要说到ICE了，也就是交互式连接建立。ICE允许WebRTC克服显示网络复杂性的框架，找到连接同伴的***途径并连接起来。

在大多数的情况下，ICE将会使用STUN服务器，其实使用的是在STUN服务器上运行的STUN协议，它允许客户端发现他们的公共IP地址以及他们所支持的NAT类型，所以理所当然STUN服务器必须架设在公网上。在大多数情况下，STUN服务器仅在连接设置期间使用，并且一旦建立该会话，媒体将直接在客户端之间流动。

具体过程让我们来看图会更清楚，WebRTC两个端各自有一个STUN服务器，通过STUN服务器来设置连接，一旦建立连接会话，媒体数据就可以直接在两个端之间流动。

刚才也说了大多数的情况，如果发生STUN服务器无法建立连接的情况的话，ICE将会使用TURN中继服务器，TURN是STUN的扩展，它允许媒体遍历NAT，而不会执行STUN流量所需的“一致打孔”，TURN服务器实际上在WebRTC对等体之间中继媒体，所以我这里理解的话使用TURN就很难被称为端对端之间通信了。 同样，我们画个图来形容TURN中继服务器的数据流动方式

TURN 是在任何网络中为两端提供连接的***可靠方式，但现实情况下运维 TURN 服务器的投入也很大。因此，***在其他直连手段都失败的情况下，再使用 TURN。 所以一般情况下每个WebRTC解决方案都会准备好支持这两种服务类型，并设计为处理TURN服务器上的处理要求。

媒体协议

WebRTC 以完全托管的形式提供媒体获取和交付服务:从摄像头到网络，再从网络到屏幕。 从上面的Android demo中我们可以看到，我们除了一开始制定媒体流的约束以外，编码优化、处理丢包、网络抖动、错误恢复、流量、控制等等操作我们都没做，都是WebRTC自己来控制的。这里WebRTC 是怎么优化和调整媒体流的品质的呢? 其实WebRTC 只是重用了 VoIP 电话使用的传输 协议、通信网关和各种商业或开源的通信服务:

安全实时传输协议(SRTP，Secure Real-time Transport Protocol) 通过 IP 网络交付音频和视频等实时数据的标准安全格式。

安全实时控制传输协议(SRTCP，Secure Real-time Control Transport Protocol) 通过 SRTP 流交付发送和接收方统计及控制信息的安全控制协议。

数据协议

我们都知道UDP是不安全的，但是WebRTC要求所有传输的数据（音频、视频和自定义应用数据）都必须加密，所以这里就要引入一个DTLS协议的概念。

DTLS说白了，其实就是因为TLS无法保证UDP上传输的数据的安全，所以在现存的TLS协议架构上提出了扩展，用来支持UDP。其实就是TLS的一个支持数据报传输的版本

既然知道了DTLS可以说是TLS的扩展版以后，我们再来看看dtls解决了哪些问题。首先先来看TLS的问题，刚才我们也提到了TLS不能直接用于数据报环境，主要的原因是包可能会出现丢失或者重排序的情况，而TLS无法处理这种不可靠性，而无法处理这种不可靠性就带来了两个问题：

TLS无法对某个记录单独解密，什么意思呢？如果A和B之间传递消息，消息以1到10依次为序列号，如果消息5没收到，那么6以后的消息都会报错，这里无法通过TLS的完整性校验，而且如果顺序不对，也无法通过TLS的完整性校验。

TLS握手层假定握手消息是可靠投递的，如果消息丢失则会中断。

那么DTLS是如何在尽可能与TLS相同的情况下解决以上两个问题的呢？

首先在DTLS中，每个握手消息都会在握手的时候分配一个序列号和分段偏移字段，当收消息的那一方收到一个握手消息的时候，会根据这个序列号来判断是否是期望的下一个消息，如果不是则放入队列中，这样就满足了有序交付的条件，如果顺序不对就报错，跟TLS一样。而分段偏移字段是为了补偿UDP报文的1500字节大小限制问题。

至于丢包问题，DTLS采用了两端都使用一个简单的重传计时器的方法，还是上面序列号为1到10的例子，如果A发给B一个序列号为5的消息，然后希望从B那里获取到序列号为6的消息，但是没收到，超时了，A就知道他发的5或者B给的6这个消息丢失了，然后就会重新发送一个重传包，也就是5这个消息。

为保证过程完整，A和B两端都要生成自已签名的证书，而WebRTC会自动为每一端生成自已签名的证书，然后按照常规的 TLS 握手协议走。

DataChannel

除了传输音频和视频数据，WebRTC 还支持通过 DataChannel API 在端到端之间传 输任意应用数据。DataChannel 依赖于 SCTP(Stream Control Transmission Protocol，流控制传输协议)，而 SCTP 在两端之间建立的 DTLS 信道之上运行的。

DataChannel api调用和WebSocket类似，上面的Android项目中我们已经讲过了，接下来我们来详细讲下DataChannel所依赖的SCTP协议。

SCTP

SCTP同时具备了TCP和UDP中***的功能：面向消息的 API、可配置的可靠性及交付语义，而且内置流量和拥塞控制机制。

因为本身UDP相对TCP来说比较简单，之前也提到UDP只是对IP层的一个简单封装而已，所以这里我们就通过比较TCP和SCTP的区别来简单的讲讲SCTP到底是什么东西和为什么具备TCP和UDP两者***的功能。

TCP是单流有序传输，SCTP是多流可配置传输，TCP在一条连接中可以复用TCP连接，是单流的，而且是有顺序的，如果一条消息出了问题的话，后面的所有消息都会出现阻塞的情况，强调顺序。而SCTP可以区分多条不同的流，不同的流之间传输数据互不干扰，在有序和无序的问题上，SCTP是可配置的，又可以像TCP那样交付次序可序化，也可以像UDP那样乱序交付。

TCP是单路径传输，SCTP是多路径传输 SCTP两端之间的连接可以绑定多条IP，只要有一条连接是通的，那么就是通的，熟悉TCP的朋友应该都知道，TCP之间只能用一个IP来连接。

TCP连接建立是三次握手，SCTP则需要四次握手，SCTP的四次握手比TCP多了一个步骤：server端在收到连接请求时，不会像TCP三次握手那样子收到请求消息以后立马分配内存，将其缓存起来，而是返回一个COOKIE消息。 client端需要回送这个COOKIE，server端对这个COOKIE进行校验以后，从cookie中重新获取有效信息（比如对端地址列表），两端之间才会连接成功。

TCP以字节为单位传输，SCTP以数据块为单位传输 块是SCTP 分组中的***小通信单位，核心概念与HTTP 2.0分帧层中的那些概念基本一样

ok，到这里基本把WebRTC通信协议的应用，以及要用到的协议啊概念啊什么的都过了一遍，要实现低延迟的，端到端的通信传输不是一件容易的事情。相信随着WebRTC不断的完善，支持的端也会越来越多，性能也会越来越完善。

---------------------------------------

WebRTC 如何工作

WebRTC 是一个媒体引擎，上面有一个 JavaScript API，所以每个人都知道如何使用它（尽管浏览器实现仍然各不相同）

（1）紫色部分是Web开发者API层；

（2）蓝色实线部分是面向浏览器厂商的API层

（3）蓝色虚线部分浏览器厂商可以自定义实现

---------------------------------------

WebRTC的历史

WebRTC( Web Real-Time- Communication)是一个谷歌开源项目，它提供了一套标准API,使Web应用可以直接提供实时音视频通信功能，不再需要借助任何插件。原生通信 过程采用P2P协议，数据直接在浏览器之间交互，理论上不需要服务器端的参与。

“为浏览器、移动平台、物联网设备提供一套用于开发功能丰富、高质量的实时音视频 应用的通用协议”是WebRTC的使命。 WebRTC的发展历史如下。

2010年5月，谷歌收购视频会议软件公司GIPS,该公司在RTC编码方面有深厚的 技术积累。

2011年5月，谷歌开源 WebRTC项目。

2011年10月，W3C发布***个 WebRTC规范草案。

2014年7月，谷歌发布视频会议产品 Hangouts,该产品使用了 WebRTC技术。

2017年11月， WebRTC进入候选推荐标准(Candidate Recommendation,cr 阶段。

---------------------------------------

传统的客户端和服务器通信：

---------------------------------------

应用WebRTC 技术的客户端和服务器通信：

以某种方式从一个浏览器向另一个浏览器发送信号，一旦建立联系，可以直接在两个浏览器之间向它们发送消息——而 Web 服务器永远不会接触这些消息。

这就是为什么许多人将 WebRTC 称为点对点技术。或简称 P2P。因为浏览器可以直接通信。

---------------------------------------

WebRTC服务器架构

从技术实现的角度讲，在浏览器之间进行实时通信需要使用很多技术，如音视频编解 码、网络连接管理、媒体数据实时传输等，还需要提供一组易用的API给开发者使用。这 些技术组合在一起，就是 WebRTC技术架构，如下图所示。

WebRTC技术架构的顶层可以分为两个部分。一部分是Web API，一组JavaScript接口，由W3C维护，开发人员可以使用这些API在浏览器中创建实时通信应用程序。另一部分是适 用于移动端及桌面开发的 libwebrtc,即使用 WebRTC++源码在 Windows、 Android、ios 等平台编译后的开发包，开发人员可以使用这个开发包打造原生的 WebRTC应用程序。

第二层是 WebRTC++API,它是 Web API和 libwebrtc的底层实现。该层包含了连接 管理、连接设置、会话状态和数据传输的API。基于这些API,浏览器厂商可以方便地加入 对 WebRTC的支持。

WebRTC规范里没有包含信令协议，这部分需要研发人员依据业务特点自行实现 。

WebRTC支持的音频编码格式有OPUS和G.711,同时还在音频处理层实现了回音消除 及降噪功能。 WebRTC支持的视频编码格式主要有VP8和H264(还有部分浏览器支持VP9 及H265格式), WebRTC还实现了 Jitter Buffer防抖动及图像增强等高级功能 。

在媒体传输层，WebRTC在UDP之上增加了3个协议。

数据包传输层安全性协议(DTLS)用于加密媒体数据和应用程序数据。

安全实时传输协议(SRTP)用于传输音频和视频流。

流控制传输协议(SCTP)用于传输应用程序数据。

WebRTC借助ICE技术在端与端之间建立P2P连接，它提供了一系列API,用于管理连接。 WebRTC还提供了摄像头、话筒、桌面等媒体采集API,使用这些API可以定制媒体流。

架构组件

Your Web App

Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。

Web API

面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用，需要注意的是可能在不同浏览器中API接口名会不太一样, 所以推荐使用这个JS适配器来协调各个浏览器的不同接口。

这些API可分成Media API、 RTCPeerConnection、Peer-to-peer Data API三类

Media API

MediaStream：MediaStream用来表示一个媒体数据流。

MediaStreamTrack：在浏览器中表示一个媒体源。

RTCPeerConnection

RTCPeerConnection：一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。

SDP: 用来描述当前连接者想要传输的内容，支持的协议类型，支持的编解码类型等。

RTCIceCandidate：表示一个ICE协议的候选者，简单的说，就是目标节点的IP以及端口。

RTCIceServer：表示一个ICE Server，其主要用于当前主机的IP发现，通过和ICE Server通讯，我们会得到一组可供连接使用的IP:Port候选值，双方通过交换ICE候选值来建立起连接。

Peer-to-peer Data API

DataChannel：数据通道( DataChannel)接口表示一个在两个节点之间的双向的数据通道，该通道可以设置成可靠传输或非可靠传输 。

WebRTC Native C++ API

本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。

Transport / Session

传输部分可基于TCP/UDP，会话层组件采用了libjingle库的部分组件实现

AudioEngine

音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。

VideoEngine

视频引擎是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

通讯内容的确立        

首先，两个客户端（Alice & Bob）想要创建连接，一般来说需要有一个双方都能访问的服务器来帮助他们交换连接所需要的信息。有了交换数据的中间人之后，他们首先要交换的数据是SessionDescription（SD），这里面描述了连接双方想要建立怎样的连接。

连接建立过程        

介绍完ICE框架中各个独立部分的含义之后，在让我们来看一看整个框架是如何工作的。

1.连接双方（Peer）通过第三方服务器来交换（Signalling）各自的SessionDescription数据。

2.连接双方（Peer）通过STUN协议从STUN Server那里获取到自己的NAT结构，子网IP和公网IP，端口，这里的IP和端口对我们称之为ICE Candidate。

3.连接双方（Peer）通过第三方服务器来交换（Signalling）各自ICE Candidates，如果连接双方在同一个NAT下那他们仅通过内网Candidate就能建立起连接，反之如果他们处于非对称型NAT下，就需要STUN Server识别出的公网Candidate进行通讯

4.如果仅通过STUN Server发现的公网Candidate仍然无法建立连接，换句话说就是连接双方（Peer）中至少有一方处于对称NAT下，这就需要处于对称NAT下的客户端（Peer）去寻求TURN Server提供的转发服务，然后将转发形式的Candidate共享（Signalling）给对方（Peer）。

5.连接双方（Peer）向目标IP端口发送报文，通过SessionDescription中涉及的密钥以及期望传输的内容，建立起加密长连接。

---------------------------------------

WebRTC 浏览器与终端兼容性

WebRTC 在所有现代浏览器中都可用。Google Chrome、Mozilla Firefox、Apple Safari 和 Microsoft Edge 都支持它。也可以将其集成到应用程序或嵌入式设备中，而完全不需要浏览器。

据统计，大部分浏览器都实现了对WebRTC的支持，各浏览器支持情况如下。

Firefox版本22+

Chrome版本23+

Safari版本11+

iOS Safari版本11+

Edge版本15+

Opera版本18+

Android Browser版本81+

Chrome for Android版本84+

Firefox for Android版本68+

IE不支持

Android和iOS原生应用都支持 WebRTC,可以使用原生SDK开发跨平台的 WebRTC 应用。 Android WebView自36版本之后，提供了对 WebRTC的支持，这意味可以使用 WebRTC API开发 Android混合App注意，一些手机厂商对部分 Android版本里的 Web View进行了裁剪，导致不能使用 WebRTC,这时候下载并安装***的 Web View即可。

iOS Web View目前还不支持 WebRTC,但是可以使 cordova的插件 cordova-plugin- iosrtc在混合App中使用 WebRTC。

WebRTC目前处于活跃开发阶段，各个浏览器的实现程度不一样。为了解决兼容性的 问题，谷歌提供了 adapter库。

---------------------------------------

应用场景：媒体和访问

目前，WebRTC 在视频通话中广受欢迎，但不限于视频语音功能。WebRTC 所做的是允许访问设备。您可以访问设备的麦克风、手机或笔记本电脑上的摄像头——或者它本身也可以是屏幕。您可以捕获用户的显示，然后远程共享或记录该屏幕。无论它做什么都是实时的，可以实现实时交互。WebRTC 不仅限于语音和视频。它允许发送任何类型的任意数据。

更多应用场景

1，统一通信——语音和视频通话、1:1 或小组会议、远程协助、直播；

2，远程操作——远程医疗、驾驶汽车、无人机、运输；

3，云游戏——在云中渲染游戏的视觉效果并将其实时发送给玩家

4，云主机 —— 操作远程机器（高性能机器或高度安全/配置的机器），就像它是本地机器一样

5，虚拟空间和虚拟世界——在 2D 或 3D 合成渲染的虚拟环境中与人们会面

---------------------------------------

WebRTC源码详解

WebRTC 是 Chromium源码third_party的一部分。

webrtc框架图

如果按照通常层次化的思维来组织，从下到上，大概分以下几个层次：

OS 跨平台适配、硬件设备访问、第三方库 Wrapper 层

包括网络层、操作系统 API 的跨平台封装，音频设备、视频设备封装，音频、视频 codec，DTLS 的第三方实现等。

网络传输层

这里包括 candidate 收集，stun/turn 协议的实现，dtls、rtp 网络连接的建立，sctp 连接的建立等。

通道层

主要包含传输通道也就是 BaseChannel 层 和 媒体通道 也就是 MediaChannel 层。BaseChannel 是和 PeerConnection、Transport 层对接。MediaChannel 实现其实在音视频引擎里面，是 BaseChannel 和引擎的桥梁。

RTP_RTCP 主要是流控

Audio Engine、Video Engine 是音视频引擎层，音视频处理。

音视频编解码器，这也是 WebRTC 自己的一个抽象，真正的编解码库还是依赖第三方库。

PeerConnection、MediaStream 主要是对 jsep 协议的实现。

PeerConnectionInterface 是一个对外抽象接口类设计。

源码结构：

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 流的抽象接口，属于视频引擎的一部分。