H.265(HEVC) 省空间可行性与本机编码能力实测

• 日期：2026-09-19
• 起因：用户问「用 H265 编码的 MP4 能不能实现原生播放和减少存储空间？」
• 约束：用户要求不要占用 GPU 机（它正在跑视频生成），只用 DSH 本机的 CPU、核显、板载 N 卡

---

一、结论速览

问题	答案
能省空间吗	能 —— 用 CPU 的 libx265，同质量下体积约减半（实测 6.11MB → 2.88MB，SSIM 几乎不变）。全库视频 62.3GB 理论可省约 31GB，但需约 38 小时 CPU 编码
能原生播放吗	不一定 —— 取决于客户端：macOS/Safari ✅；Windows+Chrome/Edge 需系统能硬件解码 HEVC；Linux 的 Chrome 通常不行；Firefox 134+ 有条件
板载 N 卡能帮上忙吗	能加速，但不能省空间 —— 修好缺失的 libnvidia-encode 后 NVENC 可用（5.2 倍实时，比 CPU 快 9 倍），但 Maxwell 编码器效率差：同质量下体积比 x264 大一倍
核显能帮上忙吗	不能（对 HEVC 而言）—— HD 4600(Haswell) 完全不支持 HEVC 编码；只能 H.264，且本机还缺 i965 VAAPI 驱动
AV1 呢	本机 CPU 编码 0.32 倍实时（比 x265 还慢），板载 Maxwell 不支持 AV1 硬件编码 → 不通

核心权衡：省空间靠「慢速高质量编码器」（CPU x265）；快编码器（NVENC）省不了空间。这台机器上二者不可兼得。

二、同源实测（30 秒 1080p 真实素材，SSIM 对照 crf16 母版）

编码器	体积	耗时	速度	SSIM
H.264 libx264 crf23（平台当前档）	6.11 MB	17.9s	1.68x	0.99426
H.265 libx265 crf26（CPU）	2.88 MB	53.7s	0.56x	0.99247
H.265 libx265 crf28（CPU）	2.28 MB	61.8s	0.49x	—
H.265 NVENC cq26（板载 N 卡）	11.91 MB	5.8s	5.16x	0.99448
H.265 NVENC cq30	7.25 MB	5.5s	5.42x	0.99287
H.265 NVENC cq32	5.59 MB	5.6s	5.34x	0.99172
H.265 NVENC cq34	4.40 MB	6.5s	4.64x	0.99050
AV1 SVT-AV1 crf35 preset8（CPU）	3.10 MB	94.5s	0.32x	—

读法：

• x265 crf26 用 一半的体积换到几乎相同的画质（SSIM 0.9925 vs 0.9943）→ 这就是 HEVC 省空间的来源。
• NVENC 要同体积（cq32 = 5.59MB）时 SSIM 掉到 0.9917，同质量（cq26）时体积反而接近 x264 的两倍 → Maxwell NVENC 只适合换格式，不适合省空间。

三、本机三块算力的实际情况

算力	型号	HEVC 编码	备注
CPU	i7-4720HQ（8 线程，实测用 4）	✅ libx265，0.56x 实时	省空间但慢
核显	Intel HD 4600（Haswell）	❌ 无 HEVC 编码能力	仅 H.264，且本机缺 i965_drv_video.so（现有 iHD 不支持该代）
板载 N 卡	NVIDIA GM204M（GTX 960M/970M）	✅ NVENC HEVC，5.2x 实时	需 4:2:0（Maxwell 限制）；编码效率低

为启用 NVENC 做的一处系统改动

本机驱动（580.119.02）只装了 libnvcuvid（解码）而缺 libnvidia-encode（编码），导致 ffmpeg 报 Error while opening encoder / Operation not permitted。已安装版本完全匹配的运行库：

apt-get install -y libnvidia-encode1   # 580.119.02-0deepin2，仅新增编码运行库，不动内核模块

装后 h264_nvenc / hevc_nvenc 均可用（hevc_nvenc 必须带 -pix_fmt yuv420p，Maxwell 不支持 4:4:4）。

其余算力（核显）未安装 i965 驱动：对 HEVC 没有意义（Haswell 无 HEVC 编码），故未动。

四、时间/空间总账（本机现状）

• 视频库：825 个文件 / 62.3GB，实测内容总时长 46.8 小时
• 磁盘 /home：805G，已用 597G，可用 168G（79% 已用）

方案	需要的编码时间	可省空间
CPU libx265 crf26（省空间路线）	约 38 小时（0.56x 实时）	约 31 GB
板载 NVENC HEVC（快路线）	约 4 小时	0 ~ 8%（同质量下甚至变多）
CPU SVT-AV1	约 67 小时	约 30GB（但播放兼容性另说）

五、建议

1. 要省空间 → 用 CPU x265，但别全库一把梭：挑最大的几个文件（如 9.12GB 的 abp-758-1.mp4 → 约 4GB）夜里分批转，-c:a copy 还能再省一点音频部分。
2. 要速度/要能播 → 用板载 NVENC HEVC 或 H.264：5 倍实时，适合把不能播的格式快速转成兼容格式，但不要期待省空间。
3. 最省事的默认做法：不动原始文件，平台按需转码（已有 7 天缓存、6GB 上限）。等真的空间紧张时再针对大文件处理。
4. 播放兼容性先用样例确认：已放入 dl-hub/05-下载服务维护/编码兼容测试/： 1-H264-应能播放.mp4 / 2-H265-HEVC-看能否播放.mp4 / 3-AV1-看能否播放.mp4（各 10 秒）， 在你平时看片的电脑上点开即可判断 —— 这一步决定了 HEVC 对你是否可用。

六、可选后续（等用户决定）

• 给平台加「HEVC 转码」选项：转码队列里可选 CPU x265（省空间，慢）或 NVENC（快）；
• 写一个批量瘦身脚本：扫描视频库按体积排序 → 逐个转 HEVC → 校验通过后替换原文件并保留备份/可回滚，支持夜间限时运行与断点续传；
• 安装 i965-va-driver 以启用核显 H.264 编码（可给"快速转 H.264"分流，减轻 CPU 负担）。

---

追加：为什么 N 卡「压不小体积」？（用户浏览器已确认 HEVC/AV1 均可播）

用户反馈：编码兼容测试/ 里 3 个样例都能正常播放 → HEVC 与 AV1 在该客户端均可用。

1. 先澄清术语

转成 HEVC 永远是「有损」压缩（CPU 的 crf26 也是）。用户真正关心的是压缩效率： 同等画质下体积能小多少。这才是 CPU 与硬件编码器的真正差距所在。

2. 实测证据：同体积比画质（30s 1080p 真实素材）

编码器	体积	SSIM（越高越保真）
CPU libx265 @2Mbps	6.95 MB	0.99470
板载 hevc_nvenc cq30	7.25 MB	0.99287
板载 hevc_nvenc cq32	5.59 MB	0.99172
板载 hevc_nvenc @2Mbps	5.48 MB	0.99138
CPU libx265 crf26	2.88 MB	0.99247

同体积（约 7MB）对比：x265 SSIM 0.99470 vs NVENC 0.99287 → 以 (1−SSIM) 计，NVENC 失真高约 25%。 反过来说：达到同样画质，这块 N 卡需要约 2 倍码率。

3. 最有说服力的证据：同一块卡上 HEVC 硬编还不如它自家 H.264 硬编

编码器（同一块 GM204，同 cq26）	体积	SSIM
h264_nvenc	10.39 MB	0.99587
hevc_nvenc	11.91 MB	0.99448

HEVC 硬编体积更大、画质更差 —— 说明问题不在 HEVC 本身，而在这块 2014 年显卡的 HEVC 编码器太初级。

4. 根本原因（四条）

1. 设计目标不同：NVENC 是为实时（直播/录屏/串流）造的固定功能电路，追求低延迟、低功耗、高吞吐；它的运动估计搜索范围、CU 划分深度、模式决策都被大幅裁剪。
2. 算法深度差距：CPU x265 每帧会做多层运动估计、多参考帧、完整 RDO（率失真优化）、lookahead、AQ 自适应量化、心理视觉优化、精细的 SAO/去块滤波决策 —— 这些计算量固定电路承担不了。
3. 代际差异是关键：NVENC 画质逐代提升，Turing（RTX 20 系，2018）是分水岭，其 HEVC 才接近 x264 medium 水平。本机是 GM204（2014 Maxwell 2 代），HEVC 编码器属第一代实现，粗糙到"不如自家 H.264”。
4. 码率控制模型不同：NVENC 的 -cq 是按 QP 近似，缺少 x264/x265 CRF 那种内容自适应分配。实测同样指定 2Mbps，NVENC 只用 5.48MB、CPU 用满 6.95MB，说明其率控没贴合目标。

一句话：省空间靠算法深度（CPU 用海量搜索换体积），硬件编码器用固定电路换速度 —— 2014 年的固定电路尤其吃亏。这是物理限制，不是配置问题。

5. 瘦身清单（>500MB 的文件，x265 crf26 预估）

文件	现在	转后约	分辨率	时长	编码耗时
abp-758-1.mp4	9.12GB	4.56GB	1080p	3.3h	~6.0h
abp-758-2.mp4	6.72GB	3.36GB	1080p	2.5h	~4.4h
thbt5.com…4K原版.mp4	2.84GB	1.42GB	2160×3840	0.2h	~0.3h
01-[韩国]美容室…mp4	2.08GB	1.04GB	720p	1.4h	~2.4h
深圳二次元漫展…720P.mp4	2.01GB	1.01GB	720×1280	2.3h	~4.2h
MVSD-467-UNCENSORED-LEAK.mp4	1.84GB	0.92GB	1080p	2.5h	~4.5h
DASS-670-UNCENSORED-LEAK.mp4	1.83GB	0.91GB	1080p	2.5h	~4.4h
2048.vip…4K.mp4	1.78GB	0.89GB	2160×3840	0.2h	~0.3h
>500MB 全部	54.9GB	约 27.4GB	—	—	约 3 天 CPU 时间

磁盘现状：/home 已用 597G、可用 168G —— 不是急需腾空间，可按需挑大文件做。

6. 建议的执行策略（待用户确认）

• 挑最大的 5~8 个（约占 27GB），用 CPU x265（crf 26 + -c:a copy）夜间分批转（例如 01:00–07:00、nice 降优先级、-threads 4 避免占满机器）；
• 转完校验（时长一致 + SSIM 达标）后替换原文件，原文件保留 7 天可回滚；
• 脚本可支持：按体积排序、限时运行、断点续传、失败回滚、生成报告。
• 注意：本机是笔记本平台（i7-4720HQ），长时间满负荷编码会发热/降频，因此限时限线程比"一把梭"更稳妥。
• N 卡的正确用途：快速把不能播/不想等的格式转成可播（5 倍实时、几乎不吃 CPU），不要用它省空间。