FFMpeg benchmark - transcoding into H.264 with different presets

Couple of years ago I developed simple software for recording from security cameras for one hotel. For various reasons I had to pull the video from the cameras in MJPEG format (Motion JPEG). MJPEG quality/bitrate ratio is quite awful, so for long-term storage, I transcode it to H.264. However, there is a lot of parameters which can affect encoding time, size of the output video and quality. So now I finally have tool to check which one would work best for me and I hope the results will be useful also for some of you.

I benchmarked FFMpeg command-line software in version N-81475-gdc7e5ad from 27 August 2016. I used two different input videos and encoded each in H.264 using constant quality setting and different presets.

Preset is prepared collection of specific settings which specify details of encoding. Using different presets, one can change the encoding time/file size/quality ratio (more about presets: https://trac.ffmpeg.org/wiki/Encode/H.264).

I used constant quality setting, so we can see the difference in run time / file size while maintaining +- same quality. As per recommendation of the manual (using "sane" values), I measured transcoding to bad quality (crf=18), default quality (crf=23) and good quality (crf=28).

Each test was run from command line as:
ffmpeg.exe -i {input_file} -c:v libx264 -profile:v high -level 4.0 -preset {preset} -crf {quality} result.mp4

System parameters

The benchmark was executed on following system:

Laptop Acer TimelineX 5820TG
CPU:	Intel Core i5 M460 2C/4T @ 2.53 GHz
RAM:	4GB DDR3 1067 MHz
SSD:	Kingston SSDNow V300 128GB
OS:	Windows 10 (10.0.14393.105)

Results

H.264 video (Simpsons movie trailer, FullHD, 120 MB, 2 min 17 seconds)
MJPEG video (Camera recording, 640x480, 92.6 MB)

Conclusion

If somebody tells you slower preset will give you smaller file size, DON'T BELIEVE THEM (until they prove it to you). Unfortunately, it is not true, in all tests fast preset produced bigger size than veryfast preset, while taking much longer time on CPU. I re-measured this with couple of other videos, on three different computers and also on Linux, results were the same. I tried filling the bug first on FFMpeg, then on x264, but so far I got only responses which states that it is not a bug.

In current situation, all I can recommend is to use only ultrafast, superfast or veryfast preset, depending on how much time you have and how much you value your storage space.
Increase in constant quality setting adds some time to transcoding and the result file is much bigger, so bear that in mind when deciding what quality to use.

You can download all results from https://drive.google.com/open?id=0B43-CuEfEyUVZXlMRzNQVDRmNkE.