视频编解码器主要负责高内存使用。
因此,需要解决内存使用问题的是编码器,而不是直接使用 FFmpeg。我不确定如何修复x264
的内存使用,但我尝试了较新的 x26 5,在我的情况下它只使用 1.6 GB,而 libx264 因询问超过 2 GB 内存限制而失败(每个进程,在 32-位系统)。
所以,对我有用的是使用:
ffmpeg -i input -pix_fmt yuv420p -c:v hevc -x265-params crf=23 out.mp4
(省略参数以处理音频。)
但一般的做法是尝试其他编码器。如果 x265 不起作用,我打算尝试 mpeg4 和 vp9,也许还有其他的。如果这些都不起作用,那么进一步的选项包括查看编码器的设置(尽管没有出现明显且与内存使用直接相关的内容):
ffmpeg -h encoder=mpeg4
更新:实际上,事实证明 YouTube 还不接受 HEVC(又名 H.265)(它只在上传完成后才让我知道)。所以,就像我上面建议的那样,我选择了 VP9,这次用前 50 帧进行了试运行。我使用了类似于我找到的指南的设置(恒定质量设置,尽管我应该使用更多他们建议的参数):
ffmpeg.exe -i <input> -pix_fmt yuv420p -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 20 -f webm pass1.webm
ffmpeg.exe -i <input> -pix_fmt yuv420p -c:v libvpx-vp9 -pass 2 -b:v 0 -crf 20 -f webm pass2.webm
(请注意,这pass1.webm
几乎是空的。)
另请注意,尽可能首选两次通过。它在所有方面都更好,包括整体更快的编码。
使用这些设置,一个 4K 分辨率的 73 秒剪辑需要大约 16 个小时来编码——这是使用一个核心,因为我忘了指定-threads
. 虽然速度很慢,但 FFmpeg 的内存使用量仅上升到大约 0.6 GB。生成的文件为 300 MB,与未压缩的帧相比,我看不到任何质量损失(因此-crf 20
可能有点太低了)。