x264 is an open source h.264 encoder. Since r1177 it includes a preset system. The presets give an easy way to balance quality vs encoding speed, ranging from placebo (highest quality) to ultrafast (lowest quality).

I wanted to get an idea what kind of quality/time gains could be archived with these settings. Usually the first steps of extra quality are barely noticeable in encoding time, while the last bits of quality cost significantly more. To verify this statement and to quantify it, I encoded 2 video sequences at 2 resolutions using all 9 available presets. I used PSNR as metric. I’d be the first to admit that PSNR does not correspond to quality, but it correlates reasonably well.

The results in short: the “slower” profile seems to give very high quality (-0.1dB PSNR loss) while reducing encoding time by roughly a factor 4! “veryfast” gives a substantial quality-boost (2.1dB PSNR) while only requiring 15% more encode time compared to ultrafast.

This graph shows the relative speed gain/loss vs PSNR gain/loss. The “slower” profile is taken as a reference.

The presets

Since they seem to be removed from the wiki, here is a copy:

  • ultrafast: subme 0, ref 1, me dia, b-adapt 0, partitions none, trellis 0, bframes 0, weightp 0, no-mixed-refs, no-mbtree, no-scenecut, no-deblock, no-cabac, no-8x8dct, aq-mode 0
  • veryfast: subme 1, ref 1, me dia, partitions i8x8,i4x4, trellis 0, weightp 0, no-mixed-refs, no-mbtree
  • faster: subme 4, ref 2, weightp 1, no-mixed-refs, no-mbtree
  • fast: subme 6, ref 2, rc-lookahead 30
  • medium: No changes
  • slow: subme 8, ref 5, me umh, b-adapt 2, direct auto, rc-lookahead 50
  • slower: subme 9, ref 8, me umh, b-adapt 2, direct auto, rc-lookahead 60, partitions all, trellis 2
  • veryslow: subme 10, ref 16, me umh, b-adapt 2, direct auto, rc-lookahead 60, partitions all, trellis 2, bframes 8, merange 24
  • placebo: subme 10, ref 16, me tesa, b-adapt 2, direct auto, rc-lookahead 60, partitions all, trellis 2, bframes 16, no-fast-pskip, slow-firstpass


  1. jet says:

    The PSNR data you got is likely flawed. As you probably know, x264 uses psychovisual optimizations. Generally the more psy the less PSNR value. Internally x264 uses more psy with ‘slower’ options (especially –subme from my experience) which skews metrics (decreases PSNR). Thus, your test is skewed towards faster settings as they have weaker psy-enhancements (which visually corresponds to less detailed texture, blocking, smear, etc but also might look ‘cleaner’). To properly test it, you should add –tune psnr to your commandlines.

  2. Niobos says:

    Hi jet,

    You are correct about the psy influencing the PSNR negatively. This was by no means a thorough scientific test, just a quick assessment of how the presets relate to each other in terms of speed and “quality” (and I’ll put it inside quotes).
    However, according to this IEEE paper, the calculated PSNR is still valid. Your alternative (using –tune psnr) will be skewed in another way, since I won’t be taking the psy into account anymore in the speed-part of the test.

    I’m planning on redoing this test with both PSNR and SSIM and maybe an Opticom analyzer, which might give more representative results.

  3. jet says:

    Hi Niobos,
    First I want to say that graphs are so much nicer than tables of numbers so thanks for this… but back to complaining:)
    The goal of this test is to find how much does PSNR change (improve) with ever slower presets. Unfortunately, psy stuff skews the result so my suggestion is to rule the psy out for pure PSNR test. I don’t have access to IEEE so i won’t be able check the paper but looking at your graph one might say that –preset fastest is actually one of the best for PSNR.(i can bet that the best result for this one clip, which is on –preset fastest, would lose badly to –placebo with –tune psnr added to both commandlines).
    As a side note – while you know that PSNR is so-so for evaluating subjective quality it is actually quite good (from my limited knowledge) for relative comparisons such as this one (developers of x264 actually get better results with psnr than ssim).

    The speed-part of this test is fine so maybe, maybe make a graph with speed from this graph and PSNR (quality) from –tune psnr encodings on the other axis? (because we want RELATIVE improvement)?
    Please post your results on doom9 forum (especially if you can get your hands on PEVQ analyzer) as there are quite a few people interested in this and you get nice feedback on your work. Also, by re-doing the test you could measure latest speed/quality improvements in x264 to boot:)
    Wainting for the results

  4. Niobos says:

    Hi jet,

    Well, the goal of this test was actually to find out how much slower “slower” is, so I wanted the psy to be activated.
    I’m glad to see that you recognize the usability PSNR, even though we both know that it is far from a perfect quality measure, that’s exactly what the IEEE article explains (as can be read in the free abstract). But I’m also curious to see what correlations there are between PSNR, SSIM, PEVQ and subjective quality.
    When I redo this test more thoroughly, I’ll post (a link to) them on doom9. I didn’t post the results from this post, because I know that they’re not obtained in a scientific relevant way.

    thx for the valuable feedback!

  5. fumo says:

    Nice job, I was looking for some sort of comparison, even if it’s not perfect it definitely is much better than nothing… I hope you maybe still will do both PSNR and SSIM and maybe an Opticom analyzer 😉
    Thanks for including presets parameters – I couldn’t find them anywhere