现象

视频不是持续变慢，而是停在某一帧，随后又连续恢复。这通常表示 RTP 包抖动/丢失或发送端编码供给中断，而不是页面渲染整体卡死。

根因模型

报警手机同时执行 WebRTC H264 实时编码和 MediaRecorder VP8 录像编码，并把录像分片通过 HTTP 上传。两套编码会争抢移动端硬件编码器/CPU；实时 RTP 与 TCP 上传又争抢 Wi-Fi 上行。实时链路缺包时，值班端会停留在上一帧，等下一个可解码关键帧后恢复。

验证方法

先关闭报警端录制上传，只保留 WebRTC；若卡顿消失，再恢复录制进行 A/B 对比。还应检查 WebRTC stats 中 packetsLost、jitter、framesDropped 和 candidate pair 类型。

设计原则

报警端优先保证实时通话；录像应在值班端对收到的流执行，或采用单次编码分发方案。实时视频应设置明确的发送码率上限，并在协商完成后调用 RTCRtpSender.setParameters，避免移动浏览器静默忽略限制。

后续优化

  1. 增加可见的 WebRTC stats 诊断面板。
  2. 根据丢包率和 RTT 动态调节分辨率/帧率/码率。
  3. 为录像上传增加低优先级、限速和网络恢复策略。
  4. 明确区分直连、TURN 中继和服务端旁听链路。

本文归档于个人知识库 · 领域：CS & AI · 模块：04 Project_CS_AI/Web