Measured performance of ffmpeg’s x264 quality presets, to know which option is the best for my purpose converting mpeg2 ts to Apple TV mp4. Factors need to be considered are 1) conversion speed, 2) file size and 3) quality of the video. The most important factor is conversion speed, which would be nice if the time for conversion is shorter than for recording. For file size off course, the smaller the better as the space of my Apple TV storage is limited.
Test Method
The test was done with ffmpeg version 0.6.1 on 2.8GHz Intel Core i7 running Mac OS X 10.6.8 as;
for i in ultrafast superfast veryfast faster fast medium slow slower veryslow placebo
do ffmpeg -i sample.ts -threads 4 -vcodec libx264 \
-vpre $i -vpre main -crf 18 -s 1280x720 \
-acodec libfaac -ab 160k \
-y $i.mp4
done
sample.ts is a 60 seconds of full HD (1440×1080) mpeg2 video.
Test Results
| Preset used for conversion | Conversion speed (fps - frames per second) | Size of the output video file (in bytes) |
|---|---|---|
| ultrafast | 29.6 | 81,046,858 |
| superfast | 27.9 | 58,180,478 |
| veryfast | 20.6 | 43,968,615 |
| faster | 13.0 | 32,981,783 |
| fast | 9.1 | 35,461,071 |
| medium | 8.0 | 35,119,322 |
| slow | 5.6 | 33,367,247 |
| slower | 2.1 | 33,698,347 |
| veryslow | 1.3 | 29,697,663 |
| placebo | 0.6 | 29,395,288 |
On my environment, ultrafast can convert ts video almost at the recording speed (29.97 fps). But my decision was to go with superfast as its fps is closer to ultrafast yet the size is much smaller.
4 replies on “Comparison of ffmpeg’s x264 presets”
[…] reason why you must compile FFmpeg proper and not apt-get install it! From my own tests and from other tests, the “veryfast” preset provides roughly the same filesize at a fraction of the […]
Granted this post is pretty old, but I’ll post anyway. Curious, I just ran a similar test, and finding that on my Intel E5 Xeon, the sweet spot is Veryfast.
1080p 30fps, 10 Minute Video, 5000 Frame clips, 2 threads per clip
h264 ultrafast superfast veryfast faster fast medium slow
Time 74 126 201 379 456 536 909
Rate 243 142 89 47 39 33 19
Size 634 410 288 327 337 318 313
% Time 12.33 21.00 33.50 63.17 76.00 89.33 151.50
% Size 100.00 64.67 45.43 51.58 53.15 50.16 49.37
Seems to me the ffmpeg default of medium is not really the best spot to set a default. A bit relieved to see your chart kinda looking the same as mine.
The results are the same for libx265, faster having smaller size with much fast speed. But, this is not for “free”. Looking frame-by-frame you can see an reduction of quality, not too much but visible and fair enough for the reduction of file size and speed.
If you just want to throw something that will be deleted a few hours later, then its very ok to use faster, but for archival porpose, anything above slow is terrible idea.
I’ll say the same here as somewhere else, as I see so many too large video files allover the net.
@vaguiners, not quite so, what you say.
Converting video+audio at veryfast to superfast already takes quite long but still gives very reasonable results, with veryfast the better quality, superfast a slightly faster transfer speed.
In x264 (x265) three things matter concerning smaller video file sizes with one pass encoding:
1) crf (constant rate factor), I would keep it between 20 and 23. 22 is a fine.
2) resolution aka image size: try a mini HD of 640×360 instead of 1280×720. You’ll notice a positive influence on file size without too much loss of quality. The video will still show satisfactory on a pc screen as on a tv screen.
3) gop (-g in ffmpeg) aka keyframe interval: if you don’t want to cut your film at very precise key frames, the default gop of 250 also makes a significant difference in file size.
Just to say I just came to convert a somewhat older 1:40h xvid-mp3-avi film of 1.3 Gb to a x264-aac-mkv between 300 and 400 Mb with the above settings (veryfast, -crf 22, -s 640×360, -g 250 44.1khz aac) with hardly quality loss.
Cheerio.