Days of Bike and Photos

鵜の木⇔六郷土手 »« 多摩川、丸子橋⇔二子玉川

Comparison of ffmpeg’s x264 presets

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 conversionConversion speed (fps - frames per second) Size of the output video file (in bytes)
ultrafast29.681,046,858
superfast27.958,180,478
veryfast20.643,968,615
faster13.032,981,783
fast9.135,461,071
medium8.035,119,322
slow5.633,367,247
slower2.133,698,347
veryslow1.329,697,663
placebo0.629,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.


June 25, 2011 at 11:03 pm
4 comments »
  • July 27, 2016 at 2:15 pmEric

    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.

  • April 22, 2019 at 5:36 amvaguiners

    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.

  • July 30, 2023 at 9:48 pmDonut

    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.


Trackbacks/Pingbacks
Leave a Reply to vaguiners or trackback

meiwaku-no-wana@pub.motokado.com