LINUX.ORG.RU

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

 , , vp7, , ,


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 ()

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

>Интересно увидеть обоснование использование асм-кода (особенно «неиспользуемого»)

Вы в исходники Firefox'а не заглядывали? А ведь там часть видеокодека, код которого унаследован от Xiph, тоже на ассемблере. Причина проста: скорость. В списке рассылки xiph предлагали переписать это на Си, чтобы было проще поддерживать, но вроде как разработчики отказались, потому как скорость кода на Си была ниже.

X-Pilot ★★★★★
()
Ответ на: комментарий от ferhiord

Интересно увидеть обоснование использование асм-кода (особенно «неиспользуемого»)

аргументация - когда то че то кто то написал, потом уволился, хз че эта вставка ваще делает, мы с васей не при делах, а удалять стремно.

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

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

Практически невероятно, если только не будет открыт какой-нибудь совершенно новый способ эффективного кодирования видео-информации, ибо те, кто разрабатывает видео-стандарты вне ISO/IEC MPEG или ITU изначально в проигрышном положении. И всегда найдется десяток-другой патентованных способов улучшить компрессию на 3%, что в сумме дает очень значительное преимущество.

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

> И всегда найдется десяток-другой патентованных способов улучшить компрессию на 3%, что в сумме дает очень значительное преимущество.

Да уж, уже плохо. Даже если гугол своим патентным пулом надавит...

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

В проигрышном, но вы же не верите всерьез, что человечество открыло все возможные способы сжатия видеоданных? :) Если я в чем и уверен, так это в том, что всегда можно еще что то придумать.

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

>вы же не верите всерьез, что человечество открыло все возможные способы сжатия видеоданных?

Конечно не верю, вот только никто не знает, когда будет следующее революционное открытие в этой сфере. Может оно случилось уже вчера, может через месяц, может через год, а может и через 20 лет.

Но я очень надеюсь, что его автор не будет любителем патентов. ;)

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

>FFmpeg запретить для windows

А смысл? Быстрые декодеры H.264 у windows уже есть (CoreAVC, DivX H.264), а если не будет быстрых декодеров VP8, то это явно затормозит адаптацию данного кодека.

anonymous
()

Когда уже аффтар заопенсорсит энкодер SIF1 и закопает всякие патентованые поделия вроде h264?

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

только виндовые хомеки о них почти не знают,так как сидят на пакете k-lite кодеков.А там ffmpeg+divX и все. А платные плееры у нас по крайей мере все меньше и меньше качают

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

> Он замахнулся на интернет-видео и ни на что больше.

Чтобы создавать интернет-видео нужна поддержка в софте. Какой софт поддерживает VP8? От Adobe, Apple, ...?

pythonist
()
Ответ на: комментарий от X-Pilot

В FF про библиотеки не слышали? Что забыл код кодека в коде браузера?

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

> Какой софт поддерживает VP8?

Сабж поддерживает и этого достаточно.

От Adobe, Apple, ...?


Эти компании вообще производят софт или только трояны?

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

> Эти компании вообще производят софт или только трояны?

Эти компании производят один из лучших софтов

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

> Это «всего лишь» уже работает быстрее гугловской реализации

Это не так. На arm и x86 он как раз МЕДЛЕННЕЕ libvpx. На остальных архитектурах быстрее.

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

Хотя по идее в проприетарщине только велосипедостроение возможно. [troll]Какой же они VCS пользуются раз форкнуть боятся.[/troll] Или не.[troll] Просто пишут такой хреновый код, что его никто другой не понимает. [/troll]

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

Какого назначения? Типа кому то нужен кодек на смартфон, поэтому должен жрать мало ресурсов, другому на ресурсы пофиг,так что ли?

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

Ну. Adobe и Apple не очень сравнимы в плане софта. Всё таки Apple больше девайсов отличный производитель. Вот Adobe это да, конь.

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

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

А для тех, кто не в теме, кто такой Роналд (Макдоналдс, что ли?) и вообще, может всё же дадите ссылку в тексте?

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

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

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


Улыбнуло. Если бы этой идеей исчерпывался h264...

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

> Всё таки Apple больше девайсов отличный производитель. Вот Adobe это да, конь.

Mac Os X, Logic, Finale Cut - это все не слабый софт

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

Logic - профессиональный софт для музыконтов

Final Cut - почти стандарт в фильмопроизводстве

просто нет смысла их слышать. и тот, и другой для меня темные лес

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

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

энкодеры

facepalm

Мигрируй в пиндосию живее.

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

> Хуже того: скриншоты в jpeg. И как отличать артефакты сжатия картинок от артефактов видео-кодека?

Есть lossless jpeg.

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

> Mac Os X, Logic

В данном конкретном случае apple не столько производитель, сколько форкАтель и выкупатель.

И да, весь толковый софт, который есть _сейчас_ на mac'е это либо Adob'o\Microsoft'овская проприетарщина портированная с оффтопика, либо порты OSS с Linux\BSD. Поскольку про легенду «mac гораздо более для художников и прочих поэтов», адекватные люди забыли вместе с последними Quadra'ми. Есть конечно некоторые исключительно полезные mac-specific мелочи, но они появились исключительно вследствии совершённых с особым цинизмом надругательств apple над BSD.

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

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

К сожалению h.264 действительно является де факто промышленным стандартом. Свободной альтернативы в то время просто не было. Вот сейчас этот h.264 даже в любительских видеокамерах используется.

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

>Есть lossless jpeg.

Да, есть, но, AFAIR, он почти нигде не реализован, так что тут точно не этот случай.

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

>> энкодеры

facepalm

Мигрируй в пиндосию живее.

Альтернативы?

Кодер — не подходит, ибо гораздо чаще используется в контексте «человек, пишущий код».

Кодек — не подходит, ибо означает комплекс из энкодера и декодера и гораздо чаще используется для обозначение непосредственно стандарта aka спецификации.

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

XVilka> Вот еще один проект кто «ворует код» http://4pda.ru/forum/index.php?showtopic=174459&st=180&start=180

Посмотрел внимательнее: кажись это китайская «разработка». А китайцы, как известно, своего ничего не сделали - они всё делают в bolgenos-style.

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

Mystra_x64> %) Я как бы о том, что новость то совсем не об этом.

Согласен. Но таки это альтернатива h.264

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

> Да, есть, но, AFAIR, он почти нигде не реализован, так что тут точно не этот случай.

В GIMP'е, например, он отлично реализован.

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

>Чтобы создавать интернет-видео нужна поддержка в софте

Чтобы серьёзно заняться интернет- и прочим видеом, нужэна поддержка в железе. На данный момент, сабж поддерживает маргинальное меньшинство производителей браузеров. И всё.

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

>Если оно стандартизировано, какого фига за это деньги просят?

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

За тексты ISO всегда хотят денег, это известно давно, AVC тут исключением не является.

У ITU-T текст этого стандарта доступен бесплатно в формате pdf и за 301 CHF в формате Word 2007, что довольно-таки забавно и как бы намекает.

Патенты — это другой и гораздо более сложный вопрос, эти организации по стандартизации требуют лишь что патенты, требуемые для реализации стандарта, будут доступны на условиях RAND (reasonable and non-discriminatory)/FRAND (fair, reasonable and non-discriminatory).

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

> Кодер

Вполне понятно из контекста. И это основной, официальный смысл слова «кодер».

Кодек — не подходит, ибо означает комплекс из энкодера и декодера

КоДек же. Не ЕнкоДек.

Dimka-Bo
()

вот только меня или ещё кого либо смущают сравнение h264 и еще кого-то на видео первоначально закодированного в h264 ?

wingrime
()
Ответ на: комментарий от Dimka-Bo

Во-первых, конечно же кодек, а не енкодек, но перевести на русский это можно как кодировщик\декодировщик или компрессор\декомпрессор. Но не калькировать английское кодер\декодер.

Во-вторых, если вам так не нравится слово энкодер, то тут открыт простор, какое же именно слово утвердить в качестве «основного, официальнго», и главное в каком более всего исконно-православного духа и славянских корней: кодер, кодировщик, компрессор?

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