aggs1990的专栏

在ubuntu和win10开发测试一段时间了，但总在存在平台特性的问题，所以准备将程序移植到macOS上测试，同步进行三个主要桌面系统开发，本教程记录下环境搭建过程。

若只是实现一对一通信，仅使用webrtc就足够了。但有时间需要进行多个人的直播会议，当人比较多时，建议使用一个流媒体服务器，笔者使用的是SRS。这个开源项目资料比较全，笔者仅在此记录下搭建过程。

win10开发测试已经一段时间了，最近将程序移植到ubuntu测试了下，改动不是很大，本教程记录下环境搭建过程。

注意，win10的sdk需要是10.0.22621.0，其他版本可能导致编译不通过，而且这个版本会根据webrtc源码的更新而发生变化。depot_tools是包含下载、编译的相关工具，需要先下载并配置它，才能继续后面的操作。3.安装VS2022，笔者使用的是社区版，并选中C++相关，笔者设置如下。可能需要执行gclient sync ，直到出现如下提示，才代表同步成功。很多小伙伴，想需要查看下，有哪些参数可以设置，可以使用如下命令查看。2.在cmd中设置临时环境变量，以下是笔者设置的，可参考下。

WebRTC编译后会在src\out\Default\obj和rc\out\Release\obj目录下生成整个WebRTC工程的静态库：webrtc.lib，链接下这个就可以了。注意，win10的sdk需要是10.0.20348.1，其他版本可能导致编译不通过，而且这个版本会根据webrtc源码的更新而发生变化。depot_tools是包含下载、编译的相关工具，需要先下载并配置它，才能继续后面的操作。3.安装VS2019，笔者使用的是社区版，并选中C++相关，笔者设置如下。整个目录太大，不方便上传，

webrtc源码目录下，有个examples目录，里面放置着官方的示例，其有peerconnection示例。2.在/examples/peerconnection/client/main.cc文件中，修改如下部分。1.在/examples/peerconnection/client/main.cc文件中，添加如下部分。服务端程序可以正常启动，但客户端程序旧版可以正常运行，最新版无法正常运行，需要修改下部分文件。指引，这两个示例是开发学习webRTC的敲门砖，建议新入坑的小伙伴仔细研究下相关代码。

因工作原因，很长时间没更新相关文档了，笔者之前测试时，一直使用示例自带的公网中转服务器。考虑到后期项目需要，笔者在线搭建一个coturn服务器测试，供有需要的小伙伴使用。

网络仿真框架提供了在不同客户端（包括WebRTC对等连接客户端）之间模拟网络行为的能力。使用预定义的实现，该实现可以使用参数（如数据包丢失、带宽、延迟等）进行配置。自定义实现从概念上讲，该框架提供了定义多个端点和用于连接它们的路由的能力。Real time实时模拟时间管理器有一个专用的任务队列，它通过所有网络路由将所有数据包从发送方传送到接收方。此任务队列行为由webrtc::TimeController决定，它基于实时或模拟时间模式。该网络在IP级别上运行，目前仅支持UDP。

implements​DefaultVideoQualityAnalyzer实现了webrtc::VideoQualityAnalyzerInterface，是webrtc视频质量分析器的主要实现。为了正确操作，它需要在每个步骤上接收视频帧：1.在捕获帧时，分析器将为帧生成一个唯一的ID，调用方应将其附加到该ID上。2.在帧进入编码器之前。3.在帧被编码之后。4.在帧被接收之后并且紧接在帧进入解码器之前。5.紧接在帧被解码之后。6.渲染帧时。

is​webrtc::webrtc_pc_e2e::PeerConnectionE2EQualityTestFixture的主要实现是webrtc::webrtc_pc_e2e::PeerConnectionE2EQualityTest。​此外，它还保留了对webrtc::TimeController的引用，用于创建所有必需的线程、任务队列、任务队列工厂和与时间相关的对象。

该框架还封装了视频编码器/解码器，并将其注入到webrtc::PeerConnection中，以测量视频质量，在捕获的帧和渲染的帧之间执行1:1的帧匹配，而不需要任何额外的输入视频要求。然后，和前面的选项一样，您需要将结果管道传输到绘图仪脚本中。​1.使用webrtc::TestMain::Create（）作为主函数实现，例如使用test/test_main.cc作为测试的主函数。在这种情况下，二进制文件将具有flag-plot，可以在其中提供要绘制的度量列表，或者指定all来绘制所有可用的度量。

可以启用RTC事件日志来捕获有关发送和接收的数据包以及某些WebRTC组件的内部状态的深入信息。这些日志有助于了解网络行为，并调试连接、带宽估计和音频抖动缓冲区方面的问题。

​PeerConnection是WEBRTC规范中Javascript对象“RTCPeerConnection”的C++级实现。这些类型在API中可见。

视频编码是将未压缩的视频帧流编码为压缩比特流的过程，其比特率低于原始流的比特率。

Resource当资源发出当前未充分使用或过度使用的信号时，就会发生自适应。当过度使用时，视频质量会降低，而当未充分使用时，则视频质量会提高。目前有两个维度可以调整质量：帧速率和分辨率。所调整的维度是基于视频轨道的降级偏好。

APM负责将语音增强效果应用于麦克风信号。VoIP呼叫需要这些效果，并且一些示例包括回声消除（AEC）、噪声抑制（NS）和自动增益控制（AGC）。APM的API位于[/modules/audio_processing/include]中[APM是使用[AudioProcessingBuilder]创建的[APM既可以作为WebRTC本机管道的一部分使用，也可以独立使用。]生成器，允许对其进行自定义和配置。

​WebRTC音频混合器模块负责将多个传入音频流（源）混合为单个音频流（混音）。它适用于10ms帧，支持高达48kHz的采样率和高达8个音频通道。API是在API/audio/audio_mixer.h中定义的，包括AudioMixer::Source的定义，描述了传入的音频流，以及AudioMixer::Source的定义，后者对AudioMiixer::Source对象的集合进行操作以生成混音。

​音频发送音频帧，每个帧应始终包含10毫秒的数据，通过Add10MsData（）提供给音频编码模块。音频编码模块使用所提供的音频编码器对音频帧进行编码，并将数据传递到预先注册的音频分组回调，该回调应该将编码的音频打包成RTP分组并通过传输发送。音频网络适配器为音频编码器（目前仅限于Opus）提供附加功能，以使音频编码器适应网络条件（带宽、丢包率等）。​音频接收音频分组通过IncomingPacket（）提供给音频编码模块，并由音频抖动缓冲器（NetEq）处理，其中包括对分组的解码。

​ADM负责驱动WebRTC中的输入（麦克风）和输出（扬声器）音频，API在audio_device.h中定义。and/sdk/and/sdk/and​ADM实现位于WebRTC存储库中的两个不同位置：/modules/audio_device/和/sdk/。iOS和Android的最新实现可以在/sdk/./modules/audio_device/下找到，其中包含移动平台的旧版本，也包括Linux、Windows和Mac OSX等桌面平台的实现。

NetEq是音频抖动缓冲和数据包丢失遮瑕膏。抖动缓冲器是一种自适应抖动缓冲器，这意味着缓冲延迟会根据网络条件不断优化。它的主要目标是确保来自网络的传入音频分组的平稳播放，同时保持尽可能低的延迟，同时具有少量的音频伪影（对分组的原始内容的更改）。

带节奏的发送器，通常被称为“起搏器”，是WebRTC RTP堆栈的一部分，主要用于平滑发送到网络上的数据包流。

The​webrtc::SctpTransport类封装了一个SCTP关联，并向webrtc用户公开了该关联的一些属性（例如Chrome）。​SctpTransport用于支持数据通道，如对等数据API的WebRTC规范中所述。​公共接口（webrtc::SctpTransportInterface）暴露了一个观察者接口，用户可以在其中定义一个回调，以便在SctpTransport的状态发生变化时调用；此回调是在网络线程上调用的（在PeerConnectionFactory初始化期间设置）。

​WebRTC通过RFC 3711中描述的安全实时协议（SRTP）强制对媒体进行加密。​WebRTC中的密钥协商使用在RFC 5764中描述的DTLS-SRTP进行。已实现较旧的SDES协议，但默认情况下未启用。​通过将PeerConnections的disable_encryption选项设置为true，可以出于调试目的启用未加密的RTP。

​WebRTC使用RFC3550中描述的RTP协议来传输音频和视频。媒体使用SRTP进行加密。

​W3C WebRTC API将其表示为DtlsTransport。line.DTLS握手发生在ICE传输变为可写并找到有效对之后。它导致为DTLS-SRTP导出一组密钥，以及将远程证书的指纹与SDP a=fingerprint：行中给出的指纹进行比较。本文档概述了DTLS是如何实现的，即以下类是如何交互的。

ICE (​ICE（链路）在两个客户端（p2p）之间或客户端和服务器之间提供不可靠的分组传输。本文档概述了ICE是如何实现的，即以下类是如何交互的。cricket::IceTransportInternal-是执行ICE（管理端口、候选端口、发送/接收数据包的连接）的接口。该接口由cricket::P2PTransportChannel实现。andcricket::PortInterface表示一种本地通信机制，可用于创建与其他客户端类似机制的连接。有4种and。

其他平台不受官方支持（这意味着它们没有CI覆盖范围），但WebRTC团队欢迎使用补丁来保持WebRTC与它们的合作。

​在内部，时间是使用webrtc::Timestamp类表示的。这表示分辨率为1微秒的时间，使用64位整数，并根据需要提供毫秒或秒的转换器。所有的时间戳都需要从系统单调时间开始测量。没有指定epoch（因为我们不能总是知道系统时钟是否正确），但无论何时需要绝对epoch，都会使用Unix时间epoch（1970年1月1日格林尼治标准时间0:00）。从/到其他格式（例如毫秒、NTP时间、时间戳字符串）的转换应尽可能靠近需要该格式的接口。

h.cc.h。

代码的一些旧部分以各种方式违反了样式指南。如果对此类代码进行了较大的更改，请考虑首先在单独的CL中对其进行清理。

此目录中的头文件构成WebRTC库的API，该库旨在供客户端应用程序使用。此API设计用于在多线程运行时之上使用。公共API函数被设计为从单个线程*（“客户端线程”）调用，并且可以对需要进行活动的线程进行内部调度。这些线程可以由客户端传入，通常作为工厂构造函数的参数，或者如果使用不带线程的工厂构造函数，则可以由库创建。许多函数被设计为以异步方式使用，其中调用一个函数来启动一个活动，并在活动完成时调用回调，或者在感兴趣的事件发生时对观察者对象调用处理程序函数。

apibelow.​目前，还可以在以下旧版API目录中使用头文件和构建文件，但请参阅下面的免责声明。media/basepcrtc_base​虽然API和旧版API目录中的文件、类型、函数、宏、构建目标等有时会发生不兼容的更改，但这些更改将提前通知discuss-webrtc@googlegroups.com，并且将提供迁移路径。在上表中未列出的目录中，不兼容的更改可能随时发生，并且不会公布。

WebRTC库的公共API由API/目录及其子目录组成。webrtc用户不应依赖任何其他文件。

and​目前支持的平台有Windows、Mac OS X、Linux、Android和iOS。有关特定于这些移动平台的构建说明和示例应用程序，请参阅Android和iOS页面。

1.1.安装Chromium工具。2.​在Windows上，仓库工具将在第一次gclient同步期间下载一个特殊版本的Git。在Mac和Linux上，需要自己安装Git。

谷歌计划在未来几个季度将Chrome的WebRTC实现从当前的SDP格式（称为“B计划”）过渡到符合标准的格式（“统一计划”，ietf rtcweb jsep草案）。该计划包括5个阶段和一个暂时的API功能。

在为WebRTC应用程序编写自动测试时，可以为浏览器启用一些有用的配置，使开发和测试更容易。

一旦TURN服务器在线可用，所需要的就是客户端应用程序使用正确的RTCConfiguration。下面的代码片段说明了RTCPeerConnection的示例配置，其中TURN服务器的主机名为my-TURN-server.mycompany.com，并在端口19403上运行。当连接到TURN服务器时，这些是必需的。该术语意思是围绕NAT使用中继的接力，它是一种用于中继网络流量的协议。目前，TURN服务器有几种在线选项，既可以作为自托管应用程序（如开源COTURN项目），也可以作为云提供的服务。

on aobject.WebRTC标准还涵盖了通过RTCPeerConnection发送任意数据的API。这是通过对RTCPeerConnection对象调用createDataChannel（）来完成的，该对象返回一个RTCDataChannel对象。channel远程对等端可以通过侦听RTCPeerConnection对象上的数据通道事件来接收数据通道。接收到的事件属于RTCDataChannelEvent类型，并且包含一个通道属性，该属性表示对等端之间连接的RTCDataChannel。

如果不熟悉API，那么创建一个基于WebRTC技术的新应用程序可能会非常困难。在本节中，将通过解释一些常见用例和解决这些问题的代码片段，展示如何开始使用WebRTC标准中的各种API。