LINUX.ORG.RU

Собственный декодер VP8 для FFmpeg

 , , , , ,


0

0

На днях, следуя принципу “несколько независимых реализаций помогают стандарту развиваться и становиться более полезным для пользователя", Роналд Балтье (Ronald Bultje) и другие разработчики FFmpeg написали собственный декодер VP8. Что это даст FFmpeg по сравнению с libvpx? Оказывается, много что:

  • один и тот же код (а самое главное, и оптимизации) можно использовать как для VP8, так и для декодеров предыдущих версий VPx (степень повторного использования кода для VP5/6 очень высока по сравнению с VP8). Благодаря этому, мультимедиа-плееры для телефонов и мобильных устройств можно сделать компактными и более быстрыми;
  • так как H.264 (в настоящее время - промышленный стандарт кодирования видео) и VP8 очень похожи, то можно использовать один и тот же код (и, конечно же, оптимизации) для реализации H.264 в FFmpeg и декодеров VP8. Опять же, это позволяет сделать мультимедиа-плееры более быстрыми и компактными;
  • так как собственные реализации VP3/Theora и декодеров Vorbis у FFmpeg более быстрые, чем аналоги (например, чем те, что поставляются Xiph в виде libvorbis/libtheora), то, и собственная реализация декодера VP8 также более быстрая, чем libvpx от Google (на данный момент есть оптимизации только для платформ x86 и PPC).

В итоге, у разработчиков FFmpeg получился декодер, который максимально полно старается использовать уже имеющийся код в компонентах FFmpeg. Новый декодер уместился всего лишь в 1400 строк кода в файле vp8.c (включая пробелы и пустые строки) и примерно 450 строк кода для функций обработки цифровых сигналов (собственно, сам математический аппарат, оптимизированный методом SIMD). Новый декодер обеспечивает полную бинарную совместимость на выходе с тем, что выдаёт libvpx для набора тестовых файлов. Для сравнения, декодер VP8 в реализации libvpx занимает порядка 10,000 строк кода (без оптимизаций), плюс более 1000 строк кода для реализации открытого API для доступа к декодеру.

Весьма интересны впечатления разработчиков после реализации VP8:

  • спецификации, предоставленные Google для VP8, не всегда помогали. Например, в спецификациях описан только базовый профиль, остальные же профили используют функции, которых нет в спецификациях, или описание которых неполное. Поэтому, зачастую, было проще читать исходный код libvpx, чем спецификации. Более того, спецификации являются ни чем иным, как копией исходных кодов декодера, поэтому, как спецификация, для профессионала она бесполезна;
  • libvpx полна ассемблерного кода, часть которого не переносится на другие платформы или вообще не используется, поэтому цель такого кода так и осталась неясной;
  • сейчас, когда VP8 уже выпущен, Google так и не выпустила спецификации на предыдущие стандарты VPx, например VP7.

Сейчас работа направлена на оптимизацию декодера, чтобы его производительность превосходила libvpx на различных устройствах (особенно мобильных).

>>> Патч для FFmpeg

★★★★

Проверено: JB ()

Ответ на: комментарий от Evtomax

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

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

>надо без потерь кодеки фотографий использовать.

Естественно, иначе такое сравнение видео-кодеков по скриншотам не стоит и ломанного гроша.

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

Тебе и там доплачивают?

Информация о пользователе Mystra_x64
Новости 0

Молодчик. Бзди дальше. Каждый должен заниматься тем, что у него лучше всего получается. Кто-то важные новости до широкой общественности доносить, а кто-то сцать кипятком в толксах про жоперу и дебиан в режиме 24/7 на протяжении 5 лет.

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

> Естественно, иначе такое сравнение видео-кодеков по скриншотам не стоит и ломанного гроша

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

А тут любой кодек дает ошибку больше, чем jpeg

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

> вообще имеено на этом и построены кодеки большей частью. они учитывают это при выборе информации, которую теряют

Они вроде учитывают только особенности восприятия статичной картинки. Приведу пример особенности восприятия динамической картинки: после светлых кадров глазу понадобится время, чтобы адаптироваться к тёмным, поэтому у тёмных кадров, идущих сразу после светлых, можно немного снизить качество.

Evtomax ()

По ссылке только патч, а откуда взялся весь текст новости? В смысле, пруфлинк есть, или это полностью авторская заметка?

На тему сравнения стандартов, вот тут разработчик x264 мощно высказался:

http://x264dev.multimedia.cx/?p=377 (вроде на LORе было?)

Вкратце, по его мнению VP8 - это недоношенный h264. А отличия объясняются лишь необходимостью избежать патентных исков от MPEG консорциума, да и то, есть подозрения, что отличий от h264 всё же слишком мало.

Интересно, что по поводу спецификаций он слово в слово повторяет текст заметки:

The spec consists largely of C code copy-pasted from the VP8 source code — up to and including TODOs, “optimizations”, and even C-specific hacks, such as workarounds for the undefined behavior of signed right shift on negative numbers. In many places it is simply outright opaque. Copy-pasted C code is not a spec.

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

> А отличия объясняются лишь необходимостью избежать патентных исков от MPEG консорциума, да и то, есть подозрения, что отличий от h264 всё же слишком мало.

Не думаю, что MPEG консоциум смог запатентовать идеи, до которых даже школьник может додуматься

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

>>Чем тест MSU не устраивает? Они тестируют кодеки уже не первый год и свое дело знают.

Там много непонятных простому пользователю цифр.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Evtomax

Нет. Они как раз учитывают смену картинок и сдвиги кадров. И особености человека. Пока достаточно мало учитывает, но стараются больше сделать

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

>>Что за принцип такой - «Несколько независимых реализаций помогают стандарту развиваться»? Типа конкуренция появится? Сейчас все начнут реализовывать и зоопарк декодеров не за горой.

Смысл в том, что разным людям требуется разная реализация в зависимости от назначения готового продукта.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Evtomax

> Не думаю, что MPEG консоциум смог запатентовать идеи, до которых даже школьник может додуматься

у них еще и не такое патентуют

namezys ★★★★ ()
Ответ на: комментарий от MuZHiK-2

> Желтуха на хабре бывает отменной.

Вполне неплохое сравнение для неспециалистов

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

>>Что означает фраза «включая пробелы»?

Я имею в виду пробелы больше одной пустой строки. То есть пробелы пустого места в коде. Под пустыми строками я понимаю пустую строку в коде, предназначенную для логического отделения блоков кода.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Evtomax

> Не думаю, что MPEG консоциум смог запатентовать идеи, до которых даже школьник может додуматься

Это какие конкретно идеи, до которых школьники додумываются?

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

>>По ссылке только патч, а откуда взялся весь текст новости? В смысле, пруфлинк есть, или это полностью авторская заметка?

Посмотри в блоге самого Роналда, он писал об этом.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от namezys

>>Вполне неплохое сравнение для неспециалистов

Лично для меня картинки выглядят одинаковыми. Я это к тому, что в движении эта разница вообще нивелируется.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от kmike

> Это какие конкретно идеи, до которых школьники додумываются?
Ссылки на другие кадры. До этого я додумался, когда был в 8-ом классе, разрабатывал одну прогу для KolibriOS и хотел написать простенький кодек для сжатия скринкастов.

Evtomax ()
Ответ на: комментарий от MuZHiK-2

ну он и написал, что разница почти незаметна было более полное сравнение у него. в общем vp8 проигрывает (а местами кодек просто глючит). и это не в максимально возможном качестве у h264

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

>тифки выкладывать имеет смысл

Никто не требует tiff, достаточно png. ;)

А тут любой кодек дает ошибку больше, чем jpeg

Дело не только в ошибке, PSNR/MSE давно не в моде. Современные энкодеры используют техники, которые _добавляют_ артефакты, чтобы сохранить сложность (complexity) у картинки. Это то, что называется psychovisual optimizations. И именно это при пережатии скриншотов lossy-методом теряется (либо добавляется лишнее).

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

Если бы там кодирование было бы хотя бы в разумно качестве - я бы понял возмущение

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

>Если бы там кодирование было бы хотя бы в разумно качестве - я бы понял возмущение

Проблема в том, что такие «мелочи» в итоги складываются и очень сильно влияют на общую картину и валидность результата.

Вот это однозначно релевантно: http://x264dev.multimedia.cx/?p=472 и http://x264dev.multimedia.cx/?p=458.

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

> Он на большее особо и не способен. Он не сильно проигрывает h264, но все же проигрывает. Тем более h264 (точнее MPEG не стоит на месте, и развивается), а vp8 все же доганяет только

...

http://habrahabr.ru/blogs/video/94394/


вот хотя бы


почему во всех этих сравненях — никто не дочитывает дофразы о том что разниццы не видно?

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

«В качестве окончательного вывода можно сказать, что H.264 всё-таки имеет преимущество и обеспечивает лучшее качество сжатия, но разница вряд ли будет заметна в большинстве ситуаций.»

namezys ★★★★ ()

А вот сравнение со свободными кодеками (x264 и Theora) c замером быстродействия. VP8 там самый медленный.

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

>>Новости 0

shahid ★★★★ (28.06.2010 11:51:22)


И у тебя ещё хватает наглости запрещать другим ковыряться в носу?

а кто-то сцать кипятком в толксах про жоперу и дебиан в режиме 24/7 на протяжении 5 лет.


Т.е. ты только что сейчас подтвердил, что за пределы толксов не выходишь. Самозабанься, если такой нежный.

Deleted ()
Ответ на: комментарий от MuZHiK-2

Всего лишь новость про ещё один велосипедный декодер (хотя может и нужный), а не про замахи.

Deleted ()

> как спецификация, для профессионала она бесполезна;

libvpx полна ассемблерного кода … цель такого кода так и осталась неясной;

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

Правильно делают, что переписывают декодер сами. Молодцы.

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

>>Всего лишь новость про ещё один велосипедный декодер (хотя может и нужный), а не про замахи.

Это «всего лишь» уже работает быстрее гугловской реализации, а на мобильных устройствах это еще важнее. А распространенность формата решает очень многое.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от ArtemZ

Она православна.

Аз есьм VP8 зело приискренне православен. АдминЪ.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от ArtemZ

>Пофиг, я собираюсь запилить тьюб, в котором всё видео будет в theora. Гугл пустьдальше пилит свои поделки

наверняка это будет «принципиально новый youtube»? :)

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

>http://habrahabr.ru/blogs/video/94394/

вот хотя бы


Ты хоть сам это читал, там по ссылке

В качестве окончательного вывода можно сказать, что H.264 всё-таки имеет преимущество и обеспечивает лучшее качество сжатия, но разница вряд ли будет заметна в большинстве ситуаций.


Тролли такие тролли

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

>почему во всех этих сравненях — никто не дочитывает дофразы о том что разниццы не видно?

Например потому, что 90% таких тестеров не знают, что делают и именно поэтому у них получаются похожие результаты?

Проблемы этого сравнения, заметные с первого взгляда:

1. Название. Называть статью «сравнение H.264 и VP8» можно только в случае если сравниваются технические спецификации и их возможности, либо если в статье представлены (почти) _ВСЕ_ энкодеры H.264 и VP8.

2. Не указаны конкретные настройки, использовавшиеся на обоих кодеках. Не указана методология выбора настроек.

3. Использован не самый лучший энкодер H.264.

4. Указано, что ядром энкодера H.264 является Mainconcept H.264, но не указана версия SDK.

5. Нет ссылки на оригинальный клип.

6. Нет скриншотов с исходника.

7. Не указано какими декодерами производилось декодирование.

8. Для скриншотов использован lossy-формат.

9. Не указано как выбирались кадры для сравнения. ( P/B/I кадры, расстояние от I-кадра. )

10. Не указано, что для H.264 использован зарезанный профиль aka «Baseline». Сравнение с H.264 High было бы гораздо интереснее. Причины выбора такого профиля не указаны.

11. Явно не указано, использовались ли похожие настройки для обоих кодеков. Например, keyframe interval должен быть выставлен на обоих энкодерах в одинаковое значение.

Наверное что-то еще, но этого должно быть вполне достаточно.

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

>Там много непонятных простому пользователю цифр.

Для них в сравнении есть раздел Conclusions и куча няшных графиков.

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

> Где?

Да хоть на лоре. Хотя, очевидно, что гугль сам понимает, что тягаться с h264 high profile его кодеку не следует.

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

вы не читаете тред

я это уже копировал. но в h264 использовались только часть возможностей (см выше)

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

> Тем более h264 (точнее MPEG не стоит на месте, и развивается), а vp8 все же доганяет только

Но таки On2 тоже не лыком сшиты, и у гугол денег тоже немало. Я и говорю, подсуетился бы гугол, глядишь, что и вышло. А ребята из ffmpeg - молодцы.

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

Чистым от патентов? Лично я на 99% уверен, что окажется. Иначе, зачем вся эта заворуха?

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

> RAW тоже проваславен. Давай уменьшим разрешение до 20 на 30 и это назовем кодеком

Тормозящее замыленное видео заставляет поностальгировать


Да хватит вам, Theora вполне ничего так. Не зря же её сравнивали вначале с h264, а не xvid какой нибудь или dirac.

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

у них там в бружуйлендии с этими патентами сам черт не разберется.

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

Новости рад,так как многие тут забыли, что ffmpeg входит в k-lite и значит что для IE это единственный пока вариант проигрывать webm

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

Но слышал, что для веба он плохо подходит. Может поэтому его особо и не рассматривали? В общем то, что гадать, для web`а я всё равно буду VP8 юзать, а для всяких девайсов я видео не жму - мне h264 ни к чему.

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

>Но таки On2 тоже не лыком сшиты, и у гугол денег тоже немало. Я и говорю, подсуетился бы гугол, глядишь, что и вышло.

Денег купить все компании, чьи технологии используются в MPEG-кодеках все-равно не хватит, а MPEG-кодеки прельщают именно поддержкой индустрии, технологичностью, совместимостью и очень широкими возможностями.

Вся надежда на то, что ожидаемое сегодня решение SCOTUS по Bilski v. Kappos окажет давление или прикончит полностью патенты на процессы (aka патенты на программное обеспечение).

А ребята из ffmpeg - молодцы.

Поддерживаю и очень жду FFV2.

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

> Желтуха на хабре бывает отменной.

Не думал что в кой-то веке буду солидарен с тобой. =) По поводу тестов на хабре и вообще тестов:

В прошлой теме срача h264 vs VP8 появился ананимус который раскритиковал выбранные ключи кодирования vp8. Т.е. со стороны h264 использовалось более качественные настройки и результат был не в пользу VP8. В свою очередь он приводил ключи и параметры, которые указывались разработчиками (с блогах или еще где-то) и с которыми по его словам результат должен был бы быть намного лучше.

В общем к чему все это? к тому, что пока формат молодой, документация не всем известна, я бы не стал особо доверять этим тестам. Есть факт - что в целом разница небольшая. а вот у кого пиписька длиннее - это нужно проводить серьезное исследование, со знанием вопроса. а не то, как на хабре (постом выше уже разнесли этот тест). у VP8 есть главнейший плюс - опенсорс. кем бы ни был h264, деюро стандартном веба он не станет никогда. W3C не пропустит!.

так что long live vp8 ! =)

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

>дирак очень хорошо

Dirac мылит, как и все wavelet-based кодеки и скорость совсем не радует.

Да и некоторые другие проблемы у wavelet-based кодеков есть: http://x264dev.multimedia.cx/?p=317.

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

Я имел ввиду, что мне нужен только декодер, жать я в него не буду :)

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

> Вся надежда на то, что ожидаемое сегодня решение SCOTUS по Bilski v. Kappos

Почему то мне кажется, что скорее выйдет VP9 какой нибудь и заткнет за пояс MPEG-кодеки (что конечно тоже маловероятно), чем отменят патенты :(

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