视频编解码器主要负责高内存使用。
因此,需要解决的是编码器的内存使用问题,而不是直接解决FFmpeg问题。我不确定如何修复 的内存使用,但我尝试了较新的x265,在我的情况下,它只使用1.6 GB,而libx264由于要求超过2 GB内存限制而失败(每个进程,在32位系统上)。x264
因此,对我有用的是使用:
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个小时才能编码 - 这是我忘记指定的那样,这是使用一个内核。虽然速度很慢,但FFmpeg的内存使用量仅上升到约0.6 GB。生成的文件为300 MB,与未压缩的帧相比,我看不到任何质量损失(因此可能有点太低)。-threads
-crf 20