webrtc开发实战系列2 – windows下编译WebRTC支持H264

在本系列上一篇文章《webrtc音视频开发实战系列 – windows下编译WebRTC》中，我们详细介绍了如何在windows平台上下载webrtc源码和安装相关的编译工具，重点介绍了如何通过VS2022来编译webrtc代码。

因为之前下载的是2024年1月的代码，目前webrtc代码有了很多更新，并且我需要在webrtc使用H264相关的功能，借着周末空闲时间，我们升级一下webrtc代码，并重新编译使之支持H264，这是本文的目标。

01 更新webrtc代码

webrtc源码下载方式及翻墙代理设置等内容前文已经讲过，这里不再赘述。

更新代码之前我们先清理一下工程

gn clean output/Debug

然后我们切换到master分支并更新代码：

git checkout master

git pull origin master

gclient sync

考虑到master分支代码比较新，可能存在一些还不明确的问题，所以我准备切换到一个相对稳定的版本，https://chromiumdash.appspot.com/branches这里我们可以看到目前webrtc代码已经更新到了m131，对应分支号是6778。

让我们切换到m130也就是branch-heads/6723分支，

git checkout -b m130  refs/remotes/branch-heads/6723

但是git提示错误,找不到对应的分支信息，回想之前我们是通过gclient sync -f来获取webrtc代码，使用git命令切换分支时，发现这种方式拉取的代码在本地仓库中看不到分支信息。看来我们有必要研究一下gclient这个工具了。

gclient是webrtc用来代码拉取、下载部署工具、代码管理的关键组件。下载到.gclient配置文件之后就可以通过gclient完成其他工作，亦即不再需要fetch了。

下面介绍一些gclient指令的参数：

—nohooks 跳过执行hook阶段，hook阶段所执行的任务通常来说是和构建和编译有关。如果暂时不需要构建编译的话，可以跳过hook阶段。等需要的时候再使用runhooks命令手动执行hook。
-v 这个参数用来控制输出信息的详细程度。gclient使用了optparse命令行参数解析库中的次数参数来处理这个参数，也即通过重复输入这个参数来控制日志的等级。总共有四个等级，不输入参数的时候为默认的等级，如果需要最详细的日志，可以重复输入三个-v。
—with_branch_heads 这个参数可以在拉取仓库的时候拉取分支的信息。chrome系列的代码仓库的分支使用了非git默认的分支引用命名，所以默认情况下clone是无法clone到分支信息的。当你有切换分支的需求时，你应该使用这个参数。但是它会导致你的代码仓库占用更多的磁盘空间。注意，这个参数应该在第一次使用sync指令时就使用。如果已经完成了代码的拉取，再次使用这个参数执行sync命令是没有用的。
–with_tags 作用类似–with_branch_heads。只不过是针对仓库的tag。
--no-history: 不拉取git提交历史信息;
--revision <version>: 将代码切换到 version 版本

了解gclient的基本用法之后我们在命令行工具中输入以下命令：

gclient sync --with_branch_heads  --with_tags

这样同步完代码，通过git命令或者图形化工具就可以看到下面的brand heads

注：但是它会导致你的代码仓库占用更多的磁盘空间

切换到m130分支：

# 创建m130对应的 branch-heads/6723 分支
git checkout -b m130  refs/remotes/branch-heads/6723

# 必须要执行，同步编译toolchain,更新依赖库等
gclient sync --nohooks

02 WebRTC支持H264编解码

为什么要支持H264？

很简单，为了兼容性。

webrtc本身自带的编解码器是google主推的VP8,VP9，但在IOS上目前支持并不好，而H264是事实上的标准，当前应用最广泛，在各个平台支持的也很好，但由于H264并不是谷歌亲生的，H264一直不受待见，所以在传输上与WebRTC本身的代码结合得还不是很完美，弱网情况下VP8比H264的表现的确要好一些,然而，在某些场景下，H264编解码器可能更具优势。

H264编解码器的优势

H264是一种广泛使用的视频编解码器，被众多设备和浏览器所支持。与VP8/VP9相比，H264在编码效率、兼容性和网络适应性方面具有一定优势。

编码效率：H264在相同的视频质量下，通常可以产生更小的码流，从而节省带宽和存储空间。
兼容性：H264得到了众多硬件和软件厂商的支持，包括许多流行的浏览器和移动设备。
网络适应性：H264支持多种网络传输协议和码率控制策略，可以更好地适应不同的网络环境。

注意：WebRTC使用OpenH264来做encoder，使用ffmpeg来做decoder

编译步骤

编译之前先清理工程：

 gn clean output/Debug

生成vs工程的命令：

gn gen  output/x64-release-h264-clang --ide=vs2022 --args="is_debug=false target_cpu=\"x64\" is_clang=true use_lld=true  use_rtti=true  rtc_use_h264=true  rtc_build_tools=false  rtc_include_tests=false  rtc_build_examples=true  proprietary_codecs=true ffmpeg_branding=\"Chrome\"  use_custom_libcxx=false  treat_warnings_as_errors=false"

然后编译生成webrtc库：

ninja -C output/x64-release-h264-clang -j8

注意: 从M100开始webrtc编译已经不支持msvc的编译器了，只能使用clang-cl编译器，所以is_clang一定要设为true。

上述 gn命令中的几个参数含义如下：

–target，顾名思义，目标平台
–ide，指定vs版本
–args，编译时的一些配置参数
- is_debug，为true编译出Debug版本；为false编译出Release版本
- rtc_use_h264 是否使用H264。注意Windows平台编码使用OpenH264，解码使用ffmpeg。
- proprietary_codecs 是否使用版权编码，也就是H264。true
- use_custom_libcxx，WebRTC默认使用的是libc++库，而我们在Windows上使用的是libstdc++库，所以需要将其设置为false
- symbol_level，编译出的WebRTC库是否带符号表，这个数据量很大，会影响运行速度，所以一般设置为0，表示编译出的WebRTC不带符号表，可以减小库的大小
- rtc_include_tests，编译WebRTC时是否编译测试用例，如果为false则不编译，这样可以大大加快WebRTC的编译速度

03 错误处理

在执行上面更新代码、编译等步骤时出现了一些错误，这里记录并分享一下。

错误解决

Windows SDK >= 10.0.22621.2428 required

Windows SDK >= 10.0.22621.2428 required. You can get it by updating Visual Studio 2022 using the
Visual Studio Installer

解决方法：

安装10.0.22621.2428版本的windows SDK

Windows 11 (10.0.22621.2428 Windows SDK)下载地址：https://developer.microsoft.com/zh-cn/windows/downloads/sdk-archive/

假设windows SDK安装目录是D:\Windows Kits\10，同时需设置环境变量WINDOWSSDKDIR如下：

set WINDOWSSDKDIR=D:\Windows Kits\10

Debugging Tools for Windows

You must install Windows 10 SDK version 10.0.22621.0 including the "Debugging Tools for Windows" feature.
ERROR at //build/toolchain/win/BUILD.gn:24:3: Script returned non-zero exit code.
  exec_script("../../vs_toolchain.py",

解决方法：同上

lld-link : error : lib failed

3>[49/75] CXX obj/rtc_base/win/hstring/hstring.obj
94>------ 已启动生成: 项目: libvpx_generic_headers, 配置: GN x64 ------
3>[50/75] CXX obj/rtc_base/win/get_activation_factory/get_activation_factory.obj
3>[51/75] LIB obj/rtc_base/win/hstring.lib
3>FAILED: obj/rtc_base/win/hstring.lib
3>..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe /lib "/OUT:obj/rtc_base/win/hstring.lib" /nologo /WX /ignore:4221 /llvmlibthin "@obj/rtc_base/win/hstring.lib.rsp"
3>@obj/rtc_base/win/hstring.lib.rsp: no such file or directory
3>
3>lld-link : error : lib failed

由于VS中自带的Clang与webrtc工程的Clang版本不匹配，最好在VS中使用webrtc的Clang编译器

解决方案: 卸载VS自身的Clang

LINK : fatal error LNK1104: 无法打开文件“comdlg32.lib”

FAILED: py_quality_assessment/quality_assessment/fake_polqa.exe py_quality_assessment/quality_assessment/fake_polqa.exe.pdb
"C:/Users/Administrator/AppData/Local/.vpython-root/store/python_venv-ugraqihfukp4j3cqs9pta4mias/contents/Scripts/python3.exe" ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe "/OUT:py_quality_assessment/quality_assessment/fake_polqa.exe" /nologo "/PDB:py_quality_assessment/quality_assessment/fake_polqa.exe.pdb" "@py_quality_assessment/quality_assessment/fake_polqa.exe.rsp"

LINK : fatal error LNK1104: 无法打开文件“comdlg32.lib”
[1034/5803] LIB obj/api/rtp_parameters.lib
ninja: build stopped: subcommand failed.

解决方法：

安装10.0.22621.2428版本的windows SDK, 可能电脑上安装了多个不同版本的windows SDK, 卸载干净之后重新安装10.0.22621.2428

only clang-cl is supprorted on Windows

从M100开始webrtc编译已经不支持msvc的编译器了，只能使用clang-cl编译器，所以is_clang一定要设为true，即设置 is_clang=true

webrtc工程自带的clang编译器所在目录：\src\third_party\llvm-build\Release+Asserts\bin

环境变量含中文导致写环境变量失败

UnicodeEncodeError: 'gbk' codec can't encode character '\u04e2' in position 3840: illegal multibyte sequence

解决方法：修改src\build\toolchain\win\setup_toolchain.py

f.write(env_block.encode('utf-8').decode('GBK'))

‘ninja.exe’ 不是内部或外部命令，也不是可运行的程序

执行gclient相关命令后，可能会把depot_tools/目录下的ninja.exe文件删掉。所以vs运行时找不到该文件

解决方法：

拷贝src\third_party\ninja目录下的ninja.exe到depot_tools/目录下

04 总结及计划

上面的编译过程中出现的问题，大部分原因还是在编译选项及参数， Windows SDK的安装及版本，相关环境变量的设置上，只要我们搞懂了各个编译环节的基本原理，这些问题就很容易解决了。

通过以上步骤最后在output/x64-release-h264-clang\obj目录下成功功编译出来webrtc的静态库webrtc.lib，此外在output/x64-release-h264-clang目录下也编译出了peerconnection_client.exe，peerconnection_server.exe等demo程序。

目前peerconnection，demo程序运行起来后client无法与server正常连接，client无法加入到房间，印象中自M93(4577)之后的版本就一直存在这个问题，没想到到现在还没解决。在webrtc开发实战系列后续章节中我们将调试和分析peerconnection示例工程的代码, 使之能正常工作，也会编写一个demo程序，通过webrtc向SRS等SFU服务器推送H264码流。敬请期待。