The OpenNET Project / Index page

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

Альтернативная реализация декодера VP8 обогнала по производительности код Google

25.07.2010 13:51

Разработчик проекта x264, ранее опубликовавший критическую статью, в которой был проведен анализ недостатков открытого компанией Google видеокодека VP8, представил обзор текущего состояния альтернативной свободной реализации декодера VP8 - ffvp8, подготовленной в рамках совместной работы участников проектов FFmpeg и x264. Тестирование производительности показало заметное преимущество кода ffvp8, способного выдать на современных процессорах примерно на 30% больше кадров в секунду при показе видео с разрешением 1080p.

Небольшой отрыв в скорости на процессорах Atom объясняется тем, что разработчики ffvp8 еще не приступили к оптимизации производительности для этого вида процессоров. Несмотря на то, что за месяц после выхода первого рабочего прототипа процесс оптимизации ffvp8 существенно продвинулся вперед, разработка еще остается экспериментальной. Благодаря использованию многих типовых функций, используемых в других декодерах пакета FFmpeg и уже неплохо оптимизированных, код декодера ffvp8 получился достаточно компактным (в пять раз меньше строк кода, чем в эталонном декодере libvpx). Загрузить тестовую версию декодера ffvp8 можно из SVN-репозитория проекта FFmpeg.

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

Из оптимизаций, которые помогли добиться высокой производительности, отмечается проведение работы по увеличению попадания данных в кэш процессора (используется метод умной предварительной загрузки данных из ключевых кадров, обращение к которым наиболее вероятно после обработки текущего кадра) и активное использование ассемблерных оптимизаций с задействованием SIMD-расширений современных процессоров (MMX, SSE, 3DNow), особенно в таких сильно нагружающих CPU задачах, как компенсация движения и фильтр деблокирования. В настоящий момент оптимизация проведена пока только для процессоров x86, поддержка архитектуры ARM остается в планах на будущее.

Также была проведена работа по уменьшению числа распаковки цифровых значений с разной степенью точности (8-битовых в 16-битовые переменные). Например, возьмём операцию abs(a-b) (модуль разности), где a и b - это 8-битные без-знаковые целые числа. Результат вычисления "a - b" требует для своего хранения в памяти 9-бит, так как может быть в промежутке от -255 до 255. Т.е. требуется привлечение дополнительного девятого знакового бита, чего можно избежать используя в условиях конструкцию вида (satsub(a,b) | satsub(b,a)), которая требует всего 4 ассемблерных команд вместо минимум 10 при использовании распаковки.

  1. Главная ссылка к новости (http://x264dev.multimedia.cx/?...)
  2. OpenNews: Сравнение работы кодировщиков VP8, x264 и XviD
  3. OpenNews: Разработчики FFmpeg написали собственный декодер для видеокодека VP8
  4. OpenNews: Релиз FFmpeg 0.6 и успехи в оптимизации видеокодека VP8
  5. OpenNews: Компания Google внесла изменения в лицензию на видеокодек VP8
  6. OpenNews: Компания Google перевела видеокодек VP8 в разряд свободных технологий
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/27425-vp8
Ключевые слова: vp8, video, codec
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (44) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, vix (?), 14:55, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    во жгут ребята..
    респект..
     
  • 1.2, 666joy666 (ok), 15:04, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Суровые мужики показали как нужно работать:)
     
  • 1.3, EuPhobos (ok), 15:40, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Гыы, Мак при более мощьном проце, выдаёт более низкие показатели) Что очередной раз подтверждает уже и без того, подтверждённую теорию "платно - не значит качественно".
     
     
  • 2.9, Andrew (??), 18:43, 25/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Где Вы это увидели?
     
     
  • 3.10, EuPhobos (ok), 18:55, 25/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Как бы, на диаграме, которая красуется наверху, в этой новости.
     
     
  • 4.11, Anonim (?), 19:35, 25/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Как бы на диаграмме C2D под макосью обошел более крутой i7.
    i5 - камень как бы тоже другого уровня.
     
     
  • 5.33, User294 (ok), 12:25, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > i5 - камень как бы тоже другого уровня.

    А вон там рядом с атомом уж не мак ли? И производительность почти как у атома несмотря на кор :). Еще напрашивается вывод что интел конкурирует сам с собой. Или какого фига i5 натягивает с аццким отрывом i7? Сие как-то не дружит с позиционированием интеля что выводок i5 - это такой удешевленный i7 :)

     
     
  • 6.36, Filosof (ok), 13:05, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Оптимизация ещё в работе" как бы намекает, что где-то не эффективно используется распаралеливание (и7 имеет меньше частоту, хоть и болше ядер/потоков) и кеш.
     
  • 6.39, Crazy Alex (??), 13:19, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В данном случае у i7 частота в полтора раза меньше, так что неудивительно.Впрочем, что интел в линейки процов заигрался - согласен.
     
  • 6.41, Аноним (-), 14:05, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А на индекс посмотреть, не? QM. Это мобильный. У него занижена частота, может ещё что-то не то, см. спеки.
     
     
  • 7.42, Andrey Mitrofanov (?), 14:06, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А на индекс посмотреть, не? QM. Это мобильный.

    Это на две буквы больше, чем нужно пользователю АМД. :->

     
     
  • 8.49, User294 (ok), 19:56, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по чертыханиям в коментах на сайте x264dev - я не один такой кто не понимае... текст свёрнут, показать
     
  • 7.45, Anonim (?), 15:34, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Если смотреть на индекс, то такого процессора вобще не существует :)
    Вот все мобильные камни http://ark.intel.com/ProductCollection.aspx?familyID=43402&MarketSegment=MBL
    Процессора с индексом 620QM там нет. Поиск по сайту ничего не дал.
    Чего там ребята тестировали – хз
     
     
  • 8.47, Anonim (?), 18:19, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Тестировали на i7-720QM с включенным турборежимом http x264dev multimedia cx ... текст свёрнут, показать
     
  • 7.48, User294 (ok), 19:36, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > У него занижена частота, может ещё что-то не то, см. спеки.

    А теперь попробуйте объяснить юзерам что "вон тот i7 - это, дескать, карманный вариант героя, поэтому он дескать проигрывает даже удешевленной версии героя" :).Удачи в этом начинании.

     
  • 6.44, Anonim (?), 15:20, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>>А вон там рядом с атомом уж не мак ли? И производительность почти как у атома несмотря на кор :)

    Ну и что? Рядом тоже мак и производительность на уровне. Сейчас это ни о чем не говорит.
    По диаграммам я вижу только одно – слабая оптимизация кодека. Причем ощущение, что оптимизировали на одной-двух железяках с расчетом, что этого хватит на весь спектр процессоров.

    >>>Еще напрашивается вывод что интел конкурирует сам с собой.

    Так и есть. Особенно это видно в нижнем сегменте.

     
  • 2.34, rfcr (ok), 12:25, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На самом деле скорей всего никто не ждет качества от платных продуктов (точнее его ждут от всех стабильных продуктов). От платных продуктов скорее ждут ответственности. Обычно эта ответственность оплачивается деньгами и закрепляется юридически - договором.

    В бесплатных продуктах от ответственности могут отказываться. Так что ИМХО теорию "платно - не значит качественно" подтверждать и не надо.

     
     
  • 3.37, Filosof (ok), 13:10, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >На самом деле скорей всего никто не ждет качества от платных продуктов
    >(точнее его ждут от всех стабильных продуктов). От платных продуктов скорее
    >ждут ответственности. Обычно эта ответственность оплачивается деньгами и закрепляется юридически -
    >договором.
    >
    >В бесплатных продуктах от ответственности могут отказываться. Так что ИМХО теорию "платно
    >- не значит качественно" подтверждать и не надо.

    Хмм... Если что-то не так работает в платном продукте, это не значит, что производитель обязуется это исправлять. Кроме слуечаев, если у Вас прямые крупные договора (как у МС и ХП). А их можно пересчитать по пальцам (ну ноги, возможно, понадобятся).
    В остальном уровень ответственности у бесплатных продуктов порой выше, ввиду, зачастую, более прозрачной возможности общения с разработчиком(упрощённый бюрократический аппарат).

     
  • 3.43, MiG (?), 14:44, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Так в юзерской лицензии того же микрософта написано, что компания не несёт ответственности за любой ущерб, причинённый софтом. Более того, не гарантирует что работа софта соответствует ожиданиям пользователя. Хоть эти самые ожидания и возникают в процессе чтения рекламы. ;-)

    Уж не такой ли ответственности ждут от проприетарного софта?

    Возьмите тот же Ред Хат: софт свободный (качай бесплатно с оф. сайта), договор - на обслуживание. Юридическая ответственность за поддержку есть, с софтом делай что хочешь (в рамках GPL). По-моему схемка гораздо приятнее.

     
     
  • 4.46, EuPhobos (ok), 16:49, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я это с самого начала и имел ввиду) Что приятнее пользоваться свободным ПО, а поддержку если надо - прикупить. Чем купить ПО, неизвестно какие баги в нём встретишь, неизвестно как их исправлять или писать подробный отчёт о них, и неизвестно вообще через сколько лет обновят его с исправлением. Потом тупо несёшь все балванки с платным ПО в мусорный ящик) ну или rm -rf

    Я тут не конкретно о Яблочниках или М$-дае говорю, а вообще в целом. Это относится и к платным и закрытым движкам/cms сайтов, и о платной и закрытой телефонной платформе, и о всяких прошивках к мобильным устройствам, и причём всё, что делается на базе открытого ПО, закрывается и продаётся - в некачественном виде.

    PS перечислил то, с чем мне приходилось сталкиваться и на что плеваться %)

     

  • 1.4, анон (?), 15:55, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Dark Shikari респект
     
  • 1.5, Аноним (-), 16:13, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хорошее дело делают люди
     
  • 1.6, KERNEL_PANIC (ok), 17:32, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Всегда их уважал, и теперь они не разочаровали!
     
  • 1.7, Skipper_gmr (?), 17:46, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот это правильно.
     
  • 1.8, Arcturus (ok), 17:46, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так и должно быть: открытая спецификация и свободные реализации.
     
     
  • 2.16, аноним (?), 22:59, 25/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Так и должно быть: открытая спецификация и свободные реализации.

    ага ага ознакомься с сабжем
    открытая спецификация не совпадает (!) с референсным кодеком
    гугл-вей

     
     
  • 3.40, Crazy Alex (??), 13:22, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Так и должно быть: открытая спецификация и свободные реализации.
    >
    >ага ага ознакомься с сабжем
    >открытая спецификация не совпадает (!) с референсным кодеком
    >гугл-вей

    Ну, тут на гугл валить не стоит. Явно это не их вина, а еще On2. А гугл поступил как праз правильно - в максимально короткие сроки выкатил WebM - хоть какой, но есть. И теперь параллельно идут его допиливание и встраивание в браузеры. Иначе все дружно жрали бы h264.

     
     
  • 4.50, аноним (?), 21:26, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну, тут на гугл валить не стоит

    Откуда столько любви к этой мерзкой конторке?

    >Явно это не их вина, а еще On2

    On2 практически нет, а "спецификацию" гугель обубликовал спустя многие месяцы после покупки. Запрет исправления багов!!!! - сугубо их вина.

    >А гугл поступил как праз правильно - в максимально короткие сроки выкатил WebM

    И кому он нужен, простите, этот ваш webm? Все как юзали h.264 и xvid, так и юзают.

     
     
  • 5.52, ЬЫР (?), 00:38, 28/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    И кому он нужен, простите, этот ваш firefox? Все как юзали IE, так и юзают.
     
     
  • 6.53, аноним (?), 06:38, 28/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >И кому он нужен, простите, этот ваш firefox?

    Пропал бы он завтра - даже не заметили бы. Опера рулит, а хром подруливает.

     

  • 1.12, Аноним (-), 20:49, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Например, когда результат "a-b", где переменные "a" и "b" могут попадать в
    > диапазон от -255 до +255, является отрицательным, требуется привлечение
    > дополнительного девятого знакового бита

    Мне кажется, или здесь действительно ошибка ? Если а и б в указанных пределах то они и так уже 9 битовые.

     
     
  • 2.13, Lain_13 (?), 21:37, 25/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Перевод, как обычно, жжот.
    > A simple example in the case of x86 is abs(a-b), where a and b are 8-bit unsigned integers.  The result of “a-b” requires a 9-bit signed integer (it can be anywhere from -255 to 255), so it can’t fit in 8-bit.

    Простой пример в случае для архитектуры x86: abs(a-b), где a и b это 8-битные без-знаковые целые значения. Результат вычисления "a-b" требует 9-битное число со знаком (может быть на промежутке от -255 до 255) и таким образом не может вместиться в 8 бит.

    Т.е. значения a и b попадают в диапазон от 0 до 255, а вот их разница...

     
     
  • 3.51, pavlinux (ok), 00:27, 27/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    0 - 255, Сколько будет?

    Правильно -  11111111 + знаковый бит.


     
  • 2.14, Lain_13 (?), 21:46, 25/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кстати, там ещё рассказывается про операцию satsub, которая здесь лишь указана. Она возвращает разницу если она положительна и 0 если разница отрицательна. После вычисления a-b и b-a для значений выполняется операция or (или), которая и возвращает не нулевое значение если оно там есть.
     

  • 1.15, FPGA (ok), 22:46, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Не видно результатов для процессоров AMD.
     
     
  • 2.21, universite (ok), 01:20, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • –6 +/

    Троллям советую аргументировать свои претензии к АМД, а не голословно высказываться.
     
  • 2.38, Filosof (ok), 13:13, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Не видно результатов для процессоров AMD.

    не помешали б, но для определения динамики и этого достаточно. Они ж сравнивают не производительность процов, а разницу в работе кодеков.

     

  • 1.26, StrangeAttractor (ok), 07:35, 26/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На самом деле всё вообще  может быть гораздо быстрее чем оно есть. Я в этом окончательно уверился увидев как на моей системе (старенький ноут с видео Intel 82852/82855, которая даже ни про какие шейдеры ничего не знает) летает Enlightenment e17 со всеми эффектами и, самое чудесное,  как на ней играется видео командой "mplayer -vo x11 %F"- наприемер при проигрывании FLV (проигрывание которого в браузере "как положено" жрёт 100% CPU) проц (при полностью софтовом декодировании и воспроизведении) загружен всего на 4% и при этом, внимание!, даже к самому видео без всякой запинки применяются эффекты композиции (прозрачность) в любых наслоениях!
     
     
  • 2.29, FractalizeR (ok), 10:31, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы о чем сейчас? "Реклама моего домашнего компа"?
     
     
  • 3.30, StrangeAttractor (ok), 11:36, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Это вы о чем сейчас? "Реклама моего домашнего компа"?

    Основная мысль какбы в первом предложении, а дальше иллюстрация.

     
     
  • 4.31, vi (?), 11:43, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Это вы о чем сейчас? "Реклама моего домашнего компа"?
    >
    >Основная мысль какбы в первом предложении, а дальше иллюстрация.

    +1 и 100500

     
  • 4.32, FractalizeR (ok), 12:13, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >На самом деле всё вообще  может быть гораздо быстрее чем оно есть

    Мысль философская, ничего не скажешь.

     
  • 2.35, User294 (ok), 12:36, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >самое чудесное,  как на ней играется видео командой "mplayer -vo x11 %F"-

    Посмотрите сколько % проца при этом кушает только вывод на экран. А если HD подсунуть? Половина проца уйдет на чисто вывод видео на экран :). Посему вас думается еще ждут сюрпризы по обнаружению того что это не предел и с акселерированным выводом видео можно еще больше :)

    >наприемер при проигрывании FLV (проигрывание которого в браузере "как
    >положено" жрёт 100% CPU) проц (при полностью софтовом декодировании и воспроизведении)

    У флеша удивительно тормозной вывод видео на экран. Связано сие с тем что как я понимаю, вывод декодера должен комбинироваться с картинкой нагенеренной остальным флешом. Ессно сие аццки тормозит.

    >загружен всего на 4%

    Наверное это был мувик 320х240 на интернетовском битрейте. Такое извините даже дохлый ARM на 400МГц декодирует...

    >и при этом, внимание!

    Какой восторг. Человек только что обнаружил что флеш - тормозилово :)

     
     
  • 3.54, StrangeAttractor (ok), 05:49, 29/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >У флеша удивительно тормозной вывод видео на экран. Связано сие с тем
    >что как я понимаю, вывод декодера должен комбинироваться с картинкой нагенеренной
    >остальным флешом. Ессно сие аццки тормозит.

    В этом и прикол, от это меня и поразило, что если включить прозрачность, сквозь играющееся в mplayer видео видно то, что под ним. Причём можно открыть насколько mplayer-ов и расположить друг над другом, и видео в них будет играться и комбинироваться. И при этом нагрузка на проц копеечная. А если смотреть тот же видеоклип в браузере, то нагрузка на проц 100%.

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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