Speed testing of x265 codec

We did some testing to assess progress in the development of codec x265. How encoding rate was changed for different presets from version to version? Testing was performed on the following config: Intel (R) Core (TM) i7-4930K CPU @ 3.40GHz, 32 GB DDR3. We encoded the same test video file (1080p @ 25fps) on different presets and measured the average FPS.

x265 Versions:
1.0, 1.1, 1.2, 1.3, 1.4
Tested presets:
DEFAULT – run without parameters
CRF-20 – run with key -CRF 20 without any other parameters
ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo – defined only -preset “…”
Compilers:
GCC 4.9.2, ICC 1400, MSVC 1800

Below is a summary table and graphics:

ver. comp iler DEF AULT CRF -20 ultra fast super fast very fast faster fast medium slow slower veryslow placebo
1.0 GCC 4.9.2 4.50 4.08 10.94 7.00 6.93 7.84 7.97 4.72 2.45 0.52 0.35 0.20
1.0 ICC 1400 4.76 4.10 10.82 6.62 6.56 7.62 7.90 4.74 2.42 0.51 0.35 0.20
1.0 MSVC 1800 4.76 4.14 11.44 6.97 6.92 7.95 8.08 4.78 2.46 0.54 0.35 0.20
1.1 GCC 4.9.2 8.07 6.44 13.12 9.30 8.81 10.29 8.69 8.07 2.40 0.51 0.34 0.20
1.1 ICC 1400 8.11 6.48 13.10 9.13 8.72 10.26 8.74 8.14 2.37 0.51 0.34 0.20
1.1 MSVC 1800 8.11 6.58 13.82 9.61 9.12 10.64 8.87 8.26 2.41 0.54 0.34 0.20
1.2 GCC 4.9.2 9.02 7.40 15.06 12.18 11.44 12.26 11.06 8.82 2.62 0.58 0.39 0.24
1.2 ICC 1400 9.02 7.42 14.88 11.96 11.16 12.17 10.91 8.83 2.60 0.57 0.39 0.24
1.2 MSVC 1800 9.02 7.53 15.44 12.68 11.83 12.68 11.32 8.99 2.69 0.61 0.39 0.24
1.3 GCC 4.9.2 8.88 7.29 15.24 12.85 12.00 12.77 11.57 8.88 2.60 0.59 0.39 0.24
1.3 ICC 1400 8.95 7.48 14.92 12.56 11.81 12.69 11.64 8.95 2.58 0.59 0.39 0.24
1.3 MSVC 1800 8.95 7.55 16.13 13.25 12.53 13.30 11.97 9.13 2.62 0.61 0.39 0.24
1.4 GCC 4.9.2 9.32 7.47 17.95 13.92 12.25 13.09 11.66 9.33 2.64 0.73 0.51 0.32
1.4 ICC 1400 9.41 7.67 17.78 13.72 12.19 13.21 11.78 9.42 2.62 0.73 0.51 0.32
1.4 MSVC 1800 9.41 7.63 18.42 14.34 12.58 13.44 11.92 9.48 2.65 0.74 0.51 0.32


Default
CRF-20
ultrafast
superfast
veryfast
faster
fast
medium
slow
slower
veryslow
placebo
This chart shows a comparison of the encoding rate for different x265 (ver. 1.4) presets
diff-presets

Conclusion:
1) Encoding speed in version 1.4 compared to version 1.0 has increased x1.5-2 times.
2) Powerful computer still fails to encode in real time, even on the fastest presets.
3) Preset medium is optimal for coding. Much faster than slow, placebo, etc. and not much inferior in speed even with ultrafast.
4) The difference is not significant, but on the test stand the fastest x265 assembly was made with Microsoft Visual C.

Опубликовано — 8 Comments ↓

8 thoughts on “Speed testing of x265 codec”

  1. А есть ли преимущество, если собирать в ICC только под данный ЦП?
    Если да, насколько оно выражается?

    Reply ↓

  2. It still need some improvement, but it’s getting better and better, keep working on it 😉

    I use preset medium for my encode on 4K and it’s the best preset you can select. Even with an 8 cores, 12 MB of cache, speed isn’t good enough, but, in order to perform an encoding without becoming old, preset medium is the best option: not so different from “fast”, but much more faster than “slow” and the final file size of slow preset isn’t worth it compared to the medium one.

    Reply ↓

    • This is only possible for low bitrates according to my tests. x265 needs 2 Xeon Sockets for real time encoding (Ultrafast Preset) in some cases. It depends on what test sequences you are using, complex sequences are very time consuming.

      Reply ↓

  4. Now reencoding some video to 256×192 at 56 kbit/s (+8 kbit/s opus audio) with placebo preset – get only 0.2 fps coding speed on my AthlonII x3 2.9 GHz. 🙁
    But results for fast moving scenes are really much better then x264.
    Want to see more video coded at 64kbitps on internet.

    Reply ↓

  5. Great test. Thanks for sharing. Even though it’s dated by now, still some good info here, but the report doesn’t indicate the resulting file sizes. It’s not possible to make a cost-benefit analysis decision only knowing the cost (enduring a slower frame rate) without the payoff (how much smaller the resulting file size is). There’s a big cost going from “medium” to “slow” preset, but no indication as to how much it reduces the file size.

    The other thing to note is minor – axes normally are labeled. In this case, it’s not a big deal because it’s not too hard to deduce them (“frame rate” and “version”).

    I’d be interested in seeing the results for newer versions (I think 1.9 is the latest at this writing).

    Thanks again for sharing.

    Reply ↓

Leave a Reply

Войти (Login): 

Your email address will not be published. Required fields are marked *

*