求助：Chrome中WebRTC视频通话卡顿，Firefox/Safari运行正常

这种特定浏览器+网络场景下的WebRTC卡顿问题确实挺闹心的，结合你观察到的现象和对Chrome编码丢帧的推测，咱们可以从这几个方向入手排查和修复：

• 验证帧丢弃的核心推测
  先通过Chrome自带的chrome://webrtc-internals/工具实锤问题：重点关注googFrameRateSent（发送帧率）、googFrameRateReceived（接收帧率）、googEncodeUsagePercent（编码使用率）这几个统计项，如果发送帧率正常但接收帧率骤降，或者编码使用率长期接近100%，那大概率是编码环节出现了帧丢弃。同时在Android端开启WebRTC debug日志，Chrome端用console.log跟踪ontrack事件里的帧数据，对比两端的帧数量差，确认丢帧发生在哪个环节。

• 排查Chrome编码器的兼容性变化
  你的代码是半年前写的，这段时间Chrome可能对VP8/VP9/H.264编码器做了策略更新，比如硬件加速逻辑、带宽适配规则。可以尝试两个操作：

  1. 在创建RTCOfferOptions时强制指定编码器偏好，比如videoCodecPreferences: ['H264', 'VP8']，切换编码器看看卡顿是否缓解；
  2. 暂时关闭Chrome的硬件加速（设置→系统→取消勾选「使用硬件加速模式（如果可用）」），测试是否是硬件编码的兼容性问题。

• 调整带宽控制与拥塞策略
  蜂窝网络下立刻卡顿，说明Chrome的带宽估计机制在跨网络场景下判断不准。可以手动干预：

  • 通过RTCRtpSender.setParameters()设置maxBitrate，比如限制在1Mbps左右，降低带宽压力；
  • 启用scaleResolutionDownBy参数，动态降低视频分辨率，适配低带宽环境；
  • 尝试切换拥塞控制算法，比如在SDP中添加a=ccm:goog-nr启用谷歌的拥塞控制逻辑，看是否改善卡顿。

• 检查Android端的视频采集配置
  虽然Firefox/Safari正常，但Android端的采集参数可能和Chrome编码逻辑不兼容：

  • 限制采集帧率为30fps、分辨率为720p，避免过高的原始数据量让Chrome编码处理不过来；
  • 关闭Android端的自动帧率调整功能，固定采集帧率，防止设备自动降帧和Chrome的编码逻辑冲突。

• 验证Chrome版本的影响
  确认出现问题的Chrome具体版本，对比测试不同版本（比如稳定版、测试版、半年前的旧版本），如果是某个版本更新引入的问题，可以暂时回退到稳定版本，同时向Chrome团队提交包含复现步骤的bug报告。

内容的提问来源于stack exchange，提问作者Praveen Kumar