WebRTC视频卡顿但getStats()显示带宽充足时，应优先检查transport类型stats中的availableOutgoingBitrate，若持续低于800kbps则实际可用带宽不足；需动态同步调整scaleResolutionDownBy和maxBitrate，并确保setParameters()参数合法，同时移动端建议设置degradationPreference: 'maintain-framerate'缓解切分辨率黑屏。
WebRTC 视频卡顿但 getStats() 显示带宽充足？先查 transport 层真实可用带宽
很多情况下，RTCPeerConnection.getStats() 返回的 availableOutgoingBitrate 看似够用（比如 2.5 Mbps），但视频依然频繁降帧、绿屏或卡死。这不是码率设低了，而是 WebRTC 底层实际能用的带宽被 NAT、防火墙、中间代理或拥塞控制算法压制了——尤其在企业内网或移动热点下。
真正该盯的是 transport 类型的 stats 中的 availableOutgoingBitrate（不是 media-source 或 track 下的同名字段），它反映网络栈当前允许的最大发送速率。如果这个值持续低于 800 kbps，哪怕你设了 1280×720@15fps，也大概率撑不住。
- 用
setInterval(() => pc.getStats().then(stats => { /* 过滤 type === 'transport' */ }), 1000)持续抓取 - 不要依赖首次连接后的单次统计；带宽可能在 3–5 秒后才收敛
- Chrome 120+ 开始，
availableOutgoingBitrate在弱网下会更保守，比旧版低 20%～40%
动态降分辨率 ≠ 降码率：必须同时调 scaleResolutionDownBy 和 maxBitrate
只改 maxBitrate 不会触发分辨率缩放，浏览器仍按原始尺寸编码，只是压得更狠——画质崩、CPU 升高、甚至触发编码器 fallback 到软编。真要适配弱网，得双管齐下。
通过 sender.getParameters() 获取当前参数，修改后用 sender.setParameters() 提交：
立即学习“前端免费学习笔记（深入）”；
const params = sender.getParameters(); params.encodings[0].scaleResolutionDownBy = 2; // 1280×720 → 640×360 params.encodings[0].maxBitrate = 800000; // 单位是 bps sender.setParameters(params);
-
scaleResolutionDownBy必须是 2 的整数幂（1, 2, 4），不能设 1.5 - 设为 1 表示不缩放，但别留空或删掉该字段，否则部分 Safari 版本会忽略整个 encoding 配置
- Android Chrome 对
scaleResolutionDownBy支持稳定，iOS Safari 16.4+ 才完全支持
RTCRtpSender.setParameters() 失败却不报错？检查 encodings 数组长度和 rid
调用 setParameters() 后视频没变化，控制台也没报错，大概率是参数结构不合法。WebRTC 规范要求：如果启用了 simulcast（即多个 encodings），每个 encoding 必须有唯一 rid；如果没开 simulcast，encodings 数组长度必须为 1，且不能带 rid。
- 常见错误：从 simulcast 配置里 copy 出来一个 encoding，直接塞进非 simulcast sender，结果因多出
rid字段被静默忽略 - 检查方式：
sender.getParameters().encodings.length—— 非 simulcast 场景下必须等于 1 - 修改前先
JSON.stringify(params)打印出来，确认没有多余字段（如active、scaleResolutionDownBy写成字符串而非数字）
移动端切分辨率后黑屏 1–2 秒？加 degradationPreference: 'maintain-framerate'
iOS Safari 和部分 Android 厂商定制 WebView 在分辨率突变时，会清空编码器上下文，导致画面中断。这不是 bug，是硬件编码器重初始化的物理延迟。
缓解方法是在创建 RTCRtpTransceiver 时指定降级策略：
pc.addTransceiver(videoTrack, {
direction: 'sendonly',
sendEncodings: [{ maxBitrate: 1200000 }],
degradationPreference: 'maintain-framerate'
});-
'maintain-framerate'会让编码器优先保帧率，牺牲清晰度；'maintain-resolution'则相反，容易卡顿 - 该选项仅影响 sender，receiver 侧无需设置
- 注意：Firefox 不支持此字段，需做 UA 判断或 fallback 到固定低分辨率
最麻烦的其实是跨厂商设备兼容性——比如某款国产平板的 MediaRecorder 和 WebRTC 共用同一套底层编码器，调一次 setParameters() 就可能让后续录屏功能失效。这种问题没法靠标准 API 解决，只能靠灰度放量 + 设备白名单兜底。
