编码器选择策略：平台检测与动态回退机制

编码器选不对，性能直接崩。这话听起来有点绝对，但我在实际项目中确实见过太多次了——明明硬件编码器跑得好好的，换个设备就花屏、卡顿、甚至直接崩溃。说白了，WebRTC 的编码器选择不能靠「猜」，得有一套完整的检测与回退机制。

这一章，我们就来聊聊怎么在不同平台上做编码器检测，以及当首选编码器不可用时，如何优雅地降级。

为什么需要平台检测？

你想想看，iOS 和 Android 的硬件编码器能力完全不同。就算都是 Android，高通和联发科的芯片表现也差很多。我遇到过最离谱的一次，某款国产手机在 H.264 编码时，码率超过 2Mbps 就直接黑屏——硬件编码器本身有 bug。

所以，平台检测不是「要不要」的问题，而是「怎么做」的问题。

平台检测的三大维度

我个人习惯把检测分成三个层面：

1. 能力查询——编码器是否存在？支持哪些分辨率、码率、帧率？
2. 运行时检测——编码器实际工作是否正常？有没有异常丢帧、编码超时？
3. 性能基准——编码器在当前设备上的真实表现如何？

下面这张图可以帮你快速理解整体流程：

平台检测的具体实现

先看 Web 端。浏览器通过 navigator.mediaCapabilities 和 MediaRecorder.isTypeSupported 提供编码能力查询。但这里有个坑——这些 API 返回的是「理论上支持」，不是「实际可用」。

// 基础能力查询示例
async function checkEncoderSupport() {
  const config = {
    type: 'webrtc',
    video: {
      contentType: 'video/H264',
      width: 1920,
      height: 1080,
      bitrate: 5000000,
      framerate: 30
    }
  };

  try {
    const result = await navigator.mediaCapabilities.encodingInfo(config);
    return {
      supported: result.supported,
      smooth: result.smooth,
      powerEfficient: result.powerEfficient
    };
  } catch (e) {
    console.warn('能力查询失败，默认回退', e);
    return { supported: false, smooth: false, powerEfficient: false };
  }
}

Android 平台的特殊处理

Android 的碎片化问题，做过多媒体开发的人都懂。不同厂商对 MediaCodec 的实现差异巨大。我总结了一套检测策略：

检测项	方法	常见坑点
编码器存在性	MediaCodecList.findDecoderForFormat	部分设备返回空但实际可用
分辨率支持	CodecCapabilities.getVideoCapabilities	支持列表可能不完整
码率范围	VideoCapabilities.getBitrateRange	高通芯片常报错范围偏大
帧率稳定性	实际编码测试 5 秒	低端芯片帧率波动大

嗯，这里要注意一点：不要只查一次。我习惯在编码器初始化时做一次完整检测，然后在运行过程中每隔 30 秒做一次轻量检测。因为有些设备在发热降频后，编码器能力会动态下降。

动态回退机制的设计

回退不是简单的「不行就换」，得有层次。我个人喜欢用三级回退策略：

1. 参数降级——降低分辨率、码率、帧率，尝试让当前编码器继续工作
2. 编码器切换——从 H.264 硬件切到 H.264 软件，或从 H.264 硬件切到 VP8 硬件
3. 完全降级——切到纯软件编码，牺牲性能保可用性

回退触发条件

什么时候该回退？我总结了几个关键指标：

• 编码超时——单帧编码耗时超过 50ms（30fps 场景）
• 输出异常——连续 3 帧输出大小为 0 或明显偏小
• 质量下降——PSNR 或 SSIM 低于阈值（这个需要额外计算）
• 系统反馈——Android 的 MediaCodec.Callback.onError 被触发

你可能会问：这些指标怎么量化？我一般会在初始化时先跑一段基准测试，记录正常编码的耗时和输出大小，然后以这个为基准设定阈值。说白了，就是先知道「正常」是什么样，才能判断「异常」。

回退的平滑过渡

回退过程中最怕什么？画面卡顿、音画不同步。我建议的做法是：

// 回退切换示例
async function fallbackEncoder(currentEncoder, targetEncoder) {
  // 1. 暂停当前编码器输出
  currentEncoder.pause();

  // 2. 创建新编码器并预热
  const newEncoder = await createEncoder(targetEncoder);
  await newEncoder.warmUp();

  // 3. 关键帧对齐
  const keyFrame = await currentEncoder.requestKeyFrame();
  newEncoder.feedKeyFrame(keyFrame);

  // 4. 切换输出流
  switchOutputStream(currentEncoder, newEncoder);

  // 5. 释放旧编码器
  currentEncoder.release();
}

平台差异总结

最后，我把几个主流平台的编码器选择策略整理了一下：

平台	首选编码器	回退方案	注意事项
iOS	VideoToolbox H.264	VideoToolbox H.265 → 软件 H.264	iOS 12+ 支持同步编码，性能更好
Android	MediaCodec H.264	MediaCodec VP8 → 软件 VP8	注意厂商定制 ROM 的兼容性
Windows	MediaFoundation H.264	Intel QSV → 软件 H.264	NVIDIA NVENC 需要单独检测
macOS	VideoToolbox H.264	VideoToolbox H.265 → 软件 H.264	Apple Silicon 和 Intel 表现不同

说实话，编码器选择这件事，没有银弹。每个平台都有自己的脾气，我们能做的就是做好检测、备好回退、持续监控。我做了这么多年多媒体，最深的体会就是：永远不要相信编码器会一直正常工作，它随时可能给你「惊喜」。

嗯，这一章的内容就到这里。记住，好的编码器策略不是选最牛的，而是选最稳的。