编码器选型与优化：硬件编码 vs 软件编码
编码器选型，说白了就是你在「画质」和「速度」之间做取舍。我见过太多团队一上来就上 x264 的 placebo 预设，结果推流端 CPU 直接打满，观众端卡成幻灯片。也见过为了省成本全用硬件编码，结果画面马赛克满天飞。
这一章，咱们就把编码器的底裤扒干净。我会结合自己踩过的坑，聊聊怎么选、怎么调。
硬件编码 vs 软件编码：核心差异
先看一张对比表，心里有个底：
| 维度 | 软件编码（x264/x265） | 硬件编码（NVENC/QuickSync） |
|---|---|---|
| 画质（同码率） | 高（参考帧多、运动估计精细） | 中低（算法简化、参考帧少） |
| 延迟 | 高（编码耗时较长） | 低（专用芯片流水线处理） |
| CPU 占用 | 极高（多核满载） | 极低（几乎不占 CPU） |
| 并发路数 | 受限于 CPU 核心数 | 单卡可支持 8-16 路 1080p |
| 适用场景 | 点播转码、高画质直播 | 高并发推流、低延迟直播 |
我的建议：如果单路推流，且 CPU 资源充裕，优先选软件编码。如果并发超过 4 路，或者对延迟敏感（比如互动直播），硬件编码是唯一选择。
x264/x265 参数调优：别再用 placebo 了
很多人用 x264 时，习惯直接上 -preset placebo，觉得这样画质最好。其实这是个误区。placebo 预设增加的编码时间与画质提升完全不成正比。
我个人习惯用 medium 或 slow 作为起点，然后针对性地调几个关键参数：
- 关键帧间隔（keyint）：直播场景建议设为 2 秒，即
-keyint 60（假设 30fps）。太长会导致 seek 困难，太短会浪费码率。 - 参考帧数量（ref）：默认 3 就够。增加到 5 以上对画质提升微乎其微，但编码时间会翻倍。
- 运动估计范围（me）：
hex是性价比最高的选择。umh和esa适合离线转码，直播场景别碰。 - 码率控制（bitrate）：直播用
ABR或CRF。CRF 值建议 23-28，数值越低画质越好。
实战参数模板（1080p 直播）：
ffmpeg -i input -c:v libx264 -preset medium -crf 23 -keyint 60 -g 60 -sc_threshold 0 -bf 2 -refs 3 -me hex -subme 7 -trellis 1 -threads auto -f flv output我曾经在一个游戏直播项目中，把 preset 从 veryfast 换成 medium，CRF 从 28 降到 23，码率只增加了 15%，但观众反馈画质明显提升。嗯，这就是调参的价值。
NVENC/QuickSync 实战：硬件编码的正确打开方式
硬件编码不是「开箱即用」那么简单。我见过有人直接用 NVENC 的默认参数，结果画面全是块状噪声。其实硬件编码也有不少可调参数。
NVENC（NVIDIA）
- 预设（preset）：
p1（最快）到p7（最慢）。直播推荐p4或p5，画质和速度平衡最好。 - 码率控制（rc）：
vbr或cbr。直播场景用cbr更稳定。 - B 帧数量（b-frames）：建议设为 2。太多会增加延迟。
- Lookahead：开启后能提升画质，但会增加 1-2 帧延迟。如果对延迟敏感，建议关闭。
NVENC 实战参数（1080p 直播）：
ffmpeg -i input -c:v h264_nvenc -preset p5 -rc cbr -b:v 4M -maxrate 4M -bufsize 8M -g 60 -bf 2 -b_ref_mode 0 -temporal-aq 1 -rc-lookahead 20 -f flv outputQuickSync（Intel）
- 编码器类型：
h264_qsv或hevc_qsv。推荐用h264_qsv，兼容性更好。 - 全局质量（global_quality）：类似 CRF，值范围 1-51。直播推荐 23-28。
- 异步深度（async_depth）：默认 4，可以适当增加到 6-8，提升编码吞吐。
QuickSync 实战参数（1080p 直播）：
ffmpeg -i input -c:v h264_qsv -preset medium -global_quality 23 -g 60 -bf 2 -async_depth 6 -f flv output编码预设对延迟和画质的影响
编码预设的本质，是在「编码速度」和「压缩效率」之间做 trade-off。你想想看，预设越慢，编码器花在运动估计、模式决策上的时间就越多，压缩效率自然更高——同等码率下画质更好。
但直播场景下，延迟是硬指标。我整理了一张预设与延迟的对照表：
| 预设 | 编码延迟（1080p） | 画质（同码率） | 推荐场景 |
|---|---|---|---|
| ultrafast | < 5ms | 差 | 极低延迟互动 |
| veryfast | 5-10ms | 较差 | 高并发推流 |
| medium | 15-30ms | 良好 | 通用直播 |
| slow | 30-60ms | 优秀 | 点播转码 |
| placebo | > 100ms | 极优秀 | 离线压制 |
避坑指南：我曾经在一个低延迟直播项目中，为了追求画质用了 slow 预设，结果编码延迟直接飙到 50ms，加上网络抖动，端到端延迟超过 2 秒。后来换成 medium，延迟降到 20ms，画质差异观众根本看不出来。所以，直播场景下，medium 或 fast 是最稳妥的选择。
编码器选型决策流程图
下面这张图，是我在实际项目中总结的选型逻辑。你可以把它当作一个快速决策工具：
这张图的逻辑很简单：先看并发，再看延迟。并发高或延迟敏感，走硬件编码；否则走软件编码。硬件编码里，如果延迟要求极高（比如 < 50ms），记得选低延迟预设。
总结
编码器选型没有银弹。我的经验是：
- 单路高画质：x264 medium + CRF 23，别碰 placebo。
- 多路高并发：NVENC p5 或 QuickSync medium，配合 CBR 码率控制。
- 极低延迟：硬件编码 + 低延迟预设，必要时牺牲画质。
嗯，这一章的内容就到这里。记住，调参不是玄学，是工程。多测、多对比、多记录，你也能找到最适合自己场景的编码方案。