第二十二章 编译WebRTC框架

源代码地址：

https://webrtc.googlesource.com/src.git

1 前置要求

1. 系统环境变量PATH中设置，Depot_tools指向webrtc同目录下的Depot_tools目录位置。
2. 确保VS2019安装了windows sdk版本 10.0.20348.0 和 10.0.19041.0 版本（需要同时安装，缺一不可，就是这么操蛋）的 Windows SDK. 必须将 Windows SDK 安装到 C 盘默认安装位置，因为 WebRTC 的编译脚本中写死了 Windows SDK 的路径。如果之前安装过 Windows SDK 到其他路径而无法选回默认路径，则可通过清空相关注册表项的方式解决（具体操作百度一下）。 安装时，需要勾选 Debugging Tools for Windows，否则生成 ninja 工程 时报错
3. 必须将 Visual Studio 安装到 C 盘默认安装路径 原因： WebRTC 的编译脚本中将 msvc 编译器的路径硬编码了。
4. 编译的目录结构一定是depot_tools目录和webrtc-checkout同一个级别。且名字不能修改。这个好变态
5. 编译的时候在webrc-checkout/src目录中直接打开cmd，执行gn指令即可。

2 编译指令

Windows webrtc M108 ，M109的版本window编译指令全集 【已验证，可以编译，且运行正常，请确保webrtc目录下所有的lib都使用同一版本编译的】

gn gen –ide=vs2019 –args=”target_os=”win” target_cpu=”x64″ is_debug=true is_component_build=false is_clang=false rtc_include_tests=false rtc_use_h264=false use_rtti=true use_custom_libcxx=false treat_warnings_as_errors=false rtc_enable_protobuf=false rtc_build_examples=false enable_iterator_debugging=true” out/x64/debug

is_debug=true debug模式 ，release模式请设置为false

target_os=”win” windows平台 （这个写或者不写，貌似没区别）

target_cpu=”x64″ x64位

is_clang=false 不用clang Google Supported, default: True. This is the main flag for switching between MSVC toolchain, and google provided toolchain. It gets a little bit more complicated with recent versions of MSVC which ship clang-cl.exe in addition to cl.exe

rtc_include_tests=false 不包含测试模块和项目

rtc_use_h264=false 不支持H264

use_rtti=true 使用C++的RTTI特性 (这个true或false都可以编译，true的情况下，编译的lib稍微大一些）

Google supported, default: false. If you see missing vtable symbols for derived classes at linking time, you likely need to set this to True. It happens, for example, when you create your own video capturer.

It is off by default because in chrome all the code is compiled in one go and you never need to extend later, and because it allows to reduce the binary size.

use_custom_libcxx=false(use_custom libcxx=false这是用来控制编译WebRtc时使用的C++库的。如果不加这个编译开关WebRtC编译使用libc++来编译，而我们编译别的代码用的是libstdc++，这会导致用到std“string的地方各种错误)但是不要用这个选项use custom libcxx for host=false不然会有各种库问题) -。设置为true直接跑错误fatal error C1189: #error: “libc++ only supports C++03 with Clang-based compilers. Please enable C++11”

treat_warnings_as_errors=false 不将错误视为错误

rtc_enable_protobuf=false 不使用内置的protobuf模块【可以使用，但可能和外部程序用的PB冲突。一般不用开】

rtc_build_examples=false 不编译examples工程

rtc_libvpx_build_vp9=true 是否支持VP9

enable_iterator_debugging=true” ，如果不设置，会出现错误mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’

use_lld=false , Community supported, default: False. This flag is only taken into account if is_clang is true. If set to false, it tells ninja to use the MSVC linker in its toolchain, improving the chances that generated binaries are compatible with MSVC project thereafter.

symbol_level =0 ——符号等级。设置为0可以减小库的大小(debug环境下还是不要设置，否则错误堆栈信息没有了）

• ffmpeg_branding——ffmpeg的分支名，采用Chrome的分支。
• rtc_build_ssl——是否编译BoringSSL。
• rtc_ssl_root——OpenSSL的头文件路径，会被写到生成的ninja文件中。
• proprietary_codecs——是否使用版权编码，也就是H264。

M109的版本window编译指令全集-支持H264

据说clang=false的情况下默认是不支持H264=true的。因为FFMPEG的缘故。（自己做好像也可以，就是比较麻烦。）

但是实际上有一次是不行，其余都是可以的。clang=true编译通过。H264也支持。运行也正常。

gn gen –ide=vs2019 –args=”target_os=”win” target_cpu=”x64″ is_debug=true is_component_build=false is_clang=true rtc_include_tests=false rtc_use_h264=true ffmpeg_branding=”Chrome” use_rtti=true use_custom_libcxx=false treat_warnings_as_errors=false rtc_enable_protobuf=false rtc_build_examples=false enable_iterator_debugging=true” out/x64/debug

编译出来了。LINK阶段没有错误。但是使用时候会有崩溃情况发生，原因未明。

3 编译依赖等问题

这里是所有window kits的下载。

https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

应该需要Windows 10 SDK, version 2004 (10.0.19041.0) -.这个版本没有在上述的SDK中找到。只能用下面的方法

安装choco

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
使用这个安装

choco install windows-sdk-10-version-2004-windbg

用MD还是MT来编译

网上很多说通过is_component_build来控制，但看上去这个没有控制MD还是MT。

这里说的是对得。 请注意..srcbuildconfigwinbuild.gn 文件位置别搞错。

然后不用通古参数配置，直接修改内容了。因为参数传递控制传导不过去。

修该目录下该文件对应内容。

看参数可以通过is_component_build 来控制，但看上去被WebRTC忽略了，理由是两者作用差不多。

其余的配置也没有很好的理清楚，就直接比较暴力的修改 static_crt的配置。将cflags修改成了MD

或者后续的MT强制修改成MD。

验证可行。

早期曾经使用过的编译指令

@REM 开始编译，进入webrtc的工作目录
@REM 设置工作目录和相关环境变量
set ROOT=C:webrtc
set SRC=%ROOT%/webrtc-checkout/src
set PATH=%ROOT%/depot_tools;%PATH%
@REM #不更新depot_tools
set DEPOT_TOOLS_UPDATE=0
@REM #编译时使用本机VS工具链
set DEPOT_TOOLS_WIN_TOOLCHAIN=0
@REM #指定VS版本
set GYP_MSVS_VERSION=2019
@REM #vs安装路径，替换成自己的
set GYP_MSVS_OVERRIDE_PATH=C:Program Files (x86)Microsoft Visual Studio2019Professional
@REM #使用ninja编译
set GYP_GENERATORS=msvs-ninja,ninja
@rem 生成项目文件
cd /d %SRC%
@REM 生成VS工程，耗时较长，耐心等待
@REM 工程生成完毕后，也可以直接使用VS打开all.sln文件，直接编译
@REM 但是推荐使用ninja，速度相对会快一些
@REM gn gen out/Release --args="is_debug=false" --ide=vs2019
gn gen --target=x64 --args="is_debug=false is_clang=false use_lld=false treat_warnings_as_errors=false use_custom_libcxx=false use_rtti=true rtc_include_tests=false enable_iterator_debugging=true symbol_level=0" --ide=vs2019 out/x64/release
@REM 执行编译-Ninja 
cd /d %SRC%
ninja -C out/x64/release
@REM 编译完成-Success
@REM 返回工作目录
cd /d %ROOT%

编译时重要的参数讲解

webrtc更多编译参数说明：

• is_component_build——是否使用动态运行期库，设置false表示使用静态运行期库，Release版本将对应MT，Debug版将对应MTd。
• proprietary_codecs——是否使用版权编码，也就是H264。
• rtc_use_h264——是否使用H264。注意Windows平台编码使用OpenH264，解码使用ffmpeg。
• ffmpeg_branding——ffmpeg的分支名，采用Chrome的分支。
• rtc_build_ssl——是否编译BoringSSL。
• rtc_ssl_root——OpenSSL的头文件路径，会被写到生成的ninja文件中。
• use_custom_libcxx——是否使用内置的libcxx作为默认的c++标准库。
• rtc_libvpx_build_vp9——是否支持vp9的编解码。
• symbol_level——符号等级。设置为0可以减小库的大小。
• rtc_include_tests=false -去掉单元测试

target_os=”win” target_cpu=”x64″ is_component_build=false is_clang=false use_lld=false treat_warnings_as_errors=false use_rtti=true rtc_include_tests=false rtc_build_examples=false”

4 如何查看当前WebRTC的版本

这个网站详细列出了对应的版本和细节。

https://chromiumdash.appspot.com/branches