Рональд Бултье (Ronald S. Bultje), принимающий участие в разработке FFmpeg, провёл (https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecod.../) исследование производительности и качества работы кодировщиков и декодировщиков для видеоформатов VP9, HEVC и H.264. В тестах приняли участие поддерживаемые в FFmpeg кодировщики libvpx (http://www.webmproject.org/code/), x265 (http://x265.org/) и x264 (http://www.videolan.org/developers/x264.html), и декодировщики openHEVC (https://github.com/OpenHEVC/openHEVC), ffh264, ffvp9, ffhevc.Основные выводы:
- Кодеки нового поколения x265 и libvpx на 50% более эффективно используют битрейт по сравнению с x264, но работают в 10-20 раз медленнее;<center><a href="https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-... src="https://www.opennet.ru/opennews/pics_base/0_1443423831.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
- Рассчитанный на эффективное использование CPU кодек libvpx близок по производительности к x264 на сопоставимых битрейтах. x265 работает слишком медленно в большинстве практических применений, за исключением high-end сценариев;
<center><a href="https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-... src="https://www.opennet.ru/opennews/pics_base/0_1443423801.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
- Самым быстрым декодировщиком является ffvp9;
<center><a href="https://blogs.gnome.org/rbultje/files/2015/09/ffmpeg-libvpx-... src="https://www.opennet.ru/opennews/pics_base/0_1443424245.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
- На многоядерных системах декодирование в многопоточном режиме даёт заметный выигрыш. Декодер libvpx-vp9 не поддерживает многопоточность;
<center><a href="https://blogs.gnome.org/rbultje/files/2015/09/ffmpeg-libvpx-... src="https://www.opennet.ru/opennews/pics_base/0_1443424289.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
URL: https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecod.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=43052
Важно понимать, что в тех же мобильных телефонах картина может быть совсем другой, так как там используются аппаратные декодеры, а не CPU. И сравнивать нужно на конкретном SoC'е, так как разные производители по-разному их делают.
в них используются те же самые декодеры, что и в писюках. И это ни разу не CPU. И, разумеется, ни разу не кодовая база vanilla ffmpeg, который вообще чем дальше тем больше становится бесполезной поделкой и враппером для чужих библиотек.
Но используются они - только и исключительно для mp4/vp8 (может уже и 9, но я в этом не уверен), потому что только для них есть готовый код, который так легко воровать.А для h265 ничего пока, насколько я понимаю, нет, одни proof-of-concept поделки.
Но тут речь о другом - сравнении на одинаковом железе, чтобы понять, в какой кодек вообще осмысленно вкладывать усилия, а на какой можно уже и забить. Понятно что метода - сомнительная, никто именно эти библиотеки as-is использовать никогда не станет, к тому же используется синтетический тест, а не визуальная оценка (мы ведь глазами это собираемся смотреть, а не измерительной аппаратурой). Но хоть что-то.
> А для h265 ничего пока, насколько я понимаю, нет, одни proof-of-concept поделки.Orange Pi 2 есть, как минимум. Или не о железе речь?
не о железе, а о поддержке железа декодерами (не говоря уж о энкодерах, каковые у нас строго mp4). Конкретно ffmpeg'овыми, потому что никаких других общедоступных (я даже не об opensource, а о том что в принципе может быть куплено за деньги) один хрен нет.
Если бы на моем домашнем десктопе видео декодировал процессор - я бы кроме слайдшоу ничерта бы не видел.
А теперь посмотрим, как у h265-х образчиков с vaapi/vdpau и поплачем...У телефонов в этом плане ровно все то же самое что у "больших".
Так nvidia с VDPAU Set F (GTX 950, 960) + свежий ffmpeg = и увсё будет
у меня вот есть основания полагать, что h265 - не будет.
Наверное, будет vp9 через libvpx, но я не проверял - раньше не работало.
Мало того, в свободный AMD драйвер прикрутили http://www.phoronix.com/scan.php?page=news_item&px=VDPAU-HEV...
А об VP9 пока не чесались.
И декодеры, и кодеры. Как в авторегистраторе :-) Ждём на декстопах!
> Кодеки нового поколения ... libvpx ... по сравнению с x264 ... работают в 10-20 раз медленнее;
> Рассчитанный на эффективное использование CPU кодек libvpx близок по производительности к x264 на сопоставимых битрейтах.Нет ли здесь деления на 0?
>Нет ли здесь деления на 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%.
Почему есть x264, но нет vp8? Я понимаю почему нет Theora - утвердежния о том, что он - конкурент h264, были преувеличены. Но почему нет vp8, если он хороший? Получается что конкурент x264 - vp9?
Ты путаешь сладкое с мокрым. x264 - кодировщик, а vp9/vp8 - кодеки.
VP8 не получил такой популярности, как H264. Ему на смену пришёл VP9, а H264 ещё очень долго будет в ходу.
Ubuntu 12 на скриншотах? О_о
Привет, Карл, тебя что-то часто стали упоминать всуе всякие умственно отсталые в интернетах.
Ну точно не 12.10
Ну логично, что это был 12.04. Только странно, что у серьезного назработчика как у начинающего блоггера название.
Ну, да. Золотое правило механики и законы сохранения энергии еще никто не отменял. А, что, программисты только сегодня о них узнали? сочувствую, можно лишь увеличить расход энергии или исправить узкие места в конструкции, но когда больше нечего исправлять все потуги бесполезны.
>>Декодер libvpx-vp9 не поддерживает многопоточностьЗаканчивался 2015й год...
Поддерживает он. Это автор новости не умеет переводить. Там же ясно сказано, что tile-columns выключен, а без него параллельное декодирование у libvpx-vp9 не работает.Я уже не говорю про «Самым быстрым декодировщиком является ffvp9». Даже в тексте поста указано, что ffh264 скейлится намного лучше по ядрам. И нигде не указано, что Рональд является одним из разработчиков VP9 и работал в Гугле при его создании. И что оценивалось-то всего одно видео, что не даёт право считать сравнение хоть сколько-то объективным.
В общем, типичный для опеннета фиговый перевод новости с хакерньюз на скорую руку без вникания в суть. Читайте оригинал и смотрите видео с VDD если хотите получить нормальную информацию, а не огрызок.
> Я уже не говорю про «Самым быстрым декодировщиком является ffvp9».В выводах ровно об этом и написано "ffvp9 is an incredibly awesome decoder that outperforms all other decoders."
> нигде не указано, что Рональд является одним из разработчиков VP9 и
> работал в Гугле при его создании. И что оценивалось-то всего одно
> видео, что не даёт право считать сравнение хоть сколько-то объективным.Это уже интересно.
>В выводах ровно об этом и написаноНу так это он приукрасил (Рональд главный автор ffvp9). На одном ядре чуть лучше ffh264, но кто сейчас использует одноядерное декодирование?
Впрочем, ffvp9 действительно очень хорош. В лису бы его теперь. А в хроме, как оказалось, ffmpeg только для VP8 по умолчанию используется, а для VP8 с альфа-каналом и VP9 — libvpx.
> а для VP8 с альфа-каналом и VP9 — libvpx.Ну и хорошо, нет?
>Кодеки нового поколения x265 и libvpx на 50% более эффективно используют битрейтинтересно, как у них dB перешли в 50% :)
