3、捕获延迟优化：摄像头采集延迟、麦克风采集延迟、采集参数调优

捕获延迟，说白了就是音视频数据从物理世界进入数字世界的「第一道坎」。很多开发者把精力都放在编码、网络传输上，结果发现延迟还是高——回头一查，摄像头采集就卡了 100ms。嗯，这里要注意：采集端的延迟往往是整个链路的起点，起点慢了，后面再怎么优化也追不回来。

我个人习惯把捕获延迟拆成三块来看：设备本身的物理延迟、驱动/API 层的缓冲延迟、以及参数配置不当带来的额外开销。咱们一个一个说。

3.1 摄像头采集延迟：从光子到帧

摄像头采集延迟，不是按下快门到拿到数据那么简单。它包含三个环节：

• 曝光时间：传感器感光的时间。光线越暗，曝光越长。室内场景下，30fps 的摄像头单帧曝光通常在 16-33ms 之间。
• 传输时间：传感器数据通过 MIPI/USB 接口传到主控芯片。USB 2.0 的 720p 帧传输大约 5-10ms。
• 缓冲排队：驱动层或 SDK 内部维护的帧队列。这个最容易被忽略。

我在项目中遇到过一个问题：某款 USB 摄像头在 Windows 上采集 1080p@30fps，实测延迟高达 120ms。排查后发现，驱动内部默认缓冲了 4 帧。4 帧 × 33ms = 132ms，几乎全耗在排队上了。把缓冲降到 1 帧后，延迟直接降到 35ms。

3.2 麦克风采集延迟：被低估的「暗雷」

麦克风采集延迟通常比摄像头小，但它的影响更隐蔽。音频延迟 20ms 人耳就能察觉，而视频延迟 100ms 可能还能接受。所以音画同步问题，很多时候是音频先「跑」了。

麦克风采集延迟主要来自：

• ADC 转换：模拟信号转数字信号，现代 Codec 一般在 1-3ms。
• 音频缓冲区：这是大头。WebRTC 默认音频缓冲区大小是 10ms，但很多系统驱动会设成 20ms 甚至 40ms。
• 回声消除处理：AEC 模块会引入额外的延迟，通常 5-10ms。

缓冲区大小	理论延迟	适用场景	风险
10ms	10-15ms	实时通话、直播连麦	CPU 负载高，低端设备可能爆音
20ms	20-25ms	大多数场景（推荐）	延迟可接受，稳定性好
40ms	40-50ms	非实时录制、语音消息	延迟明显，不适合双向通话

3.3 采集参数调优：用配置换延迟

WebRTC 提供了丰富的采集参数控制接口。调优的核心思路是：在画质可接受的前提下，尽可能降低采集端的处理时间。

3.3.1 分辨率与帧率的选择

分辨率越高，单帧数据量越大，传输和处理时间越长。帧率越高，单位时间内处理帧数越多，但每帧的曝光时间被压缩。

• 720p@30fps：大多数场景的甜点。延迟约 30-50ms，画质够用。
• 1080p@30fps：画质好，但延迟增加 10-20ms。适合直播，不适合实时互动。
• 480p@15fps：极致低延迟，但画质差。仅用于网络极差时的保底方案。

3.3.2 关键参数配置示例

下面是我在项目中常用的采集参数配置模板。注意，不同平台（Windows/macOS/iOS/Android）的 API 有差异，但思路一致。

// JavaScript 端采集约束示例
const constraints = {
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 },
    // 关键：关闭自动对焦和自动白平衡，减少处理延迟
    focusMode: 'manual',
    whiteBalanceMode: 'manual',
    // 降低亮度/对比度处理，让数据更「原始」
    brightness: { exact: 128 },
    contrast: { exact: 128 }
  },
  audio: {
    sampleRate: { ideal: 48000 },
    channelCount: { ideal: 1 },  // 单声道，减少数据量
    // 关闭自动增益控制，避免 AGC 引入额外延迟
    autoGainControl: false,
    echoCancellation: true,
    noiseSuppression: false  // 降噪会引入延迟，非必要不开
  }
};

3.4 采集延迟优化全景图

为了让你更直观地理解整个采集延迟的构成和优化点，我画了一张流程图。

3.5 实测与验证

理论说再多，不如动手测一测。我常用的方法很简单：

1. 摄像头延迟测试：用手机秒表 App 显示毫秒数，对着摄像头拍。在画面中同时显示秒表和系统时间，对比两者的差值。
2. 麦克风延迟测试：用两个设备，一个播放已知音频信号，另一个录制。分析录制信号与原始信号的偏移量。
3. WebRTC 内置工具：chrome://webrtc-internals 里可以看到采集端的 jitter 和延迟统计，虽然不够精确，但能反映趋势。