在本系列上一篇文章《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 版本.
了解gclient的基本用法之后,我们在命令行工具中输入以下命令：
gclient sync --with_branch_heads --with_tags这样同步完代码，通过git命令或者图形化工具就可以看到下面的brand heads
webrtc开发实战系列2 - windows下编译WebRTC支持H264
但是它会导致你的代码仓库占用更多的磁盘空间
.
切换到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。trueuse_custom_libcxx，WebRTC默认使用的是libc++库，而我们在Windows上使用的是libstdc++库，所以需要将其设置为falsesymbol_level，编译出的WebRTC库是否带符号表，这个数据量很大，会影响运行速度，所以一般设置为0，表示编译出的WebRTC不带符号表，可以减小库的大小rtc_include_tests，编译WebRTC时是否编译测试用例，如果为false则不编译，这样可以大大加快WebRTC的编译速度更多参数说明
is_component_build——是否使用动态运行期库，设置false表示使用静态运行期库，Release版本将对应MT，Debug版将对应MTd。ffmpeg_branding——ffmpeg的分支名，采用Chrome的分支。rtc_build_ssl——是否编译BoringSSL。rtc_ssl_root——OpenSSL的头文件路径，会被写到生成的ninja文件中。rtc_libvpx_build_vp9——是否支持vp9的编解码。use_rtti=true：编译时启用运行时类型信息功能，默认是falsertc_enable_protobuf，是否使用protobuf，使用可将其设置为true重要提示
在下载代码及编译过程中，我们使用的是通过管理员权限打开windows自带的命令行工具，或者是使用vs2022自带的Native Tools Command，切记不要使用PowerShell，否则会有莫名其妙的编译错误产生**
最新的webrtc代码要求必须使用CLang编译器，所以要设置is_clang=true
在执行上面更新代码、编译等步骤时出现了一些错误，这里记录并分享一下。
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\10lld-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/目录下
总结及计划
上面的编译过程中出现的问题，大部分原因还是在编译选项及参数， 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码流。敬请期待。
扫码关注音视频开发训练营