WebRTC 视频调试：如何使用 video_replay 重现和修复问题

调试 WebRTC 应用程序中的视频问题是一项极具挑战性的任务。由于底层存在众多可变部件，要准确找出问题的原因无异于大海捞针。最有效的策略之一就是在受控环境中持续重现问题。

在本篇文章中，我们将探讨 WebrtcH4cKS 博客中提出的一项强大技术：使用 video_replay 工具隔离并重现视频问题。通过捕获和重放原始 RTP 数据包，您可以有效地跳出实时环境，在受控环境中分析视频流。

这种方法，尤其是与 Google Chrome 浏览器记录未加密 RTP 转储的功能搭配使用时，为重现和调试视频问题提供了一种一致的方法，最终能带来更快、更有效的解决方案。

video_replay 过程概述

浏览器中的 WebRTC 应用程序依赖于一系列复杂的技术。当视频出现故障时，通常是由于其中一个或多个组件出现故障。video_replay 工具允许开发人员从以前录制的会话中重现特定的视频问题，帮助隔离问题并更好地了解问题所在。

实现这一目标的方法之一是捕获有问题流的原始 RTP 数据包，并将其传递给 libWebRTC 的 video_replay 工具。这就提供了一种通过在浏览器外使用 WebRTC 框架 “replaying ”数据流来隔离此类问题的方法，为开发人员提供了重现和调试问题的一致方法。

但是，鉴于 WebRTC 的加密方法，在正常情况下无法访问此类未加密数据包。幸运的是，Google Chrome 浏览器提供了一种记录未加密 RTP 转储的方法，可用于此目的。

总体过程如下：

启用特殊标记，启动新的 Google Chrome 会话。
建立要调试的 WebRTC 连接。
使用 webrtc-internals 获取流的相关信息。其中包括编解码器、有效载荷类型和 SSRC。
根据 Chrome 浏览器提供的 RTP 转储创建 PCAP 文件。
将此类文件传给 vide_replay，和/或使用 Wireshark 网络协议分析器等其他专业工具进一步分析。

让我们通过一个示例来了解这些步骤。

一次性设置：构建 video_replay 二进制文件

首先需要安装 video_replay 工具。它是 WebRTC 代码的一部分，因此需要克隆代码库、安装依赖项并自行构建二进制文件。Google Git WebRTC 开发页面上有详细说明，但可以概括如下：

下载Chromium depot tools，并将其添加到操作系统的 PATH 变量中。
创建一个新目录（即webrtc_checkout），然后使用fetch工具下载 WebRTC 代码。
使用该gclient工具完成代码同步。
在 src/ 文件夹内使用生成gn gen构建文件。
- 可以根据自己的需要配置构建文件：例如，配置对 H.264 的支持。
使用ninja工具来构建video_replay二进制文件。

例如，以下是基于 Unix 操作系统的命令。请注意，这将是一个相当大的下载量。

# 1. Download depot tools
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git ~/depot_tools
export PATH=~/depot_tools:$PATH

# 2. Download WebRTC code
mkdir ~/webrtc_checkout
cd ~/webrtc_checkout
fetch --nohooks webrtc

# 3. Sync code
gclient sync

# 4. Generate build files
cd src
gn gen out/Default

# 4.a (Optional)
#   Configure support for H.264
printf "rtc_use_h264 = true\nffmpeg_branding = \"Chrome\"" >> out/Default/args.gn
#   rebuild
gn gen out/Default

# 5. Build video_replay binary
ninja -C out/Default/ video_replay

此后，您将可以使用 video_replay 二进制文件来解决视频问题。

捕获未加密的 RTP 流量

现在我们需要捕获待排查流的 RTP 数据包。启动一个新的 Chrome 会话，并启用 WebRTC-Debugging-Rtp 标记，如下命令所示。确保将 Chrome 浏览器二进制文件更改为操作系统中可用的版本，在本文的例子中就是 google-chrome。

此外，如果您打算分享重放结果（即在 WebRTC 问题跟踪器中提交 bug），可能需要使用 --use-fake-device-for-media-stream 标记，以防止发送自己的摄像头视频。

# Open google chrome with RTP dump logging enabled
google-chrome --enable-logging=stderr \
-v=3 \
--force-fieldtrials=WebRTC-Debugging-RtpDump/Enabled/ \
--use-fake-device-for-media-stream \
> log.txt 2>&1

现在，让我们看看一些 WebRTC 流量！

例如，让我们从基本的 Peer 连接示例中捕获接收流。在此之前，请在另一个标签页中打开 chrome://webrtc-internals，因为我们将用它来收集一些所需的信息。

回到 WebRTC 示例，点击 “Start（开始）”，然后点击 “Call（呼叫）”。这将启动两个对等连接：一个用于发送媒体，另一个用于接收媒体。我们感兴趣的是第二个连接，因此请在 webrtc-internals 标签中查找它，您会发现它在事件列表中包含了 createAnswer API 调用。

WebRTC 视频调试：如何使用 video_replay 重现和修复问题 — chrome://webrtc-internals 的屏幕截图显示了对等连接及其“createAnswer”事件的详细信息。

接下来，识别已接收视频流的统计数据。它的名称可能类似于inbound-rtp和kind=video。展开这些值并记下 SSRC、编解码器和有效载荷类型的值，在本例中分别为154136587、VP8和96。

我们还需要经过协商的冗余编码（RED）有效载荷类型。我们可以从接收方对等体的 SDP（位于此类连接的 setLocalDescription 事件下）中获取。在 SPD 中，查找类似 a=rtpmap:119 red/9000 的一行，并注意分配给 rtpmap 的编号（本例中为 119）。

根据使用情况，您可能还需要其他信息，如有效载荷类型和重传视频数据包的 SSRC。这些信息也可以在 SDP 和/或视频流统计中找到。

有了这些信息，您就可以点击样本选项卡中的 “Hang Up”来结束通话了。

下一步是获取 RTP 转储并生成 PCAP 文件。在基于 Unix 的系统中，我们使用 grep 工具从 Chrome 浏览器日志中提取这些数据，然后使用 Wireshark 的 text2pcap 工具生成文件，如下所示：

# Generate a pcap with RTP dumps
grep RTP_DUMP log.txt > rtp-dump.txt
text2pcap -D -u 1000,2000 -t %H:%M:%S.%f rtp-dump.txt rtp-dump.pcap

现在您有一个rtp-dump.pcap捕获文件，您可以使用 Wireshark 进一步分析它和/或使用video_replay您之前构建的二进制文件重放它。

使用 video_replay 重放 RTP 流

要使用video_replay重放流，请将rtp-dump.pcap文件以及从webrtc-internals获得的流信息作为输入传递。所需的确切命令将根据用例而有所不同，因此请务必使用 --help flag 工具运行该命令来检查可用参数列表。在本文的例子中，我们使用的命令是：

# Replaying the video stream
~/webrtc-checkout/src/out/Default/video_replay \
    --codec=VP8 \
    --input_file rtp-dump.pcap \
    --media_payload_type=96 \
    --ssrc=154136587 \
    --red_payload_type 119

在后台，video_replay将使用 WebRTC 的工具来解包、解码和离线播放流。