Сравнивалось качество и скорость кодирования двух кодеков:
* x264 версия core 142 (64-бита, gcc)
* x265 версия 0.6+258 (64-бита, gcc)
Входные данные
Для сравнения использовался входной файл «1_CrowdRun_1080p25.yuv» из набора
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/
Разрешение файла 1920х1080 (FullHD) 25 кадров в секунду. Цветовое пространство YUV 4:2:0. Исходный размер файла 760 Мбайт. Ролик содержит всего 250 кадров.
Процесс сравнения
Файл кодировался на разных CRF от 15 до 30. Каждым из кодеков на разных пресетах. Дополнительные ключи не задавались.
Пресеты для кодирования x264: slower, veryslow, placebo
Пресеты для кодирования x265: medium, slow, slower, veryslow. (placebo не использовался из-за астрономического времени на кодирование)
Строчка для кодирования x264:
x264.exe --input-res 1920x1080 --fps 25 --level 4.1 --preset veryslow --crf 15 -o output.264 result.yuv
Строчка для кодирования x265:
x265.exe --input-res 1920x1080 --fps 25 --level 4.1 --preset veryslow --crf 15 --input-depth 8 --o output.hevc result.yuv
Далее измерялось время кодирования и размер выходного файла для каждого запуска.
Графики и таблицы сравнения
Время кодирования:
Подробная таблица (время кодирования в секундах, меньше лучше)
| CRF | x264 slower | x264 veryslow | x264 placebo | x265 medium | x265 slow |
x265 slower | x265 veryslow |
| 15 | 86 | 117 | 234 | 159 | 249 | 1865 | 2790 |
| 16 | 80 | 114 | 221 | 158 | 243 | 1763 | 2634 |
| 17 | 74 | 102 | 214 | 149 | 235 | 1626 | 2437 |
| 18 | 68 | 94 | 202 | 146 | 232 | 1514 | 2304 |
| 19 | 65 | 89 | 191 | 135 | 218 | 1347 | 2057 |
| 20 | 60 | 86 | 181 | 125 | 203 | 1218 | 1863 |
| 21 | 56 | 76 | 172 | 115 | 192 | 1092 | 1689 |
| 22 | 53 | 71 | 163 | 109 | 181 | 976 | 1519 |
| 23 | 50 | 65 | 158 | 108 | 165 | 887 | 1387 |
| 24 | 46 | 61 | 151 | 101 | 162 | 813 | 1292 |
| 25 | 43 | 57 | 142 | 99 | 150 | 766 | 1223 |
| 26 | 40 | 55 | 140 | 92 | 148 | 756 | 1141 |
| 27 | 41 | 52 | 136 | 89 | 140 | 668 | 1058 |
| 28 | 37 | 50 | 128 | 87 | 137 | 616 | 1002 |
| 29 | 35 | 48 | 126 | 84 | 138 | 582 | 949 |
| 30 | 35 | 45 | 124 | 82 | 131 | 542 | 893 |
Размер файла (в байтах):
Подробная таблица (размер файла в байтах, меньше лучше)
| CRF | x264 slower |
x264 veryslow | x264 placebo | x265 medium | x265 slow |
x265 slower | x265 veryslow |
| 15 | 101522180 | 98322238 | 98454048 | 88274724 | 92652594 | 85629715 | 85893115 |
| 16 | 87201610 | 84153321 | 84276669 | 76424310 | 80086971 | 73636295 | 73792032 |
| 17 | 74397615 | 71529541 | 71575680 | 65869119 | 68154675 | 62282396 | 62447838 |
| 18 | 63132654 | 60554101 | 60538386 | 56103534 | 57254828 | 52021685 | 52219113 |
| 19 | 53377996 | 51042367 | 51018164 | 47020395 | 46973227 | 42563037 | 42738755 |
| 20 | 44898840 | 42853079 | 42861909 | 39876377 | 39459522 | 35672061 | 35782799 |
| 21 | 37813482 | 36109833 | 36182195 | 33567197 | 32675539 | 29519116 | 29605900 |
| 22 | 32078403 | 30654724 | 30782369 | 28285038 | 27155876 | 24410097 | 24516145 |
| 23 | 27528735 | 26395066 | 26530552 | 23973363 | 22642812 | 20382010 | 20461329 |
| 24 | 23875254 | 22943666 | 23048636 | 20466459 | 18983059 | 17137993 | 17185619 |
| 25 | 20796190 | 19988388 | 20081942 | 17587743 | 16004565 | 14525220 | 14550284 |
| 26 | 18124475 | 17429621 | 17524443 | 14969665 | 13454918 | 12257475 | 12282829 |
| 27 | 15819902 | 15225342 | 15326830 | 12663043 | 11304791 | 10369316 | 10384867 |
| 28 | 13827338 | 13307218 | 13411572 | 10791089 | 9551058 | 8848979 | 8838106 |
| 29 | 12069990 | 11619505 | 11732465 | 9213056 | 8133832 | 7628134 | 7613975 |
| 30 | 10526933 | 10139473 | 10262268 | 7881534 | 6974773 | 6612335 | 6597796 |
Процент уменьшения размера файла по сравнению с x264 placebo для x265 veryslow (больше лучше)
Как видно процент уменьшения изменяется от 12 до 35, что весьма значительно. Кодек x265 работает эффективнее на высоких CRF.
Процент уменьшения размера файла по сравнению с x264 placebo для x265 medium (больше лучше)
Как видно процент уменьшения изменяется от 8 до 23, что тоже весьма впечатляет, так как время кодирования на настройках medium даже меньше чем у placebo x264 и лишь слегка уступает x264 veryslow.
Визуальное качество
Сравнение кусочка картинки (500×300) для разных CRF на x264 (placebo) и x265 (veryslow). Слева x264, справа x265. Цифры в углу обозначают значение CRF:
Как видно на низких CRF x265 гораздо сильнее мажет картинку. И там где на x264 ещё читаются номера на x265 это сделать уже затруднительно.
Кадр номер 100 для x264 и x265 на CRF=30:
x264:
![1_CrowdRun_1080p25_preset_placebo_30crf.mp4_snapshot_00.04_[2014.02.03_00.11.10]](http://x265.ru/wp-content/uploads/2014/02/1_CrowdRun_1080p25_preset_placebo_30crf.mp4_snapshot_00.04_2014.02.03_00.11.10.png)
x265:
![1_CrowdRun_1080p25_preset_veryslow_30crf.mp4_snapshot_00.04_[2014.02.02_23.49.53]](http://x265.ru/wp-content/uploads/2014/02/1_CrowdRun_1080p25_preset_veryslow_30crf.mp4_snapshot_00.04_2014.02.02_23.49.53.png)
Рекомендую открыть оба скриншота в браузере и переключаться между ними. Невооруженным взглядом видно, что качество у x265 намного хуже, чем у x264 для одного значения CRF.
Выводы и наблюдения
- Кодирование x265 на одном значении CRF дает размер файла меньше чем x264 (12-35% для veryslow)
- Кодирование x265 на пресетах veryslow и slower дает примерно одинаковый размер файла. Slower при этом иногда даже меньше, чем Veryslow. Считается при этом почти в два раза быстрее. Однако и тот и другой пресет серьезно проигрывают по времени счета x264 в десятки раз, даже когда x264 считает на placebo. На обработку одного кадра уходит 3-10 секунд.
- Кодирование x265 на пресетах slow и medium (дефолт) по скорости работает на уровне placebo от x264 и чуть быстрее. Размер файла также меньше чем у x264. Пресет medium работает лучше slow на маленьких CRF.
- В целом x265 дает меньший размер файла, чем x264 почти в любых случаях и его вполне можно использовать как замену x264, особенно на больших значениях CRF.
- К текущим недостаткам ещё можно отнести тот факт, что декодер x265 потребляет гораздо больше вычислительных ресурсов, чем декодер x264. И чем меньше CRF тем мощнее требуется компьютер. Например на CRF=15 мой ноутбук (Core i7) уже не тянет проигрывание видео в x265.
Важные вопросы требующие ответов
- Одинаково ли трактуется значение CRF в кодеках x264 и x265. Корректно ли сравнивать между собой файлы закодированные на одном CRF двумя этими кодеками? Судя по сравнению скриншотов сравнивать напрямую некорректно.
- Одинаковое ли визуальное качество у двух файлов с одним CRF, но закодированном на разных пресетах в рамках одного кодека? Ответ нужен и для x264 и для x265
Спасибо за труд.
Если судить по crf 30, размер у x265 меньше на 35%, но и качество серьезно хромает.
Думаю x264 сегодня по прежнему можно считать лучшим видео кодеком современности. 🙂
Обычно я подгоняю файлы по размеру, и потом визуально сравниваю по качеству картинки.
Это конечно не столь информативно, но очень быстро.
В общем как вывод: никаких 50% уменьшения объема, как заявляется в рекламе H265 нет и в помине.
Да и вряд ли их можно будет когда либо ожидать.
15-20% думаю это предел.
Ну кодек пока в активной разработке. 50% мб и будет, но гораздо позже. Периодически буду тестить большие релизы и смотреть за прогрессом.
Если не ошибаюсь экономия 50% заявлена в профиле Main10 10bit цвет, но он ещё не реализован в x265, а в Main экономия битрейта должна составлять 25%.
От таких сравнений создается создается ложное впечатление, что x265 работает в разы медленнее, а результата никакого. У меня предложение попробовать для следующего сравнения сделать сравнение в битрейте по SSIM с включеным AQ у обоих энкодеров. Силу AQ желательно держать в районе 2.
x265 и x264 сами могут выдавать метрику SSIM в консоли.
Стандартные настройки и кодирование для PSNR хороши для высоких битрейтов, а AQ как раз и придумали как способ повышения качества при средних и низких битрейтах.
В данном сравнении PSNR не использовался вовсе. )
А можешь выдрать строчку из консоли где метрика SSIM пишется? Я бы тогда в свой парсер засунул.
x265 по умолчанию кодирует для PSNR. А x264 по умолчанию включает кучу опций всяких оптимизаций.
В частности, x264 по умолчанию уже использует AQ c aq-strength 1, а в x265 оно выключено. Именно поэтому последний мылит, а первый — нет.
Для обоих кодеров можно использовать
—tune ssim —ssim —aq-mode 1 —aq-strength 1.8
В приципе, можно задать —aq-mode 2 и не задавать aq-strength.
x264 выдаст такое:
x264 [info]: SSIM Mean Y:0.9701767 (15.254db)
x265 выдаст в последней строчке
encoded 120 frames in 15.56s (7.71 fps), 955.84 kb/s, SSIM Mean Y: 0.9762467 (16.243 dB)
И какие ключи предлагается юзать для AQ? Проверю в следующем тесте. В доках вроде написано что AQ включено по дефолту.
сравнивать placebo х264 vs veryslow х265 как минимум не честно и предвзято по отношению к х265.
да даже veryslow х264 vs veryslow х265 таже ситуация, так как у х265 на таких пресетах просто отстойные настройки по сравнению с х264.
placebo х264 vs placebo х265 даст обьективный результат
или же нужно veryslow х264 vs х265 с ручными настройками до уровня аналогичных настроек у х264.
Ну мне кажется что разработчики должны более четко расставлять ключи для часто используемых пресетов, что бы не заморачиваться с кучей ключей. Если оно отключено по умолчанию, то это наверное умышленно?
да, ещё забыл такой нюансик:
х264 по умолчанию жмёт при закрытых гопах
х265 — при открытых
соответственно нужно:
или
открыть гопы в х264 (—open-gop)
или
закрыть гопы в х265 (—[no-]open-gop)
или
закрутить ключик в х265 до (—keyint 25) при открытых гопах
Открытые, закрытые, приоткрытые, распахнутые или с занавесками — разница здесь не имеет смысла. Главное, чтобы цель кодирования была одна и та же. А там пусть кодеки сами решают как им кодировать.
x264 по умолчанию кодирует для визуального качества, а x265 — для PSNR, что, естественно, не одно и то же. Если на глаз сравнивать, то и получается у последнего как-то не очень.
Сравнивать по PSNR? Тогда «tune psnr» у обоих. Сравивать по SSIM? «Tune ssim» у обоих. Просто сравнивать на глаз? Тогда у x264 все оставить как есть, а в x265 «tune ssim» ставить пока они не добавят фич.
вот не поленился, и сделал энкод с более менее нормальными настройками х265, и прошу заметит, что это ещё не плацебо!!!
x265 —input «1_CrowdRun_1080p25».yuv —input-res 1920×1080 —fps 25 —frame-threads 4 —crf 30 —ref 16 —bframes 8 —merange 64 —max-merge 3 —me 2 —subme 5 —rd 4 —aq-mode 1 —aq-strength 0.8 —keyint 25 —b-adapt 2 —rdpenalty 1 —early-skip —bframe-bias 33 —rc-lookahead 40 —ssim —tu-intra-depth 3 —tu-inter-depth 3 —output «video.hevc»
Кадр номер 100 для x265 на CRF=30:
http://i.imgur.com/jhp7YDj.jpg
если сравнить мой скрин и скрин из шапки — х264 placebo….
х264 в топку, он и рядом не стоял с х265.
log_x265 прилагается:
x265 [info]: HEVC encoder version 0.6+343-eb3713ab0641
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames : 17 / 8 / 4
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : umh / 64 / 5 / 3
x265 [info]: Keyframe min / max : 25 / 25
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-30.0 / 0.8 / 1
x265 [info]: RDpenalty : 1
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / refs : 1 / 1 / 16
x265 [info]: tools: rect amp esd rd=4 lft sao-lcu sign-hide
encoded 250 frames in 296.51s (0.84 fps), 6420.92 kb/s, SSIM Mean Y: 0.8011705 ( 7.015 dB)
x265 [info]: frame I: 10 kb/s: 26381.32 SSIM Mean: 0.831084
x265 [info]: frame P: 31 kb/s: 10395.68 SSIM Mean: 0.800574
x265 [info]: frame B: 209 kb/s: 4876.32 SSIM Mean: 0.799828
x265 [info]: global : 250 kb/s: 6420.92 SSIM Mean: 0.801170
x265 [info]: 11 of 31 (35.48%) P frames weighted
и всё таки остаюсь при своём мнении, что тест топикстартера или неправильно организован по неопытности , или нарочно предвзят для х265 по каким либо мотивам.
Я тоже на низкобитрейтном тесте использовал довольно тяжёлые настройки, какие к сожалению не помню.
Я не разбираюсь в тонкостях всех ключей, поэтому использовал дефолтные пресеты для более честного сравнения.
Этот скрин x265 выглядит визуально посимпатичнее x264. Но не без изъянов, видно, как замылило деревья и траву сзади.
Давайте поберем набор «идеальных» ключей для x264 и x265 для последующих тестов. У меня нет предвзятости,я пытаюсь сравнивать максимально объективно.
Здравствуйте, я качал отсюда: http://media.xiph.org/video/derf/y4m/ файл city_4cif_30fps.y4m, на нём на сверх низком битрейте x265(в версии 0.4 или новее) показал значительно лучший результат чем x264 на hevc было сильное мыло и местами заметные артефакты, на avc артефакты были просто ужасными и видео смотрелось значительно хуже. Кстати 10bit видео смотрелось ещё хуже. И ещё кодек растягивал видео(по времени) снижая частоту кадров до 25( в ранних билдах 0.6 замечал тоже самое, сейчас не знаю), на видео park_joy_1080p50 и park_joy_420_720p50(оттуда же) в 0.6 343. Тесты city_4cif_30fps.y4m к сожалению не сохранились.
прошу прощения, перезалил скрин на другой хост, а то он его в jpg испортил.
http://savepic.net/4512629.png
кстати обратите внимание на вес моего скрина, и скрина из шапки.3,1 MБ х265 (3 196 775 байт) vs x264 (4 950 936 байт)
замыливание заднего фона это фишка всех энкодеров, кто то сильнее кто то менее.
просто согласно правилу просмотра человек концентрирует внимание на передний план, где происходит основное действие, и перефирийным зрением воспринимает окружающую среду.
посему квадратные головы спортсменов при просмотре будут бросаться в глаза как аномалия, а вот детализацию травы и листвы на заднем фоне можно совсем и не заметить…
————————
по поводу «идеальных» ключей для x264 и x265 — думаю таких нет, но есть одинаковые настройки, + дополнительные фишки в как в 264 так и в 265.
предположительно общие настройки свести на равные, а остальные фишки каждого выкрутить на максимум, дабы раскрыть весь потенциал обоих.
Использовать режим CRF для сравнения — плохая идея. Грубая аналогия: сравнивал High10 и High у энкодера x264 используя режим CRF, в обоих случаях настройки были абсолютно идентичны за исключением профиля. В итоге High10 потребовал заметно больше битр-а чем High.
Однако ради любопытства завысил CRF в High10 и был приятно удивлён: High10+CRF20 визуально давал изображение лучше чем High+CRF15, а битр-а потреблял почти в 2 раза меньше. А ведь это только в рамках одного и того же энкодера, что уж говорить про 2 разных…
Так что наиболее объективным будет использование режима «битрейт» (либо CBR, либо ABR).
ситуация с Main10 и Main у х265 аналогичная с High10 и High у х264
*наиболее объективным будет использование режима «битрейт» * — с этим абсолютно согласен, так как размер выходного файла, при одинаковом битрейте обоих энкодеров, одинаковый.
только вот режим ABR даёт слишком большой разброс.
CBR — пока опции включения такого режима у х265 не предвидится.
на подходе многопроходной режим, который обеспечит 99.9% совпадение битрейта, вот его внедрение и ждёмс с нетерпеньем.
«Как видно процент уменьшения изменяется от 12 до 35, что весьма значительно. Кодек x265 работает эффективнее на высоких CRF.»
что под выскими понимается?
С одной стороны цифра 35 более высокая по сравнению с 12, но 12 означает более высокое качество… под каким углом Вы смотрите?