Тестирование скорости кодека x265

Для оценки прогресса в разработке кодека x265 мы провели небольшое тестирование. А как же изменялась скорость кодирования на разных пресетах от версии к версии. Тестирование проводилось на следующем конфиге: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz, 32 GB DDR3. Измерялся средний FPS кодирования на одном и том же тестовом видеофайле (1080p@25fps).

Тестировались версии x265:
1.0, 1.1, 1.2, 1.3, 1.4
Проверялись пресеты:
DEFAULT — запуск кодека без параметров
CRF-20 — запуск кодека только с ключом -CRF 20 без параметров
ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo — был задан только соответствующий -preset
Компиляторы:
GCC 4.9.2, ICC 1400, MSVC 1800 — на этих трех разных компиляторах был собран x265

Ниже приведена сводная таблица и графики:

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
На этом графике приведено сравнение скорости кодирования на разных пресетах для x265 версии 1.4
diff-presets

Выводы:
1) Скорость кодирования в версии 1.4 по сравнению с версией 1.0 выросла в 1.5-2 раза.
2) Даже не достаточно мощном компьютере все ещё не получается кодировать в реальном времени даже на самых быстрых пресетах.
3) Пресет medium является оптимальным для кодирования. Сильно быстрее slow, placebo и.т.д. и при этом не сильно уступает в скорости даже ultrafast.
4) Разница не существенна, но на тестовом стенде самыми быстрым оказались сборки, сделанные на Microsoft Visual C.

8 комментария на “Тестирование скорости кодека x265

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

  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.

    • 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.

  3. 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.

  4. 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.

Добавить комментарий

Войти (Login): 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*