3. 编码器选择：硬件编码 vs 软件编码、x264 vs x265 vs NVENC vs QuickSync

编码器选型，是推流延迟优化里最容易被低估的一环。很多人觉得「不就是选个编码器嘛，哪个快用哪个」，结果上线后延迟高得离谱，或者画质糊成一团。

我个人的习惯是：先定场景，再定编码器。直播和点播对编码器的要求完全不同，低延迟场景和高质量存档场景更是天差地别。

3.1 硬件编码 vs 软件编码：核心差异

说白了，硬件编码和软件编码的区别就是「专用芯片干活」和「通用CPU算」。硬件编码器（如NVENC、QuickSync）是显卡或CPU内部集成的专用电路，功耗低、速度快；软件编码器（如x264、x265）则完全依赖CPU的通用计算能力，灵活度高、压缩率好。

对比维度	硬件编码	软件编码
延迟	极低（1-5ms）	较高（10-50ms+）
画质/码率效率	中等（同码率下画质略差）	优秀（同码率下画质更好）
CPU占用	极低（<5%）	高（可占满多核）
灵活性	低（参数选项少）	高（几乎可调一切）
适用场景	低延迟直播、游戏推流	点播转码、高质量录制

3.2 四大编码器横向对比

目前主流的编码器就这四个：x264、x265、NVENC、QuickSync。我一个个说。

x264：软件编码的老大哥

x264是H.264的软件实现，也是目前兼容性最好的编码器。几乎所有的播放设备和CDN都支持H.264，所以它一直是直播推流的默认选择。

我在项目中遇到过一个问题：用x264的ultrafast预设推流，延迟确实低了，但画面马赛克严重。后来我改用veryfast预设，配合crf=23，画质和延迟才平衡下来。

x265：高压缩率的代价

x265是H.265/HEVC的软件实现，压缩率比x264高30%-50%。但代价是计算量翻倍，编码延迟也更高。

嗯，这里要注意：H.265的播放兼容性不如H.264。很多老旧设备、浏览器不支持硬解H.265，会导致播放端延迟飙升。所以除非你的目标用户都是新设备，否则别轻易上x265。

NVENC：NVIDIA显卡的硬件编码

NVENC是NVIDIA显卡自带的硬件编码器，从GTX 900系列开始就有了。它的最大优势是几乎不占CPU，而且延迟极低（2-3ms）。

你想想看，如果你在游戏推流，CPU要跑游戏，GPU要渲染画面，再用CPU做编码，那CPU肯定扛不住。NVENC直接把编码任务丢给显卡上的专用电路，CPU就解放了。

NVENC支持H.264和H.265两种编码格式。我建议用H.264，兼容性更好。H.265的NVENC虽然压缩率更高，但播放端兼容性问题依然存在。

QuickSync：Intel核显的隐藏技能

QuickSync是Intel CPU内置核显的硬件编码器。很多人不知道，其实大部分Intel CPU（哪怕是低端的）都集成了QuickSync。

它的延迟和NVENC差不多，也是2-5ms级别。但画质略逊于NVENC，尤其是在低码率场景下。不过对于不需要极致画质的场景（比如监控推流、会议直播），QuickSync完全够用。

编码器	类型	延迟	画质（同码率）	CPU占用	兼容性
x264	软件	10-50ms	优秀	高	极好
x265	软件	20-100ms	极优秀	极高	一般
NVENC	硬件	2-5ms	良好	极低	好
QuickSync	硬件	2-5ms	中等	极低	好

3.3 编码器选型决策流程

说了这么多，到底怎么选？我画了一张决策图，你一看就明白。

3.4 实战配置示例

最后，我给出几个常用的FFmpeg命令行配置，你直接拿去用。

低延迟直播（NVENC + H.264）

ffmpeg -i input.mp4 -c:v h264_nvenc -preset p1 -tune ll -b:v 2M -bufsize 4M -g 30 -keyint_min 30 output.flv

-preset p1是NVENC的最低延迟预设，-tune ll是低延迟调优，-g 30设置关键帧间隔为30帧（1秒）。

高质量录制（x264）

ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 18 -profile:v high -level 4.1 output.mp4

-crf 18是视觉无损级别，文件会比较大。如果空间有限，可以调到23。

平衡方案（QuickSync + H.264）

ffmpeg -i input.mp4 -c:v h264_qsv -preset veryfast -b:v 2M -g 30 output.flv

QuickSync的veryfast预设延迟和画质都比较均衡，适合大多数场景。