WebRTC出/入站RTP视频流帧尺寸匹配延迟问题咨询

现象说明 #

已通过MediaStreamTrack.applyConstraints()配置视频采集约束，但接收端侧的远端MediaStreamTrack初始分辨率低于设定值，需要10-20秒才会缓慢适配到实际帧尺寸，目前需要可实现源端与目标端视频轨道帧尺寸始终保持匹配的实现方案。

延迟产生的核心机制 #

该适配延迟并非配置错误，是WebRTC默认运行逻辑导致的，用户观察到的10-20秒适配周期，基本和WebRTC默认拥塞控制从初始低码率爬升到目标带宽的周期完全重合，具体触发点包括：

• 初始建连阶段，WebRTC编码器默认从低分辨率、低码率档位启动发送流程，避免建连初期的网络瞬态拥塞，不会直接按照约束值拉满发送分辨率
• 接收端的MediaStreamTrack分辨率会完全跟随实际接收到的编码帧尺寸动态变化，不会提前同步源端预先设置的约束参数
• 部分浏览器中applyConstraints()是异步生效的，在采集端参数未完全刷新时，轨道就已经被送入PeerConnection的发送通道，进一步拉长了分辨率对齐的时间

可实现双端帧尺寸实时匹配的操作方法 #

• 提前指定发送端的固定编码分辨率
  在轨道加入PeerConnection后，立刻通过RTCRtpSender.setParameters()强制限定编码的最大分辨率，跳过编码器的低分辨率启动探测逻辑：

  const videoSender = peerConnection.getSenders().find(sender => sender.track?.kind === 'video');
  const encodeParams = videoSender.getParameters();
  encodeParams.encodings[0].maxWidth = 1280; // 替换为实际目标分辨率宽度
  encodeParams.encodings[0].maxHeight = 720;  // 替换为实际目标分辨率高度
  encodeParams.encodings[0].maxBitrate = 2500 * 1000; // 匹配目标分辨率的码率
  await videoSender.setParameters(encodeParams);
  

• 等采集端约束完全生效后再启动连接
  必须等待applyConstraints()返回的Promise完全resolve，同时监听源端轨道的resize事件，确认采集帧尺寸达到约束目标后，再将轨道加入PeerConnection启动媒体协商流程。
• 关闭远端视频的动态尺寸适配逻辑
  部分浏览器会根据远端视频元素的DOM显示尺寸动态调整解码分辨率，可提前给挂载远端流的<video>元素设置固定的宽高值（与目标分辨率比例一致），避免触发浏览器的动态分辨率协商。
• 对齐初始拥塞控制的目标码率
  建连时可通过RTCRtpSender.setParameters()设置匹配目标分辨率的初始码率目标，跳过WebRTC内部从低码率逐步探测到目标码率的缓慢爬升过程。

关联排查参考材料 #

• RTCInboundRTPVideoStream维度的入方向流统计数据，可查看接收端实际解码分辨率、帧速率、丢包率的实时变化曲线
• RTCOutboundRTPVideoStream维度的出方向流统计数据，可查看发送端实际编码分辨率、码率、关键帧发送的实时变化曲线
• MediaCapture Main规范issue #647中关于轨道尺寸同步机制的相关讨论内容

内容的提问来源于stack exchange，提问作者Vipin J S