The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Сравнение скорости кодирования и декодирования видео при пом..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от opennews on 28-Сен-15, 10:56 
Рональд Бултье (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.dev/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.dev/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.dev/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.dev/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.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=43052

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Сравнение скорости кодирования и декодирования видео при пом..."  +5 +/
Сообщение от IZh. on 28-Сен-15, 10:56 
Важно понимать, что в тех же мобильных телефонах картина может быть совсем другой, так как там используются аппаратные декодеры, а не CPU. И сравнивать нужно на конкретном SoC'е, так как разные производители по-разному их делают.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Сравнение скорости кодирования и декодирования видео при пом..."  –5 +/
Сообщение от . on 28-Сен-15, 11:49 
в них используются те же самые декодеры, что и в писюках. И это ни разу не CPU. И, разумеется, ни разу не кодовая база vanilla ffmpeg, который вообще чем дальше тем больше становится бесполезной поделкой и враппером для чужих библиотек.
Но используются они - только и исключительно для mp4/vp8 (может уже и 9, но я в этом не уверен), потому что только для них есть готовый код, который так легко воровать.

А для h265 ничего пока, насколько я понимаю, нет, одни proof-of-concept поделки.

Но тут речь о другом - сравнении на одинаковом железе, чтобы понять, в какой кодек вообще осмысленно вкладывать усилия, а на какой можно уже и забить. Понятно что метода - сомнительная, никто именно эти библиотеки as-is использовать никогда не станет, к тому же используется синтетический тест, а не визуальная оценка (мы ведь глазами это собираемся смотреть, а не измерительной аппаратурой). Но хоть что-то.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

16. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от dimqua (ok) on 28-Сен-15, 19:54 
> А для h265 ничего пока, насколько я понимаю, нет, одни proof-of-concept поделки.

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

20. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от пох on 28-Сен-15, 23:22 
не о железе, а о поддержке железа декодерами (не говоря уж о энкодерах, каковые у нас строго mp4). Конкретно ffmpeg'овыми, потому что никаких других общедоступных (я даже не об opensource, а о том что в принципе может быть куплено за деньги) один хрен нет.
Если бы на моем домашнем десктопе видео декодировал процессор - я бы кроме слайдшоу ничерта бы не видел.
А теперь посмотрим, как у h265-х образчиков с vaapi/vdpau и поплачем...

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

21. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от soarin (ok) on 29-Сен-15, 04:45 
Так  nvidia с VDPAU Set F (GTX 950, 960) + свежий ffmpeg = и увсё будет
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

22. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от . on 29-Сен-15, 12:16 
у меня вот есть основания полагать, что h265 - не будет.
Наверное, будет vp9 через libvpx, но я не проверял - раньше не работало.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

25. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от soarin (ok) on 30-Сен-15, 21:08 
Мало того, в свободный AMD драйвер прикрутили http://www.phoronix.com/scan.php?page=news_item&px=VDPAU-HEV...
А об VP9 пока не чесались.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

5. "Сравнение скорости кодирования и декодирования видео при пом..."  –1 +/
Сообщение от Аноним (??) on 28-Сен-15, 12:23 
И декодеры, и кодеры. Как в авторегистраторе :-) Ждём на декстопах!
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Сравнение скорости кодирования и декодирования видео при пом..."  +1 +/
Сообщение от Аноним (??) on 28-Сен-15, 11:03 
> Кодеки нового поколения ... libvpx ... по сравнению с x264 ... работают в 10-20 раз медленнее;
> Рассчитанный на эффективное использование CPU кодек libvpx близок по производительности к x264 на сопоставимых битрейтах.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Сравнение скорости кодирования и декодирования видео при пом..."  +2 +/
Сообщение от Аноним (??) on 28-Сен-15, 13:41 
>Нет ли здесь деления на 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%.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Сравнение скорости кодирования и декодирования видео при пом..."  –2 +/
Сообщение от Аноним (??) on 28-Сен-15, 12:22 
Почему есть x264, но нет vp8? Я понимаю почему нет Theora - утвердежния о том, что он - конкурент h264, были преувеличены. Но почему нет vp8, если он хороший? Получается что конкурент x264 - vp9?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Сравнение скорости кодирования и декодирования видео при пом..."  +1 +/
Сообщение от Аноним (??) on 28-Сен-15, 18:00 
Ты путаешь сладкое с мокрым. x264 - кодировщик, а vp9/vp8 - кодеки.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

17. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от dimqua (ok) on 28-Сен-15, 19:57 
VP8 не получил такой популярности, как H264. Ему на смену пришёл VP9, а H264 ещё очень долго будет в ходу.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от marks on 28-Сен-15, 12:56 
Ubuntu 12 на скриншотах? О_о
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Сравнение скорости кодирования и декодирования видео при пом..."  +4 +/
Сообщение от Аноним (??) on 28-Сен-15, 13:36 
Привет, Карл, тебя что-то часто стали упоминать всуе всякие умственно отсталые в интернетах.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

19. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от Zenitur (ok) on 28-Сен-15, 20:41 
Ну точно не 12.10
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

24. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от marks on 30-Сен-15, 00:41 
Ну логично, что это был 12.04. Только странно, что у серьезного назработчика как у начинающего блоггера название.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

7. "Сравнение скорости кодирования и декодирования видео при пом..."  –5 +/
Сообщение от Гений (??) on 28-Сен-15, 13:27 
Ну, да. Золотое правило механики и законы сохранения энергии еще никто не отменял. А, что, программисты только сегодня о них узнали? сочувствую, можно лишь увеличить расход энергии или исправить узкие места в конструкции, но когда больше нечего исправлять все потуги бесполезны.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Сравнение скорости кодирования и декодирования видео при пом..."  +1 +/
Сообщение от Аноним (??) on 28-Сен-15, 16:52 
>>Декодер libvpx-vp9 не поддерживает многопоточность

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Сравнение скорости кодирования и декодирования видео при пом..."  +3 +/
Сообщение от Аноним (??) on 28-Сен-15, 17:44 
Поддерживает он. Это автор новости не умеет переводить. Там же ясно сказано, что tile-columns выключен, а без него параллельное декодирование у libvpx-vp9 не работает.

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

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от Аноним (??) on 28-Сен-15, 18:31 
> Я уже не говорю про «Самым быстрым декодировщиком является ffvp9».

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

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

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


Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от Аноним (??) on 28-Сен-15, 18:42 
>В выводах ровно об этом и написано

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

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от dimqua (ok) on 28-Сен-15, 20:01 
> а для VP8 с альфа-каналом и VP9 — libvpx.

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

23. "Сравнение скорости кодирования и декодирования видео при пом..."  +/
Сообщение от абвгдейка (ok) on 29-Сен-15, 19:42 
>Кодеки нового поколения x265 и libvpx на 50% более эффективно используют битрейт

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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