LINUX.ORG.RU

Самый быстрый декодер VP8: ffvp8

 ,


0

0

Ранее уже была новость про разработку собственного декодера VP8 для FFmpeg. Но на тот момент это была достаточно сырая версия, чтобы говорить о каких-то конкретных результатах и тестировании. Теперь, после завершения первоначального этапа оптимизации, один из основных разработчиков x264 — Jason Garrett-Glaser — представил публике первые результаты тестирования нового декодера. И, надо сказать, они действительно впечатляют:

  • абсолютно во всех тестах ffvp8 оказался быстрее libvpx от Google;
  • в некоторых тестах ffvp8 превзошёл конкурента более чем в 1.5 раза;
  • больше всего преимущество ffvp8 было заметно на 64-битных платформах, на 32-битных платформах преимущество существенно заметно лишь на платформе Windows.

Для тестирования использовались два видеоклипа (Parkjoy и Sintel) с качеством HD 1080p. Команда, при помощи которой проводилось тестирование: time ffmpeg -vcodec {libvpx or vp8} -i input -vsync 0 -an -f null. Была взята последняя версия FFmpeg из SVN. Ниже представлены результаты (в кадрах в секунду) для платформы Linux, результаты для платформ Mac OS X и Windows можно найти по ссылке.

Core i5 520M (2.4Ghz), Linux, 64-bit:

  • Parkjoy ffvp8: 68.29 +/- 0.06
  • Parkjoy libvpx: 41.06 +/- 0.04
  • Sintel ffvp8: 112.38 +/- 0.37
  • Sintel libvpx: 69.64 +/- 0.09

Atom N270 (1.6Ghz), Linux, 32-bit:

  • Parkjoy ffvp8: 15.29 +/- 0.01
  • Parkjoy libvpx: 12.46 +/- 0.01
  • Sintel ffvp8: 26.87 +/- 0.05
  • Sintel libvpx: 20.41 +/- 0.02

Также по ссылке можно прочитать рассказ разработчика о том, как проводилась разработка декодера, и за счёт чего ffvp8 оказался таким быстрым.

>>> Подробности

★★★★

Проверено: JB ()
Последнее исправление: JB (всего исправлений: 1)
Ответ на: комментарий от anon_666

Ты можешь 1.5 заменить на «полтора» и смысл не поменяется. Цифры нагляднее.

MuZHiK-2 ★★★★
() автор топика

поздравления разработчикам! хорошие результаты

maxt
()

Dark Shikari - мужик!

wxw ★★★★★
()
Ответ на: комментарий от anon_666

>>ffvp8 превзошёл ... в 1.5 раза;

1.5 раза


Fail.


Учимся читать.
В одну целую пять десятых раза.
В полтора раза.

anonymous
()

> абсолютно во всех тестах ffvp8 оказался быстрее libvpx от Google

всегда знал, что в Google нет хороших системных программистов

northerner ★★★
()
Ответ на: комментарий от upcFrost

1080p
Чему удивляться?
720p нетбук тянет, а вот 1080p в любом кодеке никак, если нет vdpau.

CyberTribe ★★
()
Ответ на: комментарий от anonymous

Учимся читать.

В одну целую пять десятых раза. В полтора раза.

Где разница? О_о

Тогда вопрос: что больше/равно: 0.99(9) или 1.0

Zodd ★★★★★
()
Ответ на: комментарий от northerner

>>всегда знал, что в Google нет хороших системных программистов

Вообще, скорее всего, этот код писал не гугл, а просто взяли то, что досталось от O2n и зарелизили.

MuZHiK-2 ★★★★
() автор топика

Если тестирование достоверно, то результат безусловно хорош.

twosev ★★
()

позитивно. Правда, на всего 2х роликах тестировать некорректно

dotbg ★★★★
()

> после завершения первоначального этапа оптимизации

Нормально - «next step was adding SIMD assembly»

Они походу только начали, и уже результат, совсем неплохой.

Ilshat
()

Это радует (: ffmpeg офигенен.

pevzi ★★★★★
()
Ответ на: комментарий от pevzi

>>Согласен, даже как-то не по-мужски.

Было нормально, но JB срезал.

MuZHiK-2 ★★★★
() автор топика

ffvp8 — доказательство, что Dark Shikari is tsundere for VP8.

anonymous
()

Ожидаемо, на самом деле.

Gukl ★★★
()
Ответ на: комментарий от northerner

VP8 делал не гугл а какая то другая контора, которую гугл купил.

Legioner ★★★★★
()
Ответ на: комментарий от anon_666

> ...Now, with the [b]first round[/b] of optimizations complete... ...Теперь, когда [b]первый цикл[/b] оптимизации завершен...

1,5? Чё, нормально для первого цикла.

anonymous
()
Ответ на: комментарий от NightOperator

>0.99(9) = 0.99 * (9) = 0.99 * 9 = 8.91

Такое ощущение, что нас с тобой разным видам математики учили.

Ttt ☆☆☆☆☆
()

Чтобы не смущать троллей, тесты на одинаковых процессорах и разных ОС не проводились?

KPSS
()

Гугле предоставил исходник, суровые мужики показали как нужно работать. У всех счастье

paran0id ★★★★★
()

Кто-то еще будет утверждать, что все сообщество FOSS состоит из криворуких школьников?

unikoid ★★★
()

1> на 32-битных платформах преимущество существенно заметно лишь на платформе Windows.

Почему это на винде вдруг быстрее?

d1337r
()
Ответ на: комментарий от d1337r

>Почему это на винде вдруг быстрее?

На винде гугло-кодег кривее

anonymous
()
Ответ на: комментарий от d1337r

>>на 32-битных платформах преимущество существенно заметно лишь на платформе Windows.

Почему это на винде вдруг быстрее?

Потому что у разработчиков не было машины с нормальным процессором и 32-битным линуксом на борту. Атом не является нормальным процессором и требуют особых оптимизаций из-за того, что он не поддерживает out of order execution. Тестировать же 64-битный ffmpeg на винде нельзя из-за вот этого бага: http://roundup.ffmpeg.org/issue1889.

anonymous
()

Новость, безусловно, радует!

helios ★★★★★
()
Ответ на: комментарий от AVL2

>этож хабрадолбоеп. Там нормальных не бывает...

Им всем захавал мозг Мицгол. А может быть это даже он тут под анонимусом является

goingUp ★★★★★
()

Почему нельзя было протестировать все ос на одном железе? А так графики про ос ниочем, ясно только что ffvp8 быстрее.

anonymous
()
Ответ на: комментарий от anonymous

>Почему нельзя было протестировать все ос на одном железе? А так графики про ос ниочем, ясно только что ffvp8 быстрее.

Потому что тестировали ни OS'ы, а декодеры на разных процессорах. Графики с разных OS лишь показывают, что результаты повторяемы между разными платформами.

anonymous
()
Ответ на: комментарий от anonymous

Пока что ясно другое:
1) гогель вывалил на публику кучу дерьма
2) эта куча дерьма плохо документирована (ещё бы, чтож там документировать-то в дерьме)
3) документация не совпадает (OH SHI-) с эталонной реализацией
4) выявленные ошибки полагается считать частью спецификации
5) даже после серии оптимизаций, проведенных признанными высококлассными специалистами, декодер конкретно сливает прямому - как всех старательно убеждают маркетолухи - конкуренту.

wxw ★★★★★
()
Ответ на: комментарий от anonymous

> Почему нельзя было протестировать все ос на одном железе? А так графики про ос ниочем, ясно только что ffvp8 быстрее.

тыг йопт! придётся:

1. либо на одно и тож железо ставить одновременно/попеременно ставить разные операционные системы

2. либо гдето доставать одинаковые аппаратные конфигурации конфигурации компьютеров..

--------------------

по поводу пункта [2] тут конешно вся ясно.

а что касается пункта [1] — то — ну вот предположим у меня на компе жёсткий диск с GPL-разметкой жосткого диска (а не разметкой MSDOS, так как нафиг мне эта MSDOS сдалась?!). и как теперь поставить Windows(?)... всё к чортовой бабушке удалять с HDD и переразмечать под MSDOS ?

и вообще — существует большенство людей — которые сначало пкупают Hardware, а потом думают о том «какую бы операционную систему и программы сюда можно поставить?»
...и сущесвует меньшее количество людей — которые при покупке Hardware заранее подбирают железо именно под нужное программное обеспечение :-) :-) ... ...вобщем чо я объясняю — наверно все это и так понимают.. :-)

mkfifo
()
Ответ на: комментарий от mkfifo

>ну вот предположим у меня на компе жёсткий диск с GPL-разметкой жосткого диска (а не разметкой MSDOS, так как нафиг мне эта MSDOS сдалась?!).

Могли бы подключить несколько дисков, или это уже проблема?

и как теперь поставить Windows(?)... всё к чортовой бабушке удалять с HDD и переразмечать под MSDOS ?

Я почти так и делал, только данные на другой винт перекидывал. Диски был в gpl а потом ВНЕЗАПНО пришлось работать с оффтопиком, которая отказалась ставится . Ну а что поделать?

anonymous
()
Ответ на: комментарий от ptah_alexs

>Make me unsee it.

Да все норм. ну записали парни после MBR текст GPL.

rave
()
Ответ на: комментарий от ptah_alexs

после темы обсуждения лицензий WordPress и WordPressШаблонов — мой моторный мозг уже квадратит и он букву "..L" — сам печатает, после «GP..» :DDDDDDDDDD

mkfifo
()
Ответ на: комментарий от upcFrost

> 12-15 кадров на атоме? Не хотет, мой нетбук мне еще нужен

12-15 кадров на 1080p. Сомневаюсь, что для нетбуков актуален такой формат. :)

cruxish ★★★★
()
Ответ на: комментарий от cruxish

Под «форматом», естественно, подразумевается формат кадра. :)

cruxish ★★★★
()
Ответ на: комментарий от cruxish

>12-15 кадров на 1080p. Сомневаюсь, что для нетбуков актуален такой формат

Вероятно, не так уж сложно догадатся, что от скорости декодирования зависит как минимум расход батарейки.

wxw ★★★★★
()

Классная новость. С утречка заряд бодрости)).

Chu
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.