最近更新于 2024-02-19 10:16
前言
我本地存储视频基本都是使用 H.265，不过目前网络上传播的视频普遍是 H.264，将 H.264 的视频重新编码为 H.265 以后体积能大大缩小，质量基本不影响。比如下面我测试用的 4K 视频，两分多钟，文件大小 833M，重新编码为 H.265 之后都没超过 50M 的。所以这里顺便测试一下，看在我电脑上哪种方案速度最快。
编码解码器
\begin{array}{|l|l|l|}
\hline
编码\ -\ 硬件 & 解码器 & 编码器 \\
\hline
H.264\ -\ CPU & h264 & libx264 \\
\hline
H.265(HEVC)\ -\ CPU & hevc & libx265 \\
\hline
H.264\ -\ Intel\ GPU & h264\_qsv & h264\_qsv \\
\hline
H.265(HEVC)\ -\ Intel\ GPU & hevc\_qsv & hevc\_qsv \\
\hline
H.264\ -\ NVIDIA\ GPU & h264\_cuvid & h264\_nvenc \\
\hline
H.265(HEVC)\ -\ NVIDIA\ GPU & hevc\_cuvid & hevc\_nvenc \\
\hline
\end{array}ffmpeg -c:v 解码器 -i 输入视频 -c:v 编码器 输出视频测试环境
-
Intel i7-12700H（Iris Xe Graphics）
-
NVIDIA RTX4060 Laptop GPU
-
Windows 11 专业版 23H2
-
FFmpeg – Auto-Build (2024-01-26 12:46)：https://github.com/BtbN/FFmpeg-Builds/releases
测试
使用一个 3840×2160 分辨率 00:02:17 长度的 H.264 MP4 视频，转为 H.265 MP4 视频。
下表中 C 指 CPU，I 指 Intel 核显，N 指 NVIDIA 独显。
\begin{array}{|l|l|l|}
\hline
解码硬件 & 编码硬件 & 用时（秒） \\
\hline
C & C & \\
\hline
C & I & 113 \\
\hline
C & N & 60 \\
\hline
I & C & \\
\hline
I & I & 108 \\
\hline
I & N & 61 \\
\hline
N & C & 390 \\
\hline
N & I & 113 \\
\hline
N & N & 60 \\
\hline
\end{array}解码器不管用 CPU、核显，还是独显，大致都差不多，但是编码器用 CPU 就是最拉跨的，我用独显当解码器，CPU 编码花的时间都已经是最多的了，解码器用 CPU 或者核显结果应该只可能更差，就没试了。编码器用独显比核显也明显的快很多。
总结来说，解码用 CPU 都没成为瓶颈，编码才是明显的瓶颈。
另外方向可能也有一定影响，因为我这里需求是把 H.264 转 H.265，而不管是解码或编码 H.264 对算力的要求都比 H.265 低。
常用的编码还有 AV1、VP9，AV1 的压缩率比 H.265 还高，可以让视频更小，我用过的感觉就是比 H.265 还要更吃硬件，编码速度会慢一些，但是能节省的空间不是很明显，就没用。油管、奈飞这些就在用 AV1，B 站还在用 H.264，就算上传 H.265 的视频也会被压成 H.264，可能只有热门视频会重新编码为 H.265。VP9 则是支持不怎么好，可能在 Google 的产品上支持不错，其它就不好说了，我用 FFmpeg 编码，Intel 的核显支持 VP9，NVIDIA 的独显就不支持，目前的情况的话。对于本地视频而言，综合感觉用 H.265 是在体积较小的情况下，支持比较广泛的编码了。
2024.2.19
发现了一个问题，虽然编码速度上 独显>核显>CPU，但是编码生成的视频文件大小是反过来的，CPU 编码（软件编码）生成的视频文件最小，而独显编码出来的视频文件（从h264转h265）甚至可能比原文件还大。我看了一下生成视频文件的码率：独显>核显>CPU，是不是意味着在不指定码率，让 FFmpeg 自动选择的情况下，CPU 可以以最小的码率维持相同的画质，而独显编码效率最低，需要更大的码率来保证画质。
用 CPU 编码的话很轻松就会满载，从而导致风扇狂飙。综合考虑，我觉得用独显解码，用核显编码可以保证速度的情况下也能保证文件大小适当减小，同时不至于电脑明显升温导致风扇满速。
