# 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），不要用它省空间。