使用FFmpeg libx265编码器时，Slow预设生成的文件为何比Ultrafast预设更大？

嗨，我完全懂你的困惑——毕竟FFmpeg文档明确说慢预设应该带来更好的压缩效率（同质量下更小文件），但你实际测出来的结果刚好相反。这里主要有几个关键原因，咱们一个个捋清楚：

1. 手动截断编码的误差是核心问题 #

你是通过盯着控制台、手动按Ctrl+C来停止编码获取前两分钟内容的，这种方式根本没法保证两个预设编码的是完全相同的视频片段。

FFmpeg编码视频是按GOP（图像组）批量处理的，当你手动中断时：

• Slow预设因为编码速度慢，可能还在处理前两分钟里的高复杂度片段（比如快速运动、光影变化大的画面），这些片段本身需要更多比特率来维持CRF 22的质量，而你中断时它还没来得及处理后面低复杂度、更省比特的部分；
• Ultrafast预设编码速度极快，可能已经跑完了高复杂度片段，进入了低复杂度部分才被你中断。

这种“编码片段不完全一致”的情况，会直接导致文件大小的偏差，完全不能作为预设对比的有效数据。正确的做法是用-t 120参数精确指定编码时长，命令改成这样：

"C:\Program Files\ffmpeg\bin\ffmpeg.exe" -i input.mkv -c:v libx265 -preset slow -crf 22 -c:a copy -t 120 output_slow.mkv

Ultrafast的命令也加上-t 120，这样两个预设编码的是完全相同的120秒内容，对比结果才可信。

2. CRF“恒定质量”的细微差异 #

虽然CRF是用来保证恒定视觉质量的，但不同预设对“质量”的实现逻辑有区别：

• Slow预设会用更复杂的算法分析画面，精准匹配CRF设定的质量标准——在复杂场景下，它会主动分配更多比特来保留细节（哪怕你主观没察觉），这会让文件变大；
• Ultrafast预设为了速度，会采用更粗糙的编码策略，在一些不影响主观观感的细节上过度压缩，从而用更少的比特达到“看起来差不多”的质量。

不过正常情况下，这种差异不会像你遇到的70MB vs 40MB这么夸张，还是手动截断的误差占主导。

3. 文档描述的前提是“完全相同的编码条件” #

你提到H.265和H.264预设的行为一致，这一点是对的——文档说的“慢预设节省比特率”，前提是编码完全相同的内容、达到完全相同的视觉质量。而你手动中断的操作，刚好打破了这个前提，才出现了和文档矛盾的结果。

验证建议 #

1. 用-t 120参数重新编码，对比两个输出的文件大小；
2. 用FFmpeg的PSNR或SSIM滤镜量化质量差异，比如：

   ffmpeg -i output_slow.mkv -i output_ultrafast.mkv -filter_complex "psnr" -f null -
   

   这能帮你确认Slow预设是否真的保留了更多细节，而不是单纯的文件大小差异。

备注：内容来源于stack exchange，提问作者Binarus