琅嬛福地

本篇博客介绍webrtc源码的下载与编译，以及推荐webrtc学习资料。源码下载电脑环境：win10/win11 64bit，合理的上网环境，没有合理的网络环境无法拉取、下载webrtc代码和工具，宽带速度要快，尽量50M. 主要步骤如下：(1) 安装git(2) 打开cmd控制台，下载google开发工具depot_tools:git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git(3) 新建一个目

Google 开源项目风格指南 (中文版)：https://zh-google-styleguide.readthedocs.io/en/latest/英文版：http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml中文版：http://zh-google-styleguide.readthedocs.org/en/latest/google-cpp-styleguide/google c++ 编码规范：http://blog.csd

什么是googletest?googletest简介​GoogleTest 是 Google 的 C++ 测试和模拟框架，可以帮助程序员测试C++程序的结果预期，GoogleTest 的代码用cmake管理，可以使用cmake进行编译程dll在程序中使用。googletest一般也可以简称为gtest, 最新版本GoogleTest 需要符合 C++11 标准或更新标准的代码库和编译器。​ gtest官网：https://google.github.io/googletest/​

windows上编译wrbrtc可能会出现KeyError: 'WINDOWSSDKDIR'这时需要设置windows sdk的路径，例如我的设置set WINDOWSSDKDIR=D:\Windows Kits\10当你在windows上搜索Windows Kits\10时可能会有多个，我也是试了很多次，才找到正确的目录，该目录内容如下不知是否正确，反正我的webrtc用vs2019编译ok了，1144个工程。...

webrc信号槽介绍  webrtc的很多类都是用了信号槽机制，类似于Qt的信号槽，webrtc中的信号槽如下：  PeerConnectionClient类class PeerConnectionClient : public sigslot::has_slots<>, public rtc::MessageHandler { public: enum State { NOT_CONNECTED, RESOL

人类最高质量的客户端项目chrome源码下载与编译对于客户端应用来说，google chrome应该是人类最高质量的客户端项目了，如果是前端开发对chrome应该很熟悉，但是chrome的源码你们看过吗，今天我来教大家怎么获取chrome源码，并用vs2019进行编译，9800多个C++项目，是不是让人窒息，作为C++程序员有没有感觉到巨大挑战。chrome git仓库：https://github.com/chromium/chromiumchrome源码下载（1）环境准备win10-64 ，预留

在webrtc大概2022之后的版本，会出现无法连接peerconnection_server的现象，如下图：在peerconnection_client界面点击Connect无法连接server.

在windows上编译webrtc时可能出现如下错误：Exception: No supported Visual Studio can be found. Supported versions are: 16.0 (2019), 15.0 (2017).在上面也有提示File "C:/webrtc/src/build/vs_toolchain.py", line 174, in GetVisualStudioVersion ' Supported versions are: %s.' ..

WebRTC 源码树包含超过 3 万个文件、横跨 6 大平台（Windows、macOS、Linux、iOS、Android、ChromeOS），其构建系统采用的是 Google 自研的 **GN（Generate Ninja）+ Ninja** 组合。与 CMake 不同，GN 是一套声明式的元构建系统（Meta-Build System），它只负责描述“构建目标是什么、依赖谁、用什么参数”，最终生成平台无关的 `.ninja` 构建描述文件；而 Ninja 则是一个极致高效的底层构建执行器，专注于“以最

WebRTC 源码树包含超过 3 万多个文件、数百个模块，其构建系统并非传统的 Makefile 或 CMake，而是 Google 自研的 **GN（Generate Ninja）+ Ninja** 组合。GN 负责用声明式语法描述目标、依赖和编译参数，生成平台无关的中间元数据；Ninja 则负责将这些元数据转换成极致并行的增量构建指令。理解这套系统的底层原理，是在真实工程中做**模块裁剪**、**编译参数定制**和**依赖治理**的前提。

  在进行RTC应用开发时，会有加入频道，其它用户加入频道，房间的流发生变化等操作，对于这些行为，需要有相应的通知，发给界面层，需要进行异步处理，例如当有用户加入房间时，就触发对应的回调函数返回加入的结果，而这个结果是用户层被动获取的，因为不知道什么时候加入成功，通过常会有一个virtual方法让界面层override获取结果。  webrtc源码提供了线程异步调用的实现，代码在rtc_base/rtc_base, 如下所示：webrtc的异步调用在头文件async_invoker.h中有相关的说明

Windows COM简介  webrtc的windows端代码，用到了很多COM技术，比如使用摄像头视频采集、音频设备管理等，都是使用windows最底层的COM技术，为了更好的熟悉webrtc windows端代码，需要对windows com技术有所了解，不然无法深入到底层，打通底层逻辑，自下而上，再自上而下，这样理解webrtc的代码才轻松一点。关于音视频的采集，可以参考我的OBS源码分析专栏，OBS是录制直播推流项目，会涉及到音视频的采集，底层也是com技术。  那么，COM组件到底是什么?C

  在rtc互动直播的项目中，必然有视频互动的功能，在pc端，那就得开启电脑得摄像头，采集摄像头数据，然后通过网络发送到对端，webrtc关于视频采集的模块在modules/video_capture.首先来看看video_capture.h文件，class VideoCaptureModule封装了设备枚举，开始采集，结束采集、打开摄像头，采集数据，编码等，webrtc都做好了，我们直接直接调用VideoCaptureModule即可完成电脑摄像头视频采集的相关操作。  注意该类的两个方法（1）视频

  音视频通话、桌面分享是各种会议软件、办公软件最基本的功能，实现这些功能，最基础的问题是，如何拿到摄像头、桌面或这窗口的数据，在本专栏的前面介绍了如何获取摄像头数据，本篇来介绍如何采集桌面和窗口，这也是webrtc的底层基石，下面来看看webrtc的基本架构图：  如果做过录制、播放、推拉流项目，那么看这张图，其实并不困难，从最底层往上看：（1）声音采集渲染：在windows上，采集声音必然要用到微软提供的音视频会话API，也就是wasapi，其实obs的源码很好的阐释了各个平台的音视频采集渲染技术

WebRTC（Web Real-Time Communication）作为一项革命性的实时通信技术，其核心在于实现浏览器或移动应用之间无需插件的点对点（Peer-to-Peer, P2P）音视频和数据通信。然而，在多人通信场景下，问题变得复杂。一个稳定、高效的WebRTC多人通信系统，其背后是一套精密的协议栈和架构设计。本章节将深入剖析WebRTC多人通信的三大核心支柱：信令交互、ICE协商以及媒体流传输与安全保障。信令交互是通信双方建立连接的“语言”，负责交换必要的元数据；

学习webrtc的第一步是学习PeerConnection，虽然现在的webrtc源码异常庞大，万事开头难，只要找好了入口，就可以进行摸索了，webrtc vs2019 c++项目目前我所用的版本一共有1286个子项目，如下图：在这篇文章之前，我介绍了webrtc的摄像头采集，桌面采集的方法，这些都是webrtc最基础的模块，没有他们就无法进行音视频通信，而webrtc最上层的PeerConnection接口依赖与摄像头采集，桌面采集等模块。PeerConnection是学习WebRTC的第一步，但是P

Network负责所有 socket I/O 与 ICE，Worker跑编解码、设备采样、音频 3A、Signaling承接 PeerConnection 公共 API 与 Observer 回调。理解三者职责与"跨线程任务投递"是写好 SDK、避免死锁和回调错乱的前提。

  peerconnection_client和peerconnection_server代码调试稍微比较麻烦，因为是两个项目，需要合理的打断点，不然调试不了。peerconnection_client的源码很有深度，除了webrtc的音视频网络传输外，用到了大量的C++高级用法，例如信号槽，不是只有Qt里才有信号槽，webrtc也是用了大量的信号槽；异步socket、工厂模式、单例模式、观察者模式、异步调用等等，在webrtc的源码里应有尽有，我也是看了webrtc的源码，才知道原来C++还可以这样玩。

本篇来聊一聊初始化InitializePeerConnection做了哪些工作，代码如下：bool Conductor::InitializePeerConnection() { RTC_DCHECK(!peer_connection_factory_); RTC_DCHECK(!peer_connection_); peer_connection_factory_ = webrtc::CreatePeerConnectionFactory( nullptr /* network

上一篇把的创建流程和依赖注入机制梳理清楚了。Factory 解决的是"怎么造出 PeerConnection"的问题，而本篇要深入的是"PeerConnection 被造出来之后，内部到底发生了什么"。目标不是背 API，而是帮助你知道它在真实 C++ Native WebRTC 项目中解决什么问题、源码应该从哪里看、线上问题应该怎么定位。WebRTC 的难点不只是概念多，而是这些概念会同时出现在 SDP、RTP、RTCP、线程、Stats 和业务回调里。

前面几篇已经把 WebRTC 的连接建立、安全传输和媒体通道梳理了一遍。从本篇开始，专栏会继续向更细的传输、媒体、工程封装和生产排查层深入。本文聚焦，目标不是背 API，而是帮助你知道它在真实 C++ Native WebRTC 项目中解决什么问题、源码应该从哪里看、线上问题应该怎么定位。WebRTC 的难点不只是概念多，而是这些概念会同时出现在 SDP、RTP、RTCP、线程、Stats 和业务回调里。只要能建立模块边界，再去读源码和写工程代码就会轻松很多。

在做Socket编程时，当要处理一个server对应多个client，这种可以每个客户端用一个线程来处理，但是客户端太多，程序的性能会降低。Windows提供了select模型，很好的处理了一对多的模型。select的申明如下：Int WSAAPI select(_In_ int nfds, //0,无意义_Inout_opt_ fd_set FAR * readfd...

webrtc peerconnection_server代码位置如下：这是一个C++控制台项目，可以单独提出来，只要把包含webrtc的头文件，链接库文件就可以编译了，下面介绍如何移植这个项目。一、创建vs2019 C++项目用vs2019创建C++控制台项目，编译模式设为x64，将webrtc的代码文件复制到项目中即可：二、包含webrtc头文件…\webrtc_sdk\include\webrtc…\webrtc_sdk\include\webrtc\third_party\abseil

WebRTC 标准本身不定义信令传输方式，但每一次成功的 P2P 连接背后，都离不开信令服务器对 SDP 会话描述、ICE 网络候选、房间状态和控制消息的可靠交换。与媒体数据通过 SRTP 直连不同，信令走的是完全不同的路径——它需要一个可靠的、低延迟的、支持服务器主动推送的全双工传输通道。本文从协议设计、状态机管理、C++ 工程实现三个层面，讲解如何设计一套生产可用的 WebSocket 信令系统。

信令服务器是 WebRTC 应用中“非 WebRTC 但必备”的核心组件。WebRTC 标准本身不定义信令传输方式，但每一次成功的 P2P 连接背后，都离不开信令服务器对 SDP 会话描述、ICE 网络候选、房间状态和控制消息的可靠交换。本文从协议设计、状态机管理、生产级 C++ 实现和集群部署四个层面，讲解如何搭建一个生产可用的信令服务器。

WebRTC 擅长低延迟互动（端到端 50~200ms），但连接数受限于 SFU 单机容量（百级下行）；直播 CDN（RTMP/HLS）擅长大规模分发（百万级观众），但延迟较高（HLS 8~20s）。转直播就是把两者的优势拼接起来：主播用 WebRTC 推流到 SFU，SFU 通过媒体网关把流转为 RTMP/HLS 推到 CDN，观众从 CDN 拉流观看。本文聚焦转直播的架构设计、协议转换原理、转码与直通决策、时间戳管理、C++ 工程实现以及生产排障。

WebRTC 转推直播让实时音视频流通过 CDN 分发给百万级观众，是互动直播、电商、教育、培训场景的"杀手锏"。WebRTC 擅长低延迟互动但连接数有限，CDN（RTMP/HLS）擅长大规模分发但延迟较高，转推就是两者的桥梁。本文从协议差异、时间戳管理、转码决策、完整推流管线到生产实践展开。

Simulcast（Simultaneous Broadcast）是 WebRTC 在 SFU 架构下解决"带宽异构"问题的核心技术：发送端同时编码并发送多路不同分辨率/码率的视频流，SFU 根据每个下行订阅者的网络带宽和终端能力，智能选择最合适的一路转发，而不需要做服务端转码。本文将深入剖析 Simulcast 的编码流水线、SDP 协商机制、SFU 选择策略以及 C++ 工程实现。

在WebRTC的多人音视频通话、在线会议、直播连麦等场景中，服务端或客户端往往需要同时处理多路音频流：将来自不同用户的PCM数据进行混音合成为一路、在编码前把采样率统一到目标值、在播放时把声道布局转换成设备支持的形式。这三项操作——**混音 AudioMixer**、**重采样 Resampler**、**声道转换 ChannelMixer**——构成了WebRTC音频处理链路中最基础也最关键的"数字信号处理三件套"。本文将从底层信号处理原理、源码实现、C++代码实例和生产调试四个维度进行深度解析。

`EventLog` 是 WebRTC 内部的 trace 事件日志系统，可以把“采集→编码→RTP→RTCP→网络→渲染”全过程的关键事件以结构化二进制格式记录下来，便于事后离线回放与分析。与 `RTC_LOG` 输出的文本日志不同，EventLog 面向的是开发调试与质量复盘场景，能够以极低性能开销精确还原通话全链路状态。

WebRTC Stats API 是排查通话质量问题的核心数据出口。它将 RTP/RTCP/编码器/网络/ICE/DTLS 等各层指标以结构化对象的形式暴露给业务层。无论是诊断"对方为什么卡顿"、"为什么听不到声音"、"为什么视频模糊"，还是搭建自动化的质量监控与告警体系，Stats API 都是最直接的抓手。本文从 Stats 的采集机制、核心指标的计算原理、C++ 代码实例、生产调试实践和常见面试题五个维度展开。

WebRTC 屏幕共享在 Native 端通过 `DesktopCapture` 系列接口实现，支持三种模式：全屏（多个显示器）、单窗口、用户自定义区域。本文从采集原理、平台实现细节、跨平台 C++ 接口封装到完整的工程代码实例进行系统展开，并结合源码解析与高频面试问题，帮助读者建立端到端的屏幕共享技术体系。

WebRTC 的视频渲染链路从解码后的 `VideoFrame` 出发，途经 `VideoBroadcaster`、应用层 sink（OpenGL/D3D11/Metal/Qt/Android Surface），最终到达窗口/纹理/文件。渲染链路看似简单——"拿到帧画上去"，但实际涉及 VideoFrameBuffer 体系、ZeroCopy 路径、跨线程投递、分辨率/旋转/像素对齐、多路分发与生命周期管理。本文把这些环节串联起来，把原理、源码、跨平台实践和排障思路讲透。

  上篇博客介绍了webrtc摄像头采集的源码以及它的实现方式，本篇来介绍，如何调用webrtc摄像头采集功能，并在Qt界面上显示摄像头画面。首先创建一个VS Qt x64项目，因为我编译的webrtc代码是x64, 界面如下：  显示视频用的是label, 只是我用qss把它背景默认设为了黑色。  控件名字如下：  下面开始编写代码, 首先添加webrtc头文件路径，lib库，预处理器。  头文件包含  预处理器WEBRTC_WIN_ITERATOR_DEBUG_LEVEL=0  

回声消除（Acoustic Echo Cancellation, AEC）是实时音频通话中决定用户体验的核心模块。当远端用户的语音从本地扬声器播放出来，又被本地麦克风采集并传回远端时，远端用户就会听到自己的回声。AEC的目标就是在本地麦克风信号中，精准地识别并移除这部分"回声成分"，只保留本地用户的真实语音。WebRTC的AEC经历了三代演进：早期AEC、移动端精简版AECM、以及当前主流的AEC3。本文将从底层算法原理、源码架构、C++代码实例和工程调试等维度，深入解析AEC3的工作机制。

`AudioProcessing` (APM) 是 WebRTC 的"音频 3A 引擎"，集成了回声消除（AEC）、噪声抑制（NS）、自动增益控制（AGC）、语音活动检测（VAD）等模块。理解 APM 的模块组合、参数配置和调试方法，是优化通话质量、降低背景噪声、提升语音清晰度的关键。

`AudioDeviceModule`（ADM）是 WebRTC 对物理音频设备的抽象层。它把"麦克风采集、扬声器播放、3.5mm/USB/蓝牙设备切换、AGC、MIC 静音"等细节封装到一组接口后，让上层在 Windows/Linux/macOS/iOS/Android 之间可以无差异使用。理解 ADM 是写好"跨平台音频 + 3A 链路"的基础，也是排查"杂音、延迟、蓝牙不工作、设备热插拔"等问题的入口。

private:// 在 PeerConnection 创建后挂载public :if(!// 在 PeerConnection 创建后挂载 auto battery = rtc :: make_ref_counted < BatteryResource >();();把“低电”当作和 CPU 一样的压力源，可以在不改框架的前提下让自适应更贴业务。

AV1 是由 Alliance for Open Media（AOM）开发的开源、免版税视频编码，2018 年正式发布。它在 WebRTC 中作为“面向未来”的编码方案被支持，主要解决“带宽紧张 + 高分辨率 + 高帧率”的实时场景。本文从算法特性、码流结构、WebRTC 集成、SVC 与 SFU 行为、工程落地几个维度把 AV1 在 RTC 中的实际用法讲清楚。

WebRTC 默认编译会带 VP8 和（如果启用）VP9、H.264，部分版本还会带 AV1。不同编码器在压缩效率、CPU 占用、硬件支持、License 与互通性上差异很大。生产中选择哪种编码器，往往要同时考虑“互通性、平台能力、带宽预算、功耗、SFU 兼容性”。本文从算法特性、协商流程、SFU 行为、工程封装四条主线把选型问题讲透。