The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Сравнение скорости кодирования и декодирования видео при помощи VP9, HEVC и H.264

28.09.2015 10:13

Рональд Бултье (Ronald S. Bultje), принимающий участие в разработке FFmpeg, провёл исследование производительности и качества работы кодировщиков и декодировщиков для видеоформатов VP9, HEVC и H.264. В тестах приняли участие поддерживаемые в FFmpeg кодировщики libvpx, x265 и x264, и декодировщики openHEVC, ffh264, ffvp9, ffhevc.

Основные выводы:

  • Кодеки нового поколения x265 и libvpx на 50% более эффективно используют битрейт по сравнению с x264, но работают в 10-20 раз медленнее;
  • Рассчитанный на эффективное использование CPU кодек libvpx близок по производительности к x264 на сопоставимых битрейтах. x265 работает слишком медленно в большинстве практических применений, за исключением high-end сценариев;
  • Самым быстрым декодировщиком является ffvp9, но ffh264 лучше масштабируется при увеличении количества ядер CPU;
  • На многоядерных системах декодирование в многопоточном режиме даёт заметный выигрыш. Декодер libvpx-vp9 не поддерживал многопоточность для выбранного режима тестирования;


  1. Главная ссылка к новости (https://blogs.gnome.org/rbultj...)
  2. OpenNews: Разработчики FFmpeg написали собственный декодер для видеокодека VP8
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/43052-vp9
Ключевые слова: vp9, h264, video, codec
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, IZh. (?), 10:56, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Важно понимать, что в тех же мобильных телефонах картина может быть совсем другой, так как там используются аппаратные декодеры, а не CPU. И сравнивать нужно на конкретном SoC'е, так как разные производители по-разному их делают.
     
     
  • 2.3, . (?), 11:49, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –5 +/
    в них используются те же самые декодеры, что и в писюках И это ни разу не CPU ... большой текст свёрнут, показать
     
     
  • 3.16, dimqua (ok), 19:54, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А для h265 ничего пока, насколько я понимаю, нет, одни proof-of-concept поделки.

    Orange Pi 2 есть, как минимум. Или не о железе речь?

     
     
  • 4.20, пох (?), 23:22, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    не о железе, а о поддержке железа декодерами (не говоря уж о энкодерах, каковые у нас строго mp4). Конкретно ffmpeg'овыми, потому что никаких других общедоступных (я даже не об opensource, а о том что в принципе может быть куплено за деньги) один хрен нет.
    Если бы на моем домашнем десктопе видео декодировал процессор - я бы кроме слайдшоу ничерта бы не видел.
    А теперь посмотрим, как у h265-х образчиков с vaapi/vdpau и поплачем...

    У телефонов в этом плане ровно все то же самое что у "больших".

     
     
  • 5.21, soarin (ok), 04:45, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Так  nvidia с VDPAU Set F (GTX 950, 960) + свежий ffmpeg = и увсё будет
     
     
  • 6.22, . (?), 12:16, 29/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    у меня вот есть основания полагать, что h265 - не будет.
    Наверное, будет vp9 через libvpx, но я не проверял - раньше не работало.
     
     
  • 7.25, soarin (ok), 21:08, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Мало того, в свободный AMD драйвер прикрутили http://www.phoronix.com/scan.php?page=news_item&px=VDPAU-HEVC-AMDGPU
    А об VP9 пока не чесались.
     
  • 2.5, Аноним (-), 12:23, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И декодеры, и кодеры. Как в авторегистраторе :-) Ждём на декстопах!
     

  • 1.2, Аноним (-), 11:03, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Кодеки нового поколения ... libvpx ... по сравнению с x264 ... работают в 10-20 раз медленнее;
    > Рассчитанный на эффективное использование CPU кодек libvpx близок по производительности к x264 на сопоставимых битрейтах.

    Нет ли здесь деления на 0?

     
     
  • 2.10, Аноним (-), 13:41, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Нет ли здесь деления на 0?

    Мы, анонимы, птице-ежики гордые - по ссылкам просто так не летаем, да?
    >So what do these results mean? Well, first of all, yeah, sure, x264/libvpx are ~50% better than x264, as
    >claimed. But, they are also 10-20x slower. That’s not good! If you normalize for equal CPU usage, you’ll
    > notice that (again looking at the x264 point at 0%, 0.61 sec/frame), if you look at intersected points of the
    > red line (libvpx) vertically above it, the bitrate improvement normalized for CPU usage is only 20-30%. For
    > x265, it’s only 10%.

     

  • 1.4, Аноним (-), 12:22, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Почему есть x264, но нет vp8? Я понимаю почему нет Theora - утвердежния о том, что он - конкурент h264, были преувеличены. Но почему нет vp8, если он хороший? Получается что конкурент x264 - vp9?
     
     
  • 2.13, Аноним (-), 18:00, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты путаешь сладкое с мокрым. x264 - кодировщик, а vp9/vp8 - кодеки.
     
  • 2.17, dimqua (ok), 19:57, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    VP8 не получил такой популярности, как H264. Ему на смену пришёл VP9, а H264 ещё очень долго будет в ходу.
     

  • 1.6, marks (?), 12:56, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ubuntu 12 на скриншотах? О_о
     
     
  • 2.9, Аноним (-), 13:36, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Привет, Карл, тебя что-то часто стали упоминать всуе всякие умственно отсталые в интернетах.
     
  • 2.19, Zenitur (ok), 20:41, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну точно не 12.10
     
     
  • 3.24, marks (?), 00:41, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну логично, что это был 12.04. Только странно, что у серьезного назработчика как у начинающего блоггера название.
     

  • 1.7, Гений (??), 13:27, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Ну, да. Золотое правило механики и законы сохранения энергии еще никто не отменял. А, что, программисты только сегодня о них узнали? сочувствую, можно лишь увеличить расход энергии или исправить узкие места в конструкции, но когда больше нечего исправлять все потуги бесполезны.
     
  • 1.11, Аноним (-), 16:52, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >>Декодер libvpx-vp9 не поддерживает многопоточность

    Заканчивался 2015й год...

     
     
  • 2.12, Аноним (-), 17:44, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Поддерживает он. Это автор новости не умеет переводить. Там же ясно сказано, что tile-columns выключен, а без него параллельное декодирование у libvpx-vp9 не работает.

    Я уже не говорю про «Самым быстрым декодировщиком является ffvp9». Даже в тексте поста указано, что ffh264 скейлится намного лучше по ядрам. И нигде не указано, что Рональд является одним из разработчиков VP9 и работал в Гугле при его создании. И что оценивалось-то всего одно видео, что не даёт право считать сравнение хоть сколько-то объективным.

    В общем, типичный для опеннета фиговый перевод новости с хакерньюз на скорую руку без вникания в суть. Читайте оригинал и смотрите видео с VDD если хотите получить нормальную информацию, а не огрызок.

     
     
  • 3.14, Аноним (-), 18:31, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Я уже не говорю про «Самым быстрым декодировщиком является ffvp9».

    В выводах ровно об этом и написано "ffvp9 is an incredibly awesome decoder that outperforms all other decoders."

    > нигде не указано, что Рональд является одним из разработчиков VP9 и
    > работал в Гугле при его создании. И что оценивалось-то всего одно
    > видео, что не даёт право считать сравнение хоть сколько-то объективным.

    Это уже интересно.


     
     
  • 4.15, Аноним (-), 18:42, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >В выводах ровно об этом и написано

    Ну так это он приукрасил (Рональд главный автор ffvp9). На одном ядре чуть лучше ffh264, но кто сейчас использует одноядерное декодирование?

    Впрочем, ffvp9 действительно очень хорош. В лису бы его теперь. А в хроме, как оказалось, ffmpeg только для VP8 по умолчанию используется, а для VP8 с альфа-каналом и VP9 — libvpx.

     
     
  • 5.18, dimqua (ok), 20:01, 28/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > а для VP8 с альфа-каналом и VP9 — libvpx.

    Ну и хорошо, нет?

     

  • 1.23, абвгдейка (ok), 19:42, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Кодеки нового поколения x265 и libvpx на 50% более эффективно используют битрейт

    интересно, как у них dB перешли в 50% :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру