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

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

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

Свободной альтернативы h.264 и сейчас нет. VP8 отлично подходит для Web, но для FullHD-видео в различных девайсах h.264 уделывает его с треском. Более или менее близкие результаты vp8 показывает разве что по сравнению c cамым простым профилем h.264, при этом жмет гораздо медленнее и файлы получаются более тяжелые. И применяется h.264 не только в любительских видеокамерах, а в любой современной hd-камере, которая жмёт видео-поток. А это все камеры, кроме топового эшелона, которыми всякие Аватары снимают. А еще H.265 уже на подходе, который будет круче 264го на порядок.

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

только если на порядок = в два раза

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

Нарисуй свой кодек, епта, чего ты здесь ноешь.

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

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

Наверно только тебя. Потому что первоначальнео кодирование это HD. А целевое - это web

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

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

Этому отстою до Pro Tools далеко.

Да. Запусти его у себя на компе.

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

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

Ну что ж - ISO снова подтвердило свою расшифровку I Sold Out. Включение вдоль и поперёк запатентованных средств в стандарт - принуждение платить деньги.

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

namezys> Да. Запусти его у себя на компе.

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

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

anonymous> И применяется h.264 не только в любительских видеокамерах, а в любой современной hd-камере, которая жмёт видео-поток. А это все камеры, кроме топового эшелона, которыми всякие Аватары снимают.

4.2

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

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

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

Для VP8 это особого значения не имеет, так как алгоритмы трансформации у них очень похож.

Да и, в любом случае, такое сравнение ближе к реальному применению, ибо любительские камеры снимают, в основном, в H.264. Настоящее uncompressed-видео, особенно HD, любитель может получить только в результате 3D-моделирования или записи скринкастов.

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

>жатель давитѣль

Во-во, а потом получаются вот такие вещи: http://multimedia.cx/eggs/sif1-on-the-map/, ибо русские плохо знают общепринятую терминологию и английский язык.

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

> То есть либо всё полностью профессионально, либо нет.

Вы прямо такой специалист в этом? Почему-то почти везде обходятся logic'ом или кубайсом?

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

> На такие камеры снимают видео в несжатом виде, и только потом обрабатывают и сжимают.

уже давно не кто не пишет в несжатом виде

представте, какой там будет объем данных. Это по какому интерфейсу они должны передаваться и куда писаться?

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

>Ну что ж - ISO снова подтвердило свою расшифровку I Sold Out. Включение вдоль и поперёк запатентованных средств в стандарт - принуждение платить деньги.

GSM? DVD? Blu-ray? HDMI? UMTS? Wi-Fi? WiMAX? LTE?

Дальше продолжать список стандартов, для реализации которых требуется лицензировать патенты, но при этом они являются неотъемлемой частью нашей жизни?

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

>4.2

4.2

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

На какие «такие»? Написано же, что кроме камер топового эшелона, они да, ничего не жмут. Такие как Sony HDC-F950, она не имеет запоминающего устройства, просто гонит по оптике 2К-кадры в несжатом виде на какой-нибудь сониевский магнитофончик ценой в 40к баксов. Но между такими монстрами и игрушками типа Kodak PlaySport лежит гигантская пропасть, заполненная кучей девайсов. И полупрофессиональные камкордеры точно так же жмут видео в H.264

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

> компрессор

Переводить «encoder» как «компрессор» ОЧЕНЬ неправильно.

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

>можно достать несжатое у блендерцев - у них на фтп папки с png

Я же сказал, что 3D-рендеринг — одно из исключений, но такой контент имеет свои особенности, а именно, он очень «чистый» и поэтому достигает «прозрачности» (transparency), по отношению к исходнику, на относительно низких битрейтах. И как раз поэтому он часто плохо отражает ситуацию с фильмами, любительской съемкой и 2D-анимацией.

anonymous
()

Хм... В арче ffmpeg уже почти каждый день обновляется. Только вот вчера в списке кодеков был vp8 и libvpx, а сегодня только libvpx.

Кто-нибудь может подсказать, с какими параметрами лучше всего сконвертировать видео из какого-нибудь divx в vp8?

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

>Они надобавляли оптимизаций для armv7

-march=armv7?

//TCPMP решает

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

суть проблемы как раз в том что разные методы кодирования суммируют ошибки/артефакты при кодировании во второй раз

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

>суть проблемы как раз в том что разные методы кодирования суммируют ошибки/артефакты при кодировании во второй раз

Это не проблема, это особенность реального мира, а также задача с которой энкодеру придется сталкиваться гораздо чаще, чем с идеально чистым lossless контентом, полученным в результате 3D-рендеринга.

Также стоит отметить, что одинаковые методы кодирования тоже страдают от этого. Артефакты от первой компрессии влияют на решения энкодера при повторном кодировании даже в тот же самый формат тем же самым энкодером. Но для перекодировки, в основном, используется другой энкодер, часто использующий другие принципы принятия решений. Например, при энкодинге H.264 в консьюмерских программных продуктах или для web чаще всего применяется x264 или Mainconcept H.264, в TV-студиях или для авторинга Blu-ray чаще всего используют ATEME, Blu-code или какие-либо hardware-решения, в камкордерах ставят различные одночиповые hardware-энкодеры. Естественно все эти продукты различаются по качеству и алгоритмам энкодинга, так что артефакты и эффективность у них будут очень разные.

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