录制性能优化：控制录制码率、关键帧间隔设置、硬件加速编码、低性能设备降级方案

说实话，做 WebRTC 录制最怕什么？不是功能实现不了，而是录出来的视频卡成幻灯片，或者文件大得离谱。我早期做的一个项目，用户反馈说录了 5 分钟的视频，结果文件有 2 个 G——这谁受得了？

所以这一章，咱们就聊聊怎么让录制跑得又快又稳。说白了，就是四个方向：码率控制、关键帧设置、硬件加速、低性能设备兜底。每个点我都踩过坑，咱们一个一个说。

1. 控制录制码率：别让视频“撑死”

码率这东西，你设得太高，文件体积爆炸；设得太低，画面糊成一团。我个人的习惯是，先根据场景定一个基准值。

举个例子，录一个普通的会议场景，720p 分辨率下，我一般把视频码率控制在 1-2 Mbps。如果是录屏幕共享（比如 PPT 演示），码率可以低一些，因为画面变化少。但如果是录游戏或者动态画面，码率就得往上提。

代码实现上，我们通过 MediaRecorder 的 bitsPerSecond 参数来控制。不过要注意，这个参数不是所有浏览器都支持。我一般会加个降级逻辑：

// 设置码率，单位 bps
const options = {
  mimeType: 'video/webm;codecs=vp9',
  videoBitsPerSecond: 1500000, // 1.5 Mbps
  audioBitsPerSecond: 128000   // 128 kbps
};

let recorder;
try {
  recorder = new MediaRecorder(stream, options);
} catch (e) {
  console.warn('指定码率失败，使用默认值');
  recorder = new MediaRecorder(stream);
}

这里有个坑：videoBitsPerSecond 在部分浏览器上会被忽略。我曾经在某个版本的 Firefox 上遇到过，明明设了 2 Mbps，结果录出来还是默认码率。所以建议你录制完成后，检查一下文件大小，做个校验。

2. 关键帧间隔设置：让视频“能拖能拽”

关键帧，也叫 I 帧。它决定了你在播放视频时，能不能随意拖动进度条。如果关键帧间隔太长，用户拖到某个位置，画面会卡住好几秒才能恢复。

我个人习惯把关键帧间隔设在 2-4 秒。为什么呢？因为 WebRTC 默认的关键帧间隔可能长达 10 秒甚至更长。你想想看，用户录了一个 30 分钟的视频，想跳到中间看某个片段，结果等了 5 秒才出画面——这体验太糟糕了。

在 WebRTC 中，关键帧间隔是通过 RTCRtpSender 的 setParameters 来控制的。不过要注意，这个操作需要在 RTCPeerConnection 建立连接之后才能做。

// 设置关键帧间隔为 2 秒
const sender = pc.getSenders().find(s => s.track.kind === 'video');
if (sender) {
  const params = sender.getParameters();
  if (!params.encodings) {
    params.encodings = [{}];
  }
  params.encodings[0].maxFramerate = 30;
  // 关键帧间隔：每 60 帧一个 I 帧（假设 30fps，即 2 秒）
  params.encodings[0].keyFrameInterval = 60;
  await sender.setParameters(params);
}

3. 硬件加速编码：让 CPU 喘口气

编码是个吃 CPU 的活。如果你在录制的同时还在做其他事情（比如直播、推流），CPU 很容易飙到 100%。这时候，硬件加速编码就派上用场了。

WebRTC 默认会尝试使用硬件编码器，但并不是所有场景都能成功。我遇到过的情况是：在 Windows 上，VP9 编码器经常回退到软件编码，而 H.264 则能顺利启用硬件加速。

所以我的建议是：优先使用 H.264 编码，并显式指定硬件加速偏好。

// 优先使用 H.264 编码，启用硬件加速
const options = {
  mimeType: 'video/webm;codecs=h264',
  videoBitsPerSecond: 1500000,
  // 部分浏览器支持 hardwareAcceleration 参数
  hardwareAcceleration: 'prefer-hardware'
};

// 检查是否支持
if (!MediaRecorder.isTypeSupported(options.mimeType)) {
  console.warn('H.264 不支持，回退到 VP8');
  options.mimeType = 'video/webm;codecs=vp8';
}

嗯，这里要注意：硬件加速虽然能降低 CPU 占用，但编码质量可能不如软件编码。如果你对画质要求极高（比如录专业课程），可以考虑在高端设备上使用软件编码。

4. 低性能设备降级方案：别让老机器“罢工”

这是我最想强调的一点。很多开发者只在高配 MacBook 上测试，结果一到用户的老旧 Windows 笔记本上，直接卡死。

我曾经在一个教育项目中，用户用的是 2015 年的 Chromebook，录了 10 分钟就崩溃了。后来我加了一套降级逻辑，才解决问题。

降级方案的核心思路是：检测设备性能，动态调整录制参数。

具体怎么做？我一般分三步：

1. 检测 CPU 核心数和内存：通过 navigator.hardwareConcurrency 和 navigator.deviceMemory 获取。
2. 检测帧率：在录制前，先跑一个 1 秒的测试录制，看实际帧率是否达标。
3. 动态降级：如果性能不足，降低分辨率、码率、帧率。

// 降级检测函数
function getDeviceLevel() {
  const cores = navigator.hardwareConcurrency || 4;
  const memory = navigator.deviceMemory || 4;
  
  if (cores >= 8 && memory >= 8) return 'high';
  if (cores >= 4 && memory >= 4) return 'medium';
  return 'low';
}

// 根据设备等级设置录制参数
function getRecordingOptions(deviceLevel) {
  const baseOptions = {
    mimeType: 'video/webm;codecs=vp8'
  };
  
  switch (deviceLevel) {
    case 'high':
      return { ...baseOptions, videoBitsPerSecond: 2500000, width: 1280, height: 720, frameRate: 30 };
    case 'medium':
      return { ...baseOptions, videoBitsPerSecond: 1000000, width: 854, height: 480, frameRate: 24 };
    case 'low':
      return { ...baseOptions, videoBitsPerSecond: 500000, width: 640, height: 360, frameRate: 15 };
  }
}

知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以看到，性能优化不是单一维度的，而是从编码参数、硬件能力、设备检测三个方向同时发力。

你看，这四个方向其实是环环相扣的。码率控制决定了文件大小，关键帧间隔影响了播放体验，硬件加速减轻了 CPU 负担，而降级方案则是最后的兜底。我个人的建议是：先做降级检测，再根据设备能力动态调整其他参数。这样既能保证高端设备的体验，又不会让老机器崩溃。

最后说一句：性能优化没有银弹。你需要在画质、流畅度、文件大小之间做权衡。多在实际设备上测试，尤其是那些你平时看不上眼的低端机——它们才是用户量最大的群体。