音视频修炼之编码器（三）：软硬编码对比-开发者社区

软编 vs 硬编完整对比

编码用 CPU 还是 GPU/专用芯片? 选错差 10x. 这一篇讲清楚.

本文速览

章节	阅读重点
0. 三大编码方式	把握本节核心概念和使用场景
1. 速度对比	按场景做技术取舍
2. 画质对比	按场景做技术取舍
3. 码率压缩率	把握本节核心概念和使用场景
4. 功耗	把握本节核心概念和使用场景
5. 内存	把握本节核心概念和使用场景
6. 灵活性	把握本节核心概念和使用场景
7. 实战 ffmpeg 对比	对照代码和运行效果落地
8. 架构内部	先看整体结构和模块关系
9. 选型决策树	按场景做技术取舍
10. Netflix 的混合策略	看大平台如何按内容价值、成本和时延分层选型
11. 兼容性 / 可移植	对比软编和硬编在平台、部署、兜底上的差异
12. 失败案例	用反例总结硬编落地最容易踩的坑
13. 总结表	快速按业务场景选择软编 / 硬编 / 混合方案

0. 三大编码方式

编码器选型先分清 3 类：软编看画质和灵活性，硬编看速度和功耗，混合方案用于在质量和成本之间折中。

编码方式	主要执行单元	典型实现	核心优势	典型短板	适合场景
软编（CPU）	通用 CPU	`x264`/`x265`、Intel Media SDK 的 software 模式	画质上限高、参数可控、跨平台一致性好	慢、耗 CPU、功耗高	离线转码、归档、画质优先、复杂码控
硬编（GPU / 专用芯片）	GPU / VPU / ISP / 专用编码单元	NVIDIANVENC、IntelQuickSync、AMDAMF、AppleVideoToolbox、AndroidMediaCodec	快、低功耗、适合实时和大并发	画质 / 参数受硬件代际限制，平台差异明显	直播、录屏、移动端、云端批量转码
混合（软硬协同）	CPU + 硬件编码器	lookahead / 场景分析跑 CPU，主编码跑硬件	兼顾速度、成本和一部分画质优化	架构复杂，需要调度和质量兜底	大平台多档 ladder、海量内容转码、实时但又要质量

一句话选择：能离线慢慢算就优先软编；要实时、省电、大并发就优先硬编；既要规模又要画质，就做混合策略。

1. 速度对比

1080p 30fps 60s 视频编码到 H.264:

项	内容
软编 x264 medium	~80s (1.0x 实时)
软编 x264 ultrafast	~12s (5.0x 实时)
硬编 NVENC P4	~3s (20x 实时) ⚡
硬编 QSV (i7)	~5s (12x 实时)
硬编 MediaCodec (手机)	~30s (2x 实时)

4K 60fps 时硬编差距更大: 软编 1080p 实时勉强, 硬编 4K 60 还能 5x.

2. 画质对比

同 4 Mbps 1080p, VMAF 评分:

项	内容
软编 x264 medium	92.5 ⭐
软编 x264 slow	93.0
硬编 NVENC (Turing+)	91.0 (差 1-2 分, 可接受)
硬编 NVENC (Pascal)	88.0 (差 4-5 分)
硬编 MediaCodec (高通)	87.0 (差 5-6 分)
硬编 MediaCodec (联发科)	85.0 (更差)
硬编 MediaCodec (低端)	82.0 (差很多)

结论: 现代 NVIDIA 硬编很接近软编, 移动硬编差距明显.

3. 码率压缩率

同 VMAF 92, 需要的码率:

项	内容
软编 x264 slow	3.5 Mbps
软编 x264 medium	4.0 Mbps
硬编 NVENC新	4.5 Mbps (+12%)
硬编 NVENC老	5.5 Mbps (+37%)
硬编 MediaCodec	6.0 Mbps (+50%)

4. 功耗

1080p 60fps 编码:

项	内容
软编 x264	40-60W (CPU 满载, 笔记本风扇起飞)
硬编 NVENC	5-10W (专用芯片, 显卡余热)
硬编 MediaCodec	1-3W (手机芯片)

移动端必须硬编, 否则手机半小时关机.

5. 内存

项	内容
软编 x264 1080p	~150 MB (lookahead + 多参考)
硬编 NVENC	~50 MB
硬编 MediaCodec	~30 MB

6. 灵活性

维度	软编 (x264)	硬编 (NVENC)	硬编 (MediaCodec)
profile/level	✓ 全支持	✓ 主流	⚠️ 受限
HDR 编码	✓	✓ Turing+	⚠️ 高端芯片
自定义参数	✓ 100+ 参数	⚠️ 30 个	⚠️ 10 个
多分辨率切换	✓	✓	⚠️ 重启
B 帧	✓ 0-16	✓ 0-3	⚠️ 部分支持
lookahead	✓ 0-250	✓ 0-32	✗

7. 实战 ffmpeg 对比

7.1 x264 软编

ffmpeg-iinput.mp4\-c:vlibx264\-presetmedium-crf23\-profile:vhigh-level4.1\-movflags+faststart\output.mp4

7.2 NVENC 硬编

# 模拟 x264 mediumffmpeg-iinput.mp4\-c:vh264_nvenc\-presetp5-tunehq\-rcvbr-cq23\-profile:vhigh-level4.1\-bf3-refs5\-rc-lookahead32\output.mp4

7.3 QSV (Intel)

ffmpeg-hwaccelqsv-c:vh264_qsv-iinput.mp4\-c:vh264_qsv-presetmedium-global_quality23\output.mp4

7.4 VAAPI (Linux)

ffmpeg-vaapi_device/dev/dri/renderD128\-iinput.mp4\-vf'format=nv12,hwupload'\-c:vh264_vaapi-qp23\output.mp4

7.5 MediaCodec (Android)

ffmpeg-iinput.mp4\-c:vh264_mediacodec\-b:v4M-maxrate4M-bufsize4M\output.mp4

8. 架构内部

软编和硬编的核心差异不是“一个用 CPU、一个用 GPU”这么简单，而是控制权在谁手里：软编把编码算法放在软件库里，硬编把大量决策固化在驱动和芯片里。

8.1 NVENC

NVENC 是 NVIDIA GPU 内置的专用编码单元，FFmpeg 只是通过 SDK 把参数交给它，真正的编码工作在硬件里完成。

维度	内容	说明
硬件位置	GPU 内置 NVENC 编码单元	与 CUDA Core 不是一回事，属于专用视频编码硬件
官方接口	NVIDIA Video Codec SDK	应用 / FFmpeg 通过 SDK 配置码率、preset、profile、B 帧等参数
FFmpeg 编码器名	`h264_nvenc`/`hevc_nvenc`/`av1_nvenc`	是否可用取决于显卡代际、驱动版本和 FFmpeg 编译配置
常见优势	高并发、低 CPU 占用、低延迟	适合直播、云转码、录屏
主要风险	老卡画质弱、并发路数有限、参数不完全等价于 x264	不能把 NVENC 结果无脑当 x264 同码率替代

GPU 代际	编码能力变化	选型提示
Pascal	H.264 / H.265 可用，但画质相对老	可用，但同画质通常要更高码率
Turing	B 帧、质量和码控明显增强	H.264 / H.265 硬编进入相对可用阶段
Ampere	继续增强视频处理能力，AV1 主要偏解码能力	适合大规模 H.264 / H.265 转码
Ada	支持 AV1 编码 ⭐	新项目如果要 AV1，可以重点看这一代及以后

8.2 Android MediaCodec

MediaCodec 是 Android 暴露给应用层的统一编解码 API，底层会落到不同 SoC 厂商的 VPU / 驱动实现，所以同一段代码在不同手机上的产物可能不完全一致。

层级	组件	作用	需要注意
应用 / FFmpeg	`h264_mediacodec`	把编码请求接入 Android MediaCodec	参数能力取决于系统暴露的 codec capabilities
Framework API	Java / NDK MediaCodec API	创建 encoder、配置`MediaFormat`、喂输入、取输出	要处理异步回调、format change、surface/input buffer 等模式
系统编解码层	Codec2 / OMX 等实现	把统一 API 转换成厂商组件调用	不同 Android 版本和厂商实现差异较大
厂商驱动 / 固件	高通、联发科、三星等 VPU 驱动	真正执行硬件编码	可能有机型 bug、profile/level 限制、低端芯片画质波动
硬件单元	SoC 内 VPU / 视频编码器	H.264 / H.265 等硬件编码	手机端省电、实时，但不可完全按 x264 预期调参

参考 Part 5 MediaCodec 系列。

9. 选型决策树

是否在移动端?

项	内容
Yes	硬编 (MediaCodec)
No	继续
Yes	软编 (x264 / x265 slow)
No	继续
Yes	硬编 (NVENC)
No	继续
Yes	看场景:
流媒体准实时	硬编 (NVIDIA T4 显卡)
画质优先	软编 (CPU 集群)
No	软编 medium 足够

10. Netflix 的混合策略

Netflix 这类平台不会简单站队“只软编”或“只硬编”，而是按内容价值、吞吐成本和时延要求分层处理。

内容 / 业务类型	推荐编码策略	为什么这么选	关键收益
新内容 / 主推内容	软编 + 多档 ladder + per-title encoding	这类内容观看量高、生命周期长，值得花更多 CPU 换更好画质和更低长期带宽	画质稳定、码率更省、用户体验最好
老内容 / 海量库存	硬编集群，例如 NVIDIA T4 / 新一代 NVENC	单个内容价值较低，但数量巨大，CPU 成本会被放大	降低转码成本，提高吞吐
直播 / 准实时业务	硬编优先，必要时配合低延迟 preset	直播最怕延迟和排队，不能像离线转码一样慢慢压	低延迟、可控并发、稳定出流
重点片源二次优化	先硬编快速出版本，再用软编做高质量版本	先满足上线时效，再补长期最优资产	兼顾上线速度和长期质量

关键点：大平台真正优化的是“单位观看成本”，不是单纯比较某一次编码谁更快、谁画质更高。

11. 兼容性 / 可移植

维度	软编（x264 / x265）	硬编（NVENC / MediaCodec / VideoToolbox 等）	结论
平台覆盖	Linux / Windows / macOS / Android 都容易跑	NVENC 依赖 NVIDIA，MediaCodec 依赖 Android，VideoToolbox 依赖 Apple	软编更容易做统一方案
代码一致性	同一套编码库和参数跨平台行为更接近	同名参数在不同硬件上效果可能不同	硬编要按平台维护适配层
产物稳定性	同版本库输出更可预测	芯片、驱动、系统版本都会影响输出	服务端硬编要锁驱动和卡型，移动端要做机型兼容
部署成本	主要消耗 CPU，扩容方式简单	需要特定 GPU / SoC / 驱动 / 授权环境	大规模部署前必须做容量和兼容性评估
故障兜底	通常可作为 fallback	硬件不可用、驱动异常、机型 bug 时需要降级	实战建议：硬编优先时，也保留软编兜底路径

12. 失败案例

案例	错误做法	直接后果	根因	正确处理
12.1 把 NVENC 产物直接当 x264 替换	同分辨率、同码率下，把老款 NVENC 输出直接替换 x264 输出	画质下降，用户投诉“糊、块状感明显”	老代 NVENC 的压缩效率低于 x264，同码率不等于同画质	单独做主观 / VMAF 评测；老卡适当提高码率，例如`+20%`；条件允许时换 Turing / Ada 等新卡
12.2 MediaCodec 在低端设备出花屏	假设所有 Android 机型的 H.265 硬编行为一致	某些 MTK / 低端机编码花屏、绿屏、解码失败	厂商 VPU 驱动或固件有 bug，profile / level / color format 支持不一致	建机型白名单 / 黑名单；异常机型 fallback 软编或 H.264；上线前做真机矩阵测试
12.3 服务端不限制 NVENC 并发	认为 GPU 在就能无限开编码任务，一张卡直接开 30 路	后续任务排队、超时或编码器创建失败	NVENC 单卡编码 session、吞吐和显存都有上限	做业务限流；按卡型设置并发阈值；多卡并行；监控 encoder utilization 和失败率

避坑原则：硬编一定要把“硬件代际、驱动版本、并发上限、机型差异”当成系统约束，而不是只看 FFmpeg 命令能不能跑通。

13. 总结表

场景	推荐	理由
抖音直播 (端)	硬编 MediaCodec	省电
抖音直播 (云)	硬编 NVENC	大并发
Netflix 转码	软编 x264/x265	画质
YouTube Reels	混合	大量 + 画质
Mac 录屏	硬编 VideoToolbox	系统集成
服务端归档	软编 slower	极致压缩
WebRTC	硬编 (端) / 软编 (SFU)	低延迟