How can I limit ffmpeg memory usage

Question

I am using ffmpeg to convert a 1080p video to MP4 using this command in PHP.

$command = FFMPEG.\' -i \' . $src . \' -sameq -strict -2 -vcodec libx264 -ar 22050 -         


        

Answer 1

It would be the video codec which is mainly responsible for the high memory use.

So it's the encoder whose memory use needs to be addressed, not FFmpeg directly. I'm not sure how to fix x264's memory use, but I tried the newer x265 and in my case it's only using 1.6 GB, while libx264 was failing by asking more than the 2 GB memory limit (per process, on 32-bit systems).

So, what worked for me was to use:

ffmpeg -i input -pix_fmt yuv420p -c:v hevc -x265-params crf=23 out.mp4

(Omitting parameters to take care of the audio.)

But the general approach is to try other encoders. I was going to try mpeg4 and vp9 if x265 didn't work, maybe others. If none of that works, then further options include looking at the encoders' settings (though nothing obvious and directly relevant to memory use shows up):

ffmpeg -h encoder=mpeg4

---

Update: actually, it turned out that YouTube doesn't accept HEVC (aka H.265) yet (and it only let me know after the upload finished). So, like I suggested above, I went for VP9, doing a pilot run with the first 50 frames this time. I used settings similar to a guide I found (the Constant quality settings, though I should have used more of their suggested parameters):

ffmpeg.exe -i  -pix_fmt yuv420p -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 20 -f webm pass1.webm

ffmpeg.exe -i  -pix_fmt yuv420p -c:v libvpx-vp9 -pass 2 -b:v 0 -crf 20 -f webm pass2.webm

(Note that pass1.webm will be almost empty.)

Also note that two passes are preferred whenever possible. It's better on all fronts, including faster encoding overall.

With these settings, a 73-second clip at 4K resolution took about 16 hours to encode — that's using one core, as I forgot to specify -threads. While slow, FFmpeg's memory use only went up to about 0.6 GB. The resulting file was 300 MB, and I can't see any loss of quality compared to uncompressed frames (so -crf 20 might have been a bit too low).