调试 WebRTC 调用

报告 WebRTC 调用问题

报告问题最佳方式是通过 Bugzilla 使用此 链接。描述您遇到的问题，包括 URL 以及呼叫设置的详细信息。请参阅 添加呼叫设置信息 部分以获取有用的模板。以下是一些描述性 WebRTC 错误摘要的常见示例

  • 呼叫者遇到视频、屏幕截图或桌面截图冻结

  • 呼叫者听不到音频

  • 呼叫者的语音听起来失真或像机器人

  • 视频分辨率低于预期

  • 呼叫者的视频显示旋转

  • 呼叫者的视频和音频之间存在明显的延迟

  • 摄像头、麦克风或屏幕未出现在 Firefox 设备访问权限提示中，等等。

  • 呼叫者的视频出现乱码、部分缺失或颜色不正确

  • 呼叫者无法共享外部显示器，但可以共享集成显示器

注意

并非所有网络会议软件都广泛使用 WebRTC。

对于简单的问题，首先检查 网页开发者控制台 中是否存在与媒体格式问题相关的错误消息。如果您在此处看到与 WebRTC、getUserMedia 或 getDisplayMedia 相关的消息，请将此信息添加到您的错误报告中。

添加呼叫设置信息

以下模板可以帮助提供诊断许多常见问题所需的所有呼叫详细信息。

* Does this problem occur in Firefox for Desktop or Android?

* Is this problem reproducible in Firefox Nightly?

* Has this worked previously?

* Have you tried using `about:profiles` to reproduce the problem in a
  clean profile?

* How many participants were in the call?

* In which web conferencing or web calling services does the problem occur?

* Does the problem present itself immediately upon starting the call?

* If not how long does it take to occur?

* If this is a problem with audio or video capture, what camera or microphone
  are you using? (adding about:support text may be helpful)

* If this is problem with screen capture, which screen was being captured,
  and are there other screens attached to the same machine?

* Would you be willing to help us find a regression range?

如果问题是规范合规性问题，则下面提供的模板可能更有用。如果不确定这是否是合规性问题，可以参考 标准文档 部分中的链接。

* What unexpected behavior is being observed? What are the steps to reproduce
  this issue?

* What is the expected behavior?

* Where is this behavior specified?

* Is this problem reproducible in Nightly?

* Have you tried using `about:profiles` to reproduce the problem in a clean
  profile?

* Has this worked previously?

* If so, would you be willing to help us find a regression range?

添加 about:support 文本

在您的 Bugzilla 报告中，请包含有关您遇到问题时的当前设备的支持信息。

  1. 打开一个标签页并访问 about:support

  2. 点击“复制文本到剪贴板”

  3. 将此文本粘贴到您的 Bugzilla 错误评论和帖子中。

注意

要在 Firefox 中打开 about:* 链接，必须执行以下操作：#. 右键单击链接并选择“在新标签页中打开链接” #. 选择新标签页 #. 单击地址栏，其中应包含 about URL #. 按 Enter

添加 about:webrtc RTCPeerConnection 统计信息

  1. 打开 about:webrtc。

  2. 展开 RTCPeerConnection 部分。

  3. 找到并展开您希望从中复制统计信息的 RTCPeerConnection 子部分。

  4. 按 Copy Stats Report

  5. 在 Bugzilla 错误中，按“附加新文件”按钮。

  6. 单击标记为 File 的大型文本框内部，然后粘贴复制的统计信息报告。

  7. 在 Description: 中添加描述性标签，例如“在帧丢失期间获取的 PeerConnection 统计信息样本”。

  8. 在下拉框中，在“从列表中选择”单选按钮旁边，选择“JSON 源 (application/json)”。

  9. 如果需要，在 comment 字段中添加描述性评论。

  10. 按“提交”按钮。

注意

将鼠标悬停在某些标题上将显示剪贴板图标。单击此图标会将该部分下的内容复制到剪贴板作为 JSON 文档。如果希望提交可用统计信息的一部分，这将非常有用。特别要注意的是 RTP Stats 标题，其按钮将复制最新的 RTP 统计信息，以及 SDP 部分，其按钮将复制 SDP 提供；答案；以及角色。

添加您的 about:webrtc 内容

对于呼叫质量问题，请通过提供您的 about:webrtc 信息来共享与网络会议相关的性能信息。请注意，应在相关呼叫仍在进行时收集此信息。

  1. 在您的呼叫仍在进行时，打开一个额外的标签页并访问 about:webrtc。

  2. 单击“清除历史记录”以清除其他最近呼叫（不再进行）的统计信息。

  3. 在页面底部，单击“保存页面”，并保存此文件。

  4. 将此文件作为附件添加到您的错误报告中。

此数据包含有关您的呼叫、用于设置呼叫的信令以及网络传输信息的统计信息。

诊断呼叫质量问题

about:webrtc 概述

about:webrtc 是用于调试 WebRTC 调用的浏览器内资源。about:webrtc 的主要受众是浏览器开发者，但它也可以用于需要对 WebRTC 调用进行故障排除的任何人。当没有呼叫数据显示时，about:webrtc 将显示如下

about:webrtc before any calls have been made

在进行任何呼叫之前 about:webrtc

请注意，有几个部分。在呼叫期间，每个部分将包含与 WebRTC 浏览器实现的不同方面相关的相关信息。

RTCPeerConnection 统计信息

此部分提供了有助于诊断活动呼叫的信息。它包含 RTCPeerConnection 创建参数、连接信息、协商详细信息、RTP 流统计信息、带宽统计信息和输出帧统计信息。

连接日志

当需要诊断底层传输问题时，可以在“连接日志”下找到日志。

用户修改的 WebRTC 配置

此部分将显示任何用户修改的偏好设置，这些偏好设置会影响浏览器组件的性能或行为，从而可能影响 WebRTC 调用。将鼠标悬停在此部分中显示的偏好设置路径上时，将出现剪贴板图标。单击该图标会将路径复制到剪贴板。然后可以将其粘贴到 about:config 中，以更改或将值重置为其默认值。

警告

此部分中的意外值可能是由已安装的扩展引起的。在可能的情况下，最好使用 about:profiles 在干净的配置文件中测试问题。

媒体上下文

用于确定编解码器可用性和功能的信息记录在“媒体上下文”下。

底部控制栏

about:webrtc 底部有一排按钮，允许用户执行各种操作。

“保存页面”按钮展开所有部分并显示一个对话框以保存页面内容。这将生成一个适合附加到错误报告的 HTML 文件。

如果遇到 WebRTC 问题，则 Enable WebRTC Log Preset 按钮是启动日志记录的非常快速的方法。按下该按钮将在一个新标签页中打开 about:logging，并选择 webrtc 预设。此预设包含所有 标准日志模块。日志记录将立即开始。如果需要更改该页面上的其他日志设置，可以自定义它们，然后按 Start Logging。如果希望将日志记录到分析器，则可能需要这样做。

如果遇到回声消除问题，可能会要求您提交回声消除日志。这些日志是通过按下 Start AEC Logging 按钮收集的。在积极遇到回声消除故障时，应按下该按钮以激活日志记录。

注意

生成回声消除日志与内容沙箱不兼容。如果沙箱处于活动状态并且按下 Start AEC Logging 按钮，系统将提示用户进一步说明。

音频/视频延迟

媒体延迟通常是由端点之间较长的物理路径引起的，尽管任何减慢数据包跳间传递速度的因素都可能是原因。请注意，这与网络路径的带宽不同，并且降低视频分辨率或音频采样率不会解决高延迟问题。往返时间或 RTT 是数据包从发送方到接收方再从接收方返回发送方所需的时间。如果两个端点之间的路径是对称的，则可以假设单向延迟是往返延迟的一半。

音频/视频延迟的第二个常见原因是抖动，即数据包到达时间间隔的可变性大小。为了平滑地播放传入的数据流，遇到抖动的接收器将不得不缓冲（延迟）传入的数据包。

使用 about:webrtc 诊断延迟

在 about:webrtc 中的关键指标是 RTT（往返时间）和抖动。它们可以在 PeerConnection 的 RTP 统计信息部分找到。PeerConnection 信息块最初处于最小化状态，需要展开一个块才能找到 RTP 统计信息部分

How to reveal the full statistics of a PeerConnection in about:webrtc

如何在 about:webrtc 中显示 PeerConnection 的完整统计信息

展开后，可以找到 RTP 统计信息部分并找到关键的诊断统计信息

Location in about:webrtc of jitter and RTT stats

在 about:webrtc 中抖动和 RTT 统计信息的位置

在此图中，我们可以看到抖动为 0 毫秒，往返延迟为 32 毫秒。此通话不应遇到任何明显的延迟。有关更多详细信息，请参阅下面的 延迟计算 附录部分。

如果感知到的延迟大于估计的延迟，则可能表示 Firefox 中存在需要调试的问题。在这种情况下，通过按下“复制报告”按钮获取当前统计信息的 JSON 副本，并将这些统计信息粘贴到您的 Bugzilla 错误报告中将很有帮助。

Location in about:webrtc of Copy Report button

在 about:webrtc 中“复制报告”按钮的位置

性能分析和日志记录

捕获 Firefox 性能配置文件

对于基本的性能问题，性能配置文件可以帮助工程师诊断视频格式、性能和渲染方面的问题。

  1. 访问 https://profiler.firefox.com/ 并启用 Profiler 工具栏按钮。

  2. 单击工具栏按钮的下拉箭头，并在设置下拉菜单中选择“媒体”。

  3. 打开一个选项卡并访问包含受影响媒体内容的页面。

  4. 单击 Profiler 工具栏主按钮以开始录制。

  5. 播放媒体，直到出现您遇到的问题。

  6. 再次单击 Profiler 工具栏按钮以停止录制。

  7. 当新的配置文件选项卡打开时，单击右上角的上传配置文件按钮。

  8. 复制生成的配置文件 URL 并将其发布到您的 Bugzilla 报告中。

此外，可以在性能配置文件中收集详细的日志，以帮助调试复杂问题。要启用收集具有低级调试功能的配置文件，请执行以下操作：

  1. 访问 https://profiler.firefox.com/ 并启用 Profiler 工具栏按钮。

  2. 在新选项卡中，访问 about:webrtc。单击“启用 WebRTC 日志预设”按钮，这将打开一个 about:logging 选项卡，其中包含预填充的信息。

  3. 在 about:logging 中，单击“开始日志记录”按钮。（您现在正在录制配置文件，配置文件工具栏切换按钮应自动选中。）

  4. 打开一个新选项卡进行测试，并查看您遇到问题的媒体。（重现后，请勿立即关闭此测试选项卡。）

  5. 切换到 about:logging 选项卡，单击“停止日志记录”，然后关闭测试选项卡。

  6. 等待大约 10 到 20 秒，以便自动打开一个包含生成的性能配置文件的新选项卡。

  7. 在配置文件选项卡的右上方，单击“上传本地配置文件”按钮以启动配置文件上传。上传完成后，将打开一个下拉文本字段，显示配置文件的 URL。选择此文本并复制。

  8. 与您正在合作的工程师共享配置文件的 URL 以供分析。

或者，可以设置以下环境变量

MOZ_LOG="jsep:5,sdp:5,signaling:5,mtransport:5,nicer:5,RTCRtpReceiver:5,RTCRtpSender:5,RTCDMTFSender:5,WebrtcTCPSocket:5,CamerasChild:5,CamerasParent:5,VideoEngine:5,ShmemPool:5,TabShare:5,MediaChild:5,MediaParent:5,MediaManager:5,MediaTrackGraph:5,cubeb:5,MediaStream:5,MediaStreamTrack:5,DriftCompensator:5,ForwardInputTrack:5,MediaRecorder:5,MediaEncoder:5,TrackEncoder:5,VP8TrackEncoder:5,Muxer:5,GetUserMedia:5,MediaPipeline:5,WebAudioAPI:5,webrtc_trace:5,RTCRtpTransceiver:5,ForwardedInputTrack:5,HTMLMediaElement:5,HTMLMediaElementEvents:5"

标准日志记录模块

标准日志记录模块

模块

组件

功能

备注

jsep

信令

JSEP 状态机

sdp

信令

SDP 解析

mtransport

网络

网络传输

nicer

网络

ICE 堆栈

RTCRtpReceiver

JS API

与接收媒体和媒体控制数据包相关的 JS API

RTCRtpSender

JS API

与发送媒体和媒体控制数据包相关的 JS API

RTCDMTFSender

JS API

与发送 DTMF 消息相关的 JS API

WebrtcTCPSocket

网络

CamerasChild

媒体捕获

内容进程端 IPC 通道，用于接收来自媒体捕获设备的帧

CamerasParent

媒体捕获

父进程端 IPC 通道，用于发送来自媒体捕获设备的帧

VideoEngine

媒体捕获

在父进程中协调从媒体捕获设备捕获帧

ShmemPool

媒体捕获

共享内存帧缓冲区的对象池，用于将媒体捕获帧从父进程传输到子进程

TabShare

媒体捕获

捕获选项卡内容以供共享

MediaChild

媒体

MediaParent

媒体

MediaManager

媒体

MediaTrackGraph

媒体

cubeb

媒体

MediaStream

媒体

MediaStreamTrack

媒体

DriftCompensator

媒体

ForwardInputTrack

媒体

MediaRecorder

媒体

MediaEncoder

媒体

TrackEncoder

媒体

VP8TrackEncoder

媒体

Muxer

媒体

MediaPipeline

网络

传输、媒体和 libwebrtc 组件之间的粘合代码

WebAudioAPI

webrtc_trace

webrtc

libwebrtc 日志记录

在 Firefox v123 之前，必须在运行时从 about:webrtc 中启用它，或者必须在启动时在 MOZ_LOG 环境变量中设置它。

RTCRtpTransceiver

JS API

实现 RTCRtpTransceiver 对象

HTMLMediaElement

ForwardedInputTrack

HTMLMediaElementEvents

非标准日志记录模块

标准日志记录模块

模块

组件

功能

备注

RTPLogger

网络

记录 RTP 和 RTCP 数据包片段

请参阅 调试加密数据包

检查呼叫性能问题

启用呼叫统计信息历史记录

在 Nightly 中默认启用呼叫统计信息历史记录。要在发布版本中启用，请打开 about:config，并将“media.aboutwebrtc.hist.enabled”更改为 true。这将保留最近几次呼叫的统计信息历史记录窗口，以便在呼叫完成后在 about:webrtc 中进行检查。

转储呼叫统计信息

可以转储活动呼叫的呼叫统计信息的 JSON 数据块，或者如果启用了呼叫统计信息历史记录，则转储最近呼叫的 JSON 数据块。在 about:webrtc 中有两个按钮可以执行此操作，“复制报告”和“复制报告历史记录”。前者将创建 PeerConnection 最近统计信息的副本。后者将复制 about:webrtc 为该 PeerConnection 累积的所有统计信息报告历史记录，这可能长达几分钟的统计信息。

调试加密数据包

警告

有一篇 博文 介绍了在日志中转储未加密的部分 RTP 和 RTCP 数据包的方法。虽然该文章中提供的信息仍然相关，但文章中提取数据包数据的命令已过时。下面提供了一种可行的方法；

使用 gecko 日志记录系统，可以输出未加密的、损坏的、部分的 RTP 数据包。这可能是调查数据包丢失和恢复、模拟广播和反馈的一个好途径。由于无法保证记录数据包的全部内容，因此这不太适合调试编码媒体方面的问题。这些记录的数据包可以转换为 PCAP 文件，然后可以在 Wireshark 中进行探索。此模块生成的日志可能非常大，因此可以很容易地通过文件大小识别哪些子进程日志文件包含数据包转储。

要开始 RTP 日志记录，必须启用 RtpLogger 日志模块。sync 选项也应该使用，因为它可以防止日志消息发生不希望的交错。以下是所需的最小日志设置

MOZ_LOG='sync,RtpLogger:5'

为了解释数据包内容，需要参考 SDP。Wireshark 不了解协商的详细信息，因此它无法直接解码媒体，也无法解码报头扩展。SDP 也可以记录，因此以下是一组更有用的日志设置

MOZ_LOG='sync,RtpLogger:5,jsep:5'

注意

在 macOS 上，使用 Homebrew 安装 Wireshark 和 text2pcap 非常简单

# Use only one of the following:
# ==============================

# To install the Wireshark GUI application and the command line utilities:
brew install --cask wireshark

# To install only the command line utilities:
brew install wireshark

可以使用 tee 从命令行启动的 Firefox 副本（例如，通过 mach）捕获日志输出。或者，可以通过环境变量 MOZ_LOG_FILE 或通过 about:logging 设置日志文件。

警告

如果子进程未创建日志文件，这可能是由于内容进程的沙盒化造成的。要解决此问题，必须选择沙盒中的一个位置、禁用内容沙盒或从命令行启动 Firefox（例如，从 Firefox 开发环境启动）

MOZ_LOG=sync,RtpLogger:5,jsep:5 MOZ_LOG_FILE= ./mach run 2>&1 | tee your.log

要生成 PCAP 文件，需要过滤日志以仅包含 RtpLogger 日志行，将其缩减为 text2pcap 预期的摄取格式，最后调用 text2pcap。

cat your.log  | rg 'RtpLogger.*RTC?P_PACKET|>>\s(?P<packet>.+$)' --only-matching  --replace '$packet' | text2pcap -D -n -l 1 -i 17 -u 1234,1235 -t '%H:%M:%S.' - your.output.pcap

注意

如果 rg（也称为 ripgrep）尚不可用，可以通过以下方法之一安装它

# Install through cargo on macOS, Linux, or Windows
cargo install ripgrep

# Install via Homebrew on macOS
brew install ripgrep

# ripgrep packages may be available through the package manager for your
# Linux distro

生成的 PCAP 文件可以使用 Wireshark 进行探索。目前，必须参考 SDP 才能解释 RTP 数据包。

# On most Linux distros
wireshark -d 'udp.port==1234,rtp' your.output.pcap

# On macOS when installed via Homebrew
open /Applications/Wireshark.app --args -d 'udp.port==1234,rtp' your.output.pcap

检查编解码器可用性和功能

当编解码器协商未按预期进行时，可以在几个有用的位置找到信息。SDP 提供和应答包含初始提供中编解码器的列表，以及应答中选择的这些编解码器的子集。

在实时通话中获取此信息的最简单方法是通过 about:webrtc。每个 RTCPeerConnection 都有自己的子部分，展开后包含一个 SDP 部分。有一些按钮可以显示提供和应答。根据哪一方是提供方，哪一方是应答方，可能会有本地提供和远程应答，或者远程提供和本地应答。

Firefox 根据可用性选择要提供的编解码器。某些编解码器（如 Opus 或 VP8）始终可用。某些编解码器在软件中可用，而某些平台上的某些编解码器在硬件中可用。H264 支持由第三方提供，并在首次请求使用时自动下载。根据网络情况，此过程可能需要可变的时间。

注意

在 about:support#media 的“媒体”部分中提供了具有播放支持的媒体编解码器的列表。并非所有媒体编解码器都存在并可供 Firefox 用于播放，都支持在 WebRTC 通话中使用。

要检查当前因素（包括首选项），这些因素用于计算除了编解码器存在之外的可用性，可以检查 about:webrtc 的“媒体上下文”部分。

example about:webrtc media context values

有关 WebRTC 可用编解码器的深入参考，请参阅 MDN 页面：WebRTC 使用的编解码器。

运行 WebRTC 测试

有多种测试提供了对 WebRTC 相关代码的覆盖。Web 平台套件为浏览器提供一致性测试。gtest 套件由单元测试组成。崩溃测试是一种回归测试，旨在诱发崩溃。存在模糊测试，以作者未预料到的方式使用 API。所有 WebRTC 测试都可以在本地使用 mach 或在 Try 上的 CI 中运行。此处详细概述了所有可用的测试类型，包括 WebRTC 代码未使用的测试类型 此处。

注意

运行 ./mach <verb> --help 是发现可以简化测试过程的选项的不可或缺的工具。

注意

在 Try 上的测试套件可能是多个逻辑测试套件的聚合。例如，Try 上的 mochitest-media 套件同时包含 WebRTC 和回放 mochitests。

警告

WebRTC 调用使用了许多内部计时器。这些计时器控制的行为包括传输选择、带宽估计、数据包丢失确定、媒体适配、唇同步、连接超时等等。有一些 Try 目标速度太慢，无法可靠地运行许多测试。在 Try 上首次运行特定测试之前，最好检查相关的测试套件清单。这可以通过 Searchfox.org 很容易地完成，方法是搜索并查看测试文件。如果该测试在一个或多个平台上被禁用，则详细信息将如下所示

Searchfox.org warning that the displayed test file has been disabled on Android

测试地图集

WebRTC 测试位置

组件

测试类型

测试文件位置

Try 套件

Treeherder 缩写

WebRTC

Mochitest

dom/media/webrtc/mochitests

mochitest-media

mda，M(mda)

Web 平台测试

testing/web-platform/tests/webrtc

wpt

wpt，W(wpt)

崩溃测试

dom/media/webrtc/tests/crashtests

crash

R(C)

WebRTC 信令

GTest

media/webrtc/signaling/gtest

gtest

gtest

WebRTC（gUM/gDDM）

浏览器 Chrome 测试（mochitest）

browser/base/content/test/webrtc

browser-chrome

bc，M(bc)

WebRTC 传输

CPPUnit

dom/media/webrtc/transport/test

cppunit

fuzztest

dom/media/webrtc/transport/fuzztest

fuzzing

SDP 解析器

模糊测试

dom/media/webrtc/tests/fuzztests

fuzzing

Web 平台测试

WPT 套件包含了各种 W3C 规范的符合性测试，例如：CSS、JS API 和 HTML。WebRTC 是一个 JS API，因此其测试属于 testharness.js 类型。这里有详细的 WPT 文档 此处 可用。Web 平台测试可以从本地运行

# Run the entire WebRTC WPT test suite
./mach wpt testing/web-platform/tests/webrtc

# Run a single test, e.g. RTCPeerConnection-createAnswer.html
./mach wpt testing/web-platform/tests/webrtc/RTCPeerConnection-createAnswer.html

# Run all of the PeerConnection tests, i.e. RTCPeerConnection-*.html
# NOTE that the `mach` verb in use is `test` not `wpt`
./mach test testing/web-platform/tests/webrtc/RTCPeerConnection

警告

在本地运行 WPT 测试可能会严重干扰用户的桌面工作环境，因为窗口会频繁出现并抢夺焦点。使用 mach 的 --headless 标记可以防止这种情况发生，如果用户的问题可以通过命令行输出进行评估，这将是一个很好的运行方式。

这些测试与主 Web 平台测试仓库 同步，同样地，我们的更改也会从我们的 树内副本 同步回该仓库。

警告

在 Try 中运行 WebRTC mochitests 是使用整个 Web 平台测试套件 wpt 完成的。因此，这可能很慢。

./mach try fuzzy --query 'wpt'

用户可以 在 Chromium 中运行相同的测试，如果需要比较不同浏览器之间的行为，也可以在 Safari 或 Servo 中运行。这可以通过 mach 直接完成，请参阅 在其他浏览器中运行测试 以了解更多详细信息。

Mochitests

WebRTC mochitests 是集成测试、回归测试和健全性测试。这些测试的需求与 WPT（Web 平台测试）套件中的规范一致性测试不一致。在编写新的 mochitest 之前，用户应该考虑是否可以将测试更好地表达为 WPT，所有浏览器都可以针对它进行测试。

本地运行 WebRTC mochitests 应该在 Firefox 开发环境中使用 mach 完成，如下所示

# Run the whole suite
./mach mochitest dom/media/webrtc/tests/mochitests

# Run a single test, e.g. test_peerConnection_basicAudioVideo.html
./mach mochitest dom/media/webrtc/tests/mochitests/test_peerConnection_basicAudioVideo.html
# Or
./mach mochitest test_peerConnection_basicAudioVideo.html

# Run all of the PeerConnection tests, i.e. test_peerConnection_*.html
./mach mochitest test_peerConnection

在 try 上，WebRTC mochitests 是较大的媒体测试套件的一部分。可以使用以下模糊查询轻松选择此套件

# Run the media mochitest suite on all regular platforms
./mach try fuzzy --query 'mochitest-media'

# Run the media mochitest suite only on Linux which will resolve far faster
./mach try fuzzy --query 'linux mochitest-media'

GTests

所有 gtests 都编译成一个单一的库目标：xul-test。这使得从 mach 运行 gtests 与其他测试类型略有不同。

# Run a single test by using Prefix.TestName, e.g. JsepSessionTest.FullCall
# https://searchfox.org/mozilla-central/rev/4d6a5b97428760d15bfcad13f8fc81439370a7ec/media/webrtc/signaling/gtest/jsep_session_unittest.cpp#1551
./mach gtest 'JsepSessionTest.FullCall'

# Run all the tests in a single Prefix, e.g. JsepSessionTest
./mach gtest 'JsepSessiontTest.*'

# Run all tests which have a Prefix.TestName containing the substring 'Jsep'
# See the table of selectors below
./mach gtest '*Jsep*'

# Run all the gtests for Firefox
./mach gtest

以下列出了一些用于执行特定 WebRTC gtests 的有用的子字符串选择器

WebRTC GTest 选择器

选择器

描述

文件

*Jsep*

JSEP（信令）测试

jsep_session_unittest.cpp jsep_trak_unittest.cpp

*Sdp*

SDP 解析测试

sdp_unittests.cpp

*MediaPipeline*

用于 RTP 媒体处理的 MediaPipline 和 MediaPipeline 过滤器测试

mediapipeline_unittest.cpp

*AudioConduit*

用于 RTP 音频媒体的 libwebrtc 粘合代码的 AudioConduit 测试

audioconduit_unittests.cpp

*VideoConduit*

用于 RTP 视频媒体的 libwebrtc 粘合代码的 VideoConduit 测试

videoconduit_unittests.cpp

有关 gtests 的更多一般信息，请参阅 此处 的文档。

模糊测试

通常不需要运行模糊测试，因为它在 CI 中以半连续的方式运行。用户更有可能需要响应模糊测试机器人提交的错误。如果用户有兴趣进行模糊测试，则应该参考 此处 提供的优秀文档。

代码图谱

许多组件协同工作以创建成功的 WebRTC 通话。在调试通话时，很难看到所有碎片的更大难题。下面提供了 WebRTC 相关源代码目录的列表，以帮助用户进行导航。

WebRTC 代码图谱

目录

组件

描述

备注

dom/media/webrtc

WebRTC

这是 Firefox WebRTC 代码的主要目录

dom/media/webrtc/common

WebRTC

这里包含 WebRTC 相关的实用程序代码

dom/media/webrtc/jsapi

JS API

这里包含 JavaScript WebRTC 接口的 C++ 实现

dom/media/webrtc/jsep

信令

这是 JSEP 状态引擎的实现

media/webrtc/libwebrtcglue

WebRTC（各种）

这是 libwebrtc 和 Firefox 之间的粘合代码

dom/media/webrtc/sdp

信令

这里包含 SDP 解析接口

dom/media/webrtc/tests

测试

这里包含 一些 WebRTC 相关的测试

dom/media/webrtc/third_party_build

构建

为供应商提供新版本的 libwebrtc 的脚本和配置位于此处

这不太可能与调试相关

dom/media/webrtc/transport

网络

这里包含 ICE 实现、MDNS 实现和传输代码

dom/media/webrtc/transportbridge

WebRTC

这里包含 MediaPipeline 和 MediaPipeline 过滤器代码，它们是传输和 libwebrtc RTP 堆栈之间的粘合代码

third_party/libsrtp

网络

这是 Firefox 使用的 SRTP 实现

third_party/libwebrtc

WebRTC（各种）

libwebrtc 处理 WebRTC 通话在传输层之上和表示层之下的许多方面

third_party/rust/webrtc-sdp

信令

webrtc-sdp 是 WebRTC 专用 SDP 解析器的 Rust 实现

third_party/sipcc

信令

sipcc 是通用 SDP 解析器的 C 实现

它包含许多本地修改

dom/media

媒体捕获

GetUserMedia 和相关类位于此处

这里还有许多其他不相关的媒体源文件

dom/webidl

WebIDL（JS API）

这里包含 WebRTC JS API 的 WebIDL 定义以及许多其他 WebIDL 定义

RTC*.webidl

标准文档

在调试 API 行为时，可能需要查阅 WebRTC 的规范。ECMAScript API 在几个 W3C 标准中定义，webrtc-pc 和 webrtc-stats。合并到 WebRTC 中的 IETF 标准数量众多，无法在此列出。用户可以在 webrtc-pc 规范的 规范性引用 部分找到这些标准。

附录：延迟计算

就所有意图和目的而言，抖动和 RTT 本质上是累加的。如果报告了 25 毫秒的抖动和 272 毫秒的 RTT，则可以估计从发送端传输到接收端播放的预期延迟为

25ms + (272ms / 2) = 161ms