15 thoughts on “Comparing x264 and x265 for bitrate-based encoding (01.2014)”
Привет. У меня получился несколько другой результат при кодировании x264 (core 140.2377) через MeGUI, в том же режиме: 2000kbps, 2pass, Preset=VerySlow, x64 mode. Мой скриншот отличается от твоего на том же кадре. Выложи плиз свой видео файл x264, чтобы я посмотрел через MediaInfo твои точные установки кодирования x264 и сделал сам скриншот из него. Могу выложить свой скриншот но не знаю как его загрузить на этот сайт.
Zorro, я сейчас на отдыхе далеко от компа на котором делалось сравнение. До файликов доберусь только 22 января. Как только дойду сразу выложу. Если что вот скрипт, которым кодировалось:
set x264binary=x264_64.exe
set filename=1_CrowdRun_1080p25
У меня не стояла опция “slow-firstpass”, но даже без нее картинка получилась получше чем тут выложена. А после того как я поставил “slow-firstpass” то картинка стала еще лучше.
Но я считаю что некорректно сравнивать x265 однопроходный режим с двухпроходным режимом x264. Надо сравнивать с однопроходным режимом x264. Дело в том что никакие профессиональные приложения и оборудование не используют двухпроходный режим кодирования H264. Телевещание, интернет-трансляции, видеорегистраторы, системы видеонаблюдения, платы аппаратного кодирования, мастеринг Blu-Ray дисков – везде используется однопроходный режим H264.
И я лично тоже для практических целей уже много лет не использую двухпроходный режим кодирования – это лишняя трата времени. При правильно подобранном битрейте и настройках, однопроходный режим (при заданном битрейте или постоянном заданном режиме качества) в x264 через MeGUI или через x264 VFW дает прекрасный результат, нет смысла применять двухпроходный режим. Кроме того, с недавних пор у меня есть профессиональная карта аппаратного кодирования в H264 – Matrox CompressHD (стоит 540 USD) так что есть с чем сравнивать.
Двухпроходное кодирование все ещё используется там, где нет критичности к real-time. Например когда кодируют фильмы или клипы. Но я согласен, что на графике стоило добавить и результат однопроходного кодирования для наглядности. И если существенной разницы с двумя проходами реально не будет, то убрать два прохода в следующих тестах.
я так понял, на выставке крутили демо ролик с разрешением 4к на телике 4к, но экран телика разделили на пополам.
на первой половине экрана был 265рипчик, на второй половине – синхронно крутился 264рипчик .
ну и в конце концов один из разрабов щёлкнул этот процес на фотик…
если сравнить мой скрин от энкодера х265 с кадром разраба, можно согласится, что по качеству они выглядят почти одинаково.
а вот добиться такого плохого качества как у разраба от х264 энкодера – мне не удалось, он выглядит несколько лучше, нежели аналогичный кадр от х265.
не ожидал я такого обмана со стороны разраба…
———————————————————————-
учитывая четырёхкратную разницу в битрейте, можно сказать, что х265 показал себя вполне достойно, а увеличив битрейт до 8000 вполне способен обойти х264.
Привет. У меня получился несколько другой результат при кодировании x264 (core 140.2377) через MeGUI, в том же режиме: 2000kbps, 2pass, Preset=VerySlow, x64 mode. Мой скриншот отличается от твоего на том же кадре. Выложи плиз свой видео файл x264, чтобы я посмотрел через MediaInfo твои точные установки кодирования x264 и сделал сам скриншот из него. Могу выложить свой скриншот но не знаю как его загрузить на этот сайт.
Zorro, я сейчас на отдыхе далеко от компа на котором делалось сравнение. До файликов доберусь только 22 января. Как только дойду сразу выложу. Если что вот скрипт, которым кодировалось:
set x264binary=x264_64.exe
set filename=1_CrowdRun_1080p25
for /l %%i in (2000,2000,14001) do (
“./Soft/%x264binary%” –input-res 1920×1080 –fps 25 –level 4.1 –preset veryslow –slow-firstpass –bitrate %%i –stats “x264/stats.log” –pass 1 -o “x264/%filename%.264” “Uncompressed/%filename%.yuv” 2> “logs/%filename%_x264_%%ikbps_pass1.log
“./Soft/%x264binary%” –input-res 1920×1080 –fps 25 –level 4.1 –preset veryslow –slow-firstpass –bitrate %%i –stats “x264/stats.log” –pass 2 -o “x264/%filename%.264” “Uncompressed/%filename%.yuv” 2> “logs/%filename%_x264_%%ikbps_pass2.log
“./Soft/MP4Box.exe” -add “x264/%filename%.264” -new “x264/%filename%_%%ikbps.mp4”
del “x264\%filename%.264”
)
Файлик x264_64.exe использовался из AMVSimpleGUI 4.0: http://amvnews.ru/index.php?go=Pages&in=view&id=34
У меня не стояла опция “slow-firstpass”, но даже без нее картинка получилась получше чем тут выложена. А после того как я поставил “slow-firstpass” то картинка стала еще лучше.
Но я считаю что некорректно сравнивать x265 однопроходный режим с двухпроходным режимом x264. Надо сравнивать с однопроходным режимом x264. Дело в том что никакие профессиональные приложения и оборудование не используют двухпроходный режим кодирования H264. Телевещание, интернет-трансляции, видеорегистраторы, системы видеонаблюдения, платы аппаратного кодирования, мастеринг Blu-Ray дисков – везде используется однопроходный режим H264.
И я лично тоже для практических целей уже много лет не использую двухпроходный режим кодирования – это лишняя трата времени. При правильно подобранном битрейте и настройках, однопроходный режим (при заданном битрейте или постоянном заданном режиме качества) в x264 через MeGUI или через x264 VFW дает прекрасный результат, нет смысла применять двухпроходный режим. Кроме того, с недавних пор у меня есть профессиональная карта аппаратного кодирования в H264 – Matrox CompressHD (стоит 540 USD) так что есть с чем сравнивать.
Отредактировал запись:
1) Добавил однопроходное кодирование x264 на график
2) Добавил набор файликов закодированных на 2000kbps
Будет интересно если посмотришь не накосячил ли я где. )
А что с кодированием не для PSNR, а для SSIM с адаптивным квантованием? Ведь именно SSIM лучше показывает визуальное качество картинки.
Я без AQ никогда ничего не кодирую. C aq-mode 1 и aq-strength 2 x265 мылить начинает в разы меньше
К сожалению для AVISynth я нашел только реализацию PSNR. Возможно попозже и SSIM прикручу.
Двухпроходное кодирование все ещё используется там, где нет критичности к real-time. Например когда кодируют фильмы или клипы. Но я согласен, что на графике стоило добавить и результат однопроходного кодирования для наглядности. И если существенной разницы с двумя проходами реально не будет, то убрать два прохода в следующих тестах.
Интересно было бы увидеть x264 в crf с подогнанным по размеру файла.
Тесты по CRF на подходе.
презентация от разрабов
x265 veryslow 4 Mbps vs x264 veryslow 16 Mbps
http://forum.doom9.org/showpost.php?p=1677487&postcount=635
конечно там не описано всех деталей тестов, но вполне достаточно информации для желающих повторить этот тест у себя.
исходник:
http://media.xiph.org/video/derf/y4m/crowd_run_2160p50.y4m
полноценные скрины теста от разрабов
http://x265.org/CrowdRun4K_4Mbps.7z
На самом деле, там вообще никаких подробностей нет. Даже пояснения, что именно изображено на картинке. Придется самому проверять. )
я так понял, на выставке крутили демо ролик с разрешением 4к на телике 4к, но экран телика разделили на пополам.
на первой половине экрана был 265рипчик, на второй половине – синхронно крутился 264рипчик .
ну и в конце концов один из разрабов щёлкнул этот процес на фотик…
провёл у себя такой же блиц-тестик.
x265 –input “crowd_run_2160p50.y4m” –bitrate 4000 –preset veryslow –output “video.hevc”
265лог – http://paste.org.ru/?5n7ey0
x264 “crowd_run_2160p50.y4m” –bitrate 16000 –preset veryslow –output “video264.mkv”
264лог – http://paste.org.ru/?grrpjq
сделал скрины того же кадра, что и у разраба в архиве:
х265
http://lostpic.net/orig_images/e/d/6/ed672e8d3a5ec8e1b437b1e5f140c2ba.png
х264
http://lostpic.net/orig_images/9/4/e/94ec9570a528a13f5251c7d6ae3e0aea.png
если сравнить мой скрин от энкодера х265 с кадром разраба, можно согласится, что по качеству они выглядят почти одинаково.
а вот добиться такого плохого качества как у разраба от х264 энкодера – мне не удалось, он выглядит несколько лучше, нежели аналогичный кадр от х265.
не ожидал я такого обмана со стороны разраба…
———————————————————————-
учитывая четырёхкратную разницу в битрейте, можно сказать, что х265 показал себя вполне достойно, а увеличив битрейт до 8000 вполне способен обойти х264.
Вот мне тоже показалось, что x264 не может давать такого качества на 16 Мбпс. Мб на 4 Мбпс и то сомневаюсь.
По твоим скринам x264 на порядок лучше чем x265.
У разраба показан кадр закодированный x264 c bitrate 4000.
Я когда проверял, почему-то сразу понял какой битрейт сравнивается у обоих кодеков.