WebRTC采用UDP传输流媒体数据，不可避免存在丢包情况。WebRTC主要采用FEC（Forward Error Correction，前向纠错）以及NACK（negative-acknowledge character，否定应答）对抗网络丢包。对于NACK，遇到丢包了才通知发送端重传对应数据包，但不是所有情况下某个包丢了就一定重传该包，有些场景下，重传该包会带来其它问题，例如增大延时，缓存过大，同时也可能发送端没有该数据包缓存，导致无法重传，此时会放弃重传该包。由于关键帧可以单独解码出图像，不参考前后视频帧，所以会采取请求关键帧这种更便捷的方式替代重传该数据包，使解码端能立刻刷新出新图像，避免丢包过多，长时间等待重传数据包导致的画面停顿问题，以及获取不到重传包导致后续数据解码花屏问题。除了丢包，在WebRTC还存在其他请求关键帧的场景。 关键帧请求场景 下面结合代码列举几种常见场景。 H264解码无sps,pps信息 解码H264时无法获取sps，pps，导致无法解码，此时就需要请求获取关键帧，在H264SpsPpsTracker中，相关处理代码如下： [crayon-69c79231496ca794827196/] 丢失包过多 在非常高的丢包率情况下，丢失的包太多，若都一一重传，将造成延时增大（等帧数据完整了才会去解码渲染），此时新来的数据也只能一直缓存，所以jitterbuffer大小也会不断增大，此时不如直接请求发送一个关键帧来得实际，以前丢的那些包都不管了，由于关键帧可以单独解码，所以不会造成解码端花屏马赛克现象。但是由于前面那些视频帧都丢弃了，此时生成的关键帧会与之前播放的视频存在不连贯性，所以画面变化大时会有轻微卡顿现象，相当于跳帧了。NackModule中相关处理代码如下： [crayon-69c79231496d6763849147/] 上面代码中，要重传的包数量nack_list_.size()在进行RemovePacketsUntilKeyFrame()操作后若还超过规定大小，就开始清空要重传的数据包列表：nack_list_.clear()，然后请求关键帧。 丢失包过旧 发送端默认缓存600个RTP包，如果丢失的包太旧，超出缓存范围，此时发送端就没有该数据包的缓存，就无法重传该包。在VCMJitterBuffer中，相关处理代码如下： [crayon-69c79231496dc256906770/] 获取帧数据超时 要解码的帧数据存放在FrameBuffer中，解码器解码时如果超过规定时间一直无法从FrameBuffer中获取解码数据，此时就会请求关键帧。相关处理代码如下： [crayon-69c79231496e0594935667/] 解码出错 当解码器返回解码失败，或者解码器返回请求关键帧结果时，需要请求关键帧。相关处理代码如下： [crayon-69c79231496e3807446285/] 在上面我们列举了几种需要关键帧请求的情况，我们只需要规定好RTCP报文格式，就能通知编码发送端发送关键帧。关键帧请求RTCP报文格式比较简单，在RFC4585（RTP/AVPF）以及RFC5104（AVPF）规定了两种不同的关键帧请求报文格式：Picture Loss Indication (PLI)、Full Intra Request (FIR)。WebRTC中关键帧请求也只用到了这两种消息，相关代码如下： [crayon-69c79231496e6880742580/] Picture Loss Indication (PLI) 在RFC4585中定义，属于RTCP反馈消息中的一种。RTCP反馈消息数据包格式按如下规定： [crayon-69c79231496ea199000175/] 其中PT字段按如下规定： [crayon-69c79231496ed300389989/] 对于PLI，由于只需要通知发送关键帧，无需携带其他消息，所以FCI部分为空。对于FMT规定为1，PT规定为PSFB。 在WebRTC源码中，PLI相关解析封装代码位于webrtc::Pli中。相关代码如下： [crayon-69c79231496f0627366792/] PLI消息用于解码端通知编码端我要解码的图像的编码数据丢失了。对于基于帧间预测的视频编码类型，编码端收到PLI消息就要知道视频数据丢失了，由于帧间预测需要基于前后完整的视频帧才能解码（例如H264中，存在B帧，需要参考前后帧才能解码），前面的数据丢失了，后面的视频帧不能正常解码出图像，此时编码端可以直接生成一个关键帧，然后发送给解码端。 Full Intra Request (FIR) 在RFC5104中定义。参照上一小节RTCP反馈消息数据包格式，对于FMT规定为4，PT规定为PSFB。由于FIR可用于通知多个编码发送端（例如多点视频会议情况），所以用到了FCI部分，填充多个发送端的ssrc信息。具体包格式如下： [crayon-69c79231496f3859447705/] 在WebRTC源码中，FIR相关解析封装代码位于webrtc::Fir中。相关处理代码就不贴出来了，类似PLI处理，除了FCI部分要填充一些信息。 当解码端需要刷新时，可以发送FIR消息给编码端，编码端此时发送关键帧，刷新解码端。这有点类似PLI消息，但是PLI消息是用于丢包情况下的通知，而FIR却不是，在有些非丢包情况下，FIR就要用到。举两个例子： 1）解码端需要切换到另一路不同视频时，由于需要新的解码参数，所以可通过发送FIR消息，通知编码端生成关键帧，获取新的解码参数，刷新视频解码器； 2）在视频会议中，新用户随机时刻加入，各个编码端发送的视频不一定都是关键帧，所以新用户不一定能正常解码。此时该新加入用户发送FIR消息，通知各个编码端给它发关键帧，获取关键帧后即可正常解码。 总结 本文主要介绍了几种关键帧请求场景，讲了AVPF中定义的两种关键帧请求消息，虽然这两种消息获取的结果一样，但是表达的意义却不一样，用于不同场景，使用时需要区分下。

在音视频领域，想深入研究的话，必定会接触WebRTC。WebRTC是一个庞大的工程，就像是音视频领域的百科全书，音视频采集，编解码，传输，渲染等一条龙在WebRTC里都有，而且WebRTC还有很多先进的音视频处理算法。由于WebRTC代码过于庞大，所以最好单步调试跟踪代码运行，这样才可以更好地学习WebRTC，否则很难有头绪。工欲善其事必先利其器，作为调试神器，宇宙第一IDE Visual Studio必不可少。所以本篇文章主要讲下如何在Windows上编译WebRTC，同时得到VS工程，然后调试。 本文内容截止2020.04.01，最新代码测试编译通过。最新VS2017以上版本编译见文末。 系统要求 Win7及以上64位系统。 内存至少8G，当然越大越好。 至少50G磁盘空间（NTFS格式），不能是FAT32，因为会生成大于4G的文件。 Visual Studio安装 WebRTC用到了很多C++最新特性，所以编译最新WebRTC代码VS要求为2017(>=15.7.2) 版本。我用的是VS2017社区版（VS新老版本下载）。VS最好安装在C盘，按默认路径安装，否则可能遇到问题（见问题0x02）。安装VS2017时选择自定义安装，必须勾选如下几项： Desktop development with C++组件中10.0.18362或以上的Win10 SDK，后面还要安装调试工具 Desktop development with C++组件中MFC以及ATL这两项 2020.04.01更新：由于最新WebRTC源码要求10.0.18362及以上Win10 SDK。所以请下载10.0.18362 或以上的Win10 SDK。本文写于2019年，那时VS2019还没发布。由于10.0.18362 Win10 SDK存在于VS2019安装选项中，VS2017安装选项不带有该SDK，所以使用VS2017得从Win10 SDK下载另外下载最新Win10 SDK，或者再装个VS2019选择安装该SDK 安装完VS2017后，必须安装SDK调试工具。打开控制面板->程序与功能，找到刚才安装的最新Windows Software Development Kit，鼠标右键->change。 勾选Debugging Tools For Windows，然后点击change。 depot_tools安装 下载depot_tools然后解压到某个目录，比我的解压到E盘根目录。接着将该depot_tools目录的路径加到系统环境变量Path里，然后把该路径移到最前面（避免已安装的python与git造成影响）。 获取WebRTC源码 由于WebRTC的源码地址被墙了，所以需要通过代理或者vpn才能得到源码。后面都是命令行操作，打开cmd窗口，由于我用的是ss代理，在cmd窗口我按如下设置： [crayon-69c792314b3c7435907757/] 设置当前cmd窗口代理上网，如果cmd窗口关闭了重开得重新设置。当然了，也可以设置系统全局代理上网。其他代理方法也类似。如果是VPN之类非代理，就不用这样设置了。 接着执行gclient命令，安装编译需要用到的一些工具，比如git以及python。 [crayon-69c792314b3d1556402611/] 再接着设置一些环境变量，设置下我们的VS安装路径。 [crayon-69c792314b3d5612275140/] 然后cd到要放源码的地方（要遵守前面说的磁盘要求），执行： [crayon-69c792314b3d8067434362/] 这一过程是个漫长的等待，要下的东西将近10G，包括源码以及一些测试的音视频文件资源等，如果因为网络等原因中断了，就再执行gclient sync。如果这一步一直卡着不动，可以执行ctrl+c，然后执行gclient sync。 使用gclient sync可能遇到的问题 问题0x01 [crayon-69c792314b3db499945036/] Unicode字符编码问题，python的一个bug，因为很多人系统语言都是中文的，所以得按如下设置，把系统区域改为英文，然后重启即可。 问题0x02 2019.04.01更新。去年的版本我编译时没报这个问题，我看到评论里有人提出来了，我下了今天的最新代码，编译时也碰到了，看了下是最新WebRTC windows相关脚本变化导致 报Exception: No supported Visual Studio can be found. Supported versions are: 16.0 (2019), 15.0 (2017)错误： [crayon-69c792314b3df613437431/] 解决方法为修改src\build目录下的vs_toolchain.py脚本，加了一行，直接写死我们的VS路径代码： [crayon-69c792314b3e2056218726/] 脚本中的代码默认以C盘处理的，如果我们的VS安装在C盘默认目录就不会报这个错，但我想很多人VS不会装在C盘。 执行：python src/build/vs_toolchain.py get_toolchain_dir验证修改，控制台打印如下： [crayon-69c792314b3e5992726359/] 说明修改成功。接着我们使用gclient sync会报如下问题： [crayon-69c792314b3e8725711536/] 因为我们修改了脚本，所以执行gclient sync --force即可。 gclient sync --force成功结束后，vs_toolchain.py文件会被还原，所以得按前面重新修改vs_toolchain.py。vs_toolchain.py中会优先选择高版本VS编译，由于本文使用VS2017编译，假如我们电脑安装有VS2019，需要按如下修改，把VS2017放前面，避免造成影响。 [crayon-69c792314b3eb407740266/] 编译 生成VS2017工程文件： [crayon-69c792314b3ee565581424/] 可以在src\out\Default\ 下得到 all.sln解决方案文件。 如果不想使用默认编译参数，可以使用gn args out/Default --list查看当前编译参数，通过类似如下方式设置： [crayon-69c792314b3f1154351240/] 接着执行编译命令： [crayon-69c792314b3f4591019630/] 用VS2017打开： 可以看到众多工程，到此算是完成了。找到我们感兴趣的，就可以用VS单步调试，跟踪代码运行了。这么多宝贝够研究很久了。 代码更新 [crayon-69c792314b3f7058095146/] 引用WebRTC库 WebRTC编译后会在src\out\Default\obj目录下生成整个WebRTC工程的静态库：webrtc.lib，链接下这个就可以了。 总结 总之WebRTC在Windows上的编译很考验耐心，也很苛刻，需要有个好的访问被墙地址工具。最新VS2019编译可以参考我的这篇文章： Windows平台WebRTC编译（持续更新），本文也不再更新。 参考 1. WebRTC Native code Development 2. Chromium’s build instructions for Windows