要在火狐浏览器里深入捕获并调试WebRTC音视频推流的底层数据，关键不是点开几个统计面板看封装结果。而是绕过应用层，直接观察原始媒体流怎么生成、编码前长什么样、以及连接协商时谈了什么细节。否则，你看到的永远是“马后炮”式汇总数字，对定位问题帮助有限。

先做几个基本确认，再一步步动手。

确认WebRTC功能已启用并进入安全上下文

打开Firefox地址栏，输入about:config回车，搜索media.peerconnection.enabled，确保它是true。如果被禁用了，双击一下就能切换回来。这一步不难，但容易忽略。

更重要的一点是：所有WebRTC媒体采集操作——包括getUserMedia和getDisplayMedia——都只会在HTTPS或localhost环境下生效。如果你在普通的HTTP非本地域名下运行，na vigator.mediaDevices会直接变成undefined，连个报错提示都未必能看到。测试前务必确认浏览器地址栏是带锁的。

捕获原始音视频流（不经过编码压缩）

拿到原始流是第一步，这里有两种常用方法。

方法一：直接使用getUserMedia

在控制台执行下面这段代码：

na vigator.mediaDevices.getUserMedia({video: true, audio: true}).then(stream => { window.localStream = stream; console.log("原始流已捕获", stream); });

这一步拿到的是浏览器从设备驱动读取的原始帧数据，还没进编码器。你可以用它来分析采集延迟、帧率有没有抖动、或者YUV格式是否异常。这是最“原汁原味”的媒体源。

方法二：用captureStream()劫持已有HTML元素

如果页面上已经有一个或，可以直接对它调用captureStream(60)。这个方法的优势是不触发设备权限弹窗，流的内容完全由源元素的渲染节奏决定。缺点也很明显：它拿不到音频轨道，除非源元素本身已经包含了音频。另外，注意帧率参数跟不上实际渲染速度的话，流会掉帧。

查看实时ICE候选、SDP交换与轨道级统计

原始流到手之后，接下来要看连接层面的细节。Firefox内置了一个非常好用的调试页面。

第一步：访问内置调试页

在地址栏输入about:webrtc并回车，页面会自动加载当前所有WebRTC连接实例。你可以把它理解成一个WebRTC版的“任务管理器”。

第二步：定位目标连接

在“Active PeerConnections”列表中找到你要调试的那个推流连接——通常标签里会显示RTCPeerConnection或者你自定义的id。点右侧的“Show Details”展开明细。

第三步：重点观察三类数据

• ICE Stats：检查candidate-pair的状态是否为succeeded。如果长期停留在checking，说明NAT穿透失败，很可能需要检查STUN/TURN服务器配置。
• SDP：切换到这个标签页，对比local/remote的offer和answer，确认video codecs里是否包含VP8/VP9/A V1。某些企业防火墙会故意过滤H.264的payload type，导致协商失败——这种情况比你想象的更常见。
• Media Statistics：下拉选择outbound-rtp轨道，看framesEncoded是否持续增长。如果这个数值卡在某个数字不动了，基本可以判断编码器已崩溃或者流被静音了。

这三个层面看下来，大部分连接问题都能定位。

导出完整WebRTC日志用于离线分析

实时看数据固然方便，但有些深层次问题（比如花屏、卡顿、首帧延迟过高）需要离线细看帧级别的日志。Firefox支持导出非常详细的调试日志。

方法1：启用详细日志输出

在about:config中新建一个布尔型配置项media.webrtc.debug.aec_dump_enabled，设为true。再新建一个整数型配置项media.webrtc.debug.log_file_path，值设为一个绝对路径。比如/tmp/webrtc_log.txt（Linux/macOS）或C:webrtclog.txt（Windows）。

方法2：触发日志捕获

重启Firefox → 打开推流页面 → 在about:webrtc页面点击“Start Logging”按钮 → 完成推流测试后点击“Stop Logging”。日志文件会立刻写入你指定的路径。

这份日志包含每一帧的采集时间戳、编码耗时、NALU包拆分详情、RTP序列号跳变等信息。可以说，它是定位花屏、卡顿、首帧延迟的根本依据。如果你手头没有更好的工具，这个日志比大部分第三方分析工具都靠谱。

顺便提一句，日常调试时可以把getUserMedia捕获的原始流结合about:webrtc的统计一起看，往往能一眼看出问题出在采集端还是编码传输端。掌握这套方法，你在火狐上调试WebRTC的底层数据就不再是黑盒操作了。