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

>так как H.264 (в настоящее время - промышленный стандарт кодирования видео)

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

Deleted
()

Замечательно. Ещё бы гугол подсуетилися.

Deleted
()

Звучит вкусно.

Звучит очень вкусно.

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

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

Давай не будем отрицать очевидное - H.264 является стандартом, который используют все крупнейшие фирмы в индустрии IT. Хотят они или нет его использовать - другой вопрос.

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

>>так как H.264 (в настоящее время - промышленный стандарт кодирования видео)

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

Некоторые люди не осознают, что делают работу, за которую вообще-то им должны бы заплатить :)

const86 ★★★★★
()

выглядит здорово.

jcd ★★★★★
()

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

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

Вне зависимости от того, что такое промышленный стандарт и прочего, какое это имеет отношение к рассматриваемой новости?

Deleted
()

> так как H.264 (в настоящее время - промышленный стандарт кодирования видео)

С чего это?

так как собственные реализации VP3/Theora и декодеров Vorbis у FFmpeg более быстрые, чем аналоги (например, чем те, что поставляются Xiph в виде libvorbis/libtheora), то, и собственная реализация декодера VP8 также более быстрая, чем libvpx от Google

Херасе логика.

anonymous
()

>в настоящее время - жлобский патентованный стандарт кодирования видео

Чуть более чем очевидный фикс.

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

>>Вне зависимости от того, что такое промышленный стандарт и прочего, какое это имеет отношение к рассматриваемой новости?

Это показывает, куда замахнулся VP8, для сравнения весовых категорий.

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

> Поэтому, зачастую, было проще читать исходный код libvpx, чем

спецификации. Более того, спецификации являются ни чем иным,

как копией исходных кодов декодера,



Перводчики жгут не по детски. :) 3 раза предложение перечитал так и не врубился ;)

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

>>Перводчики жгут не по детски. :) 3 раза предложение перечитал так и не врубился ;)

Ни разу не видел, как пишут спеки, накопипастив туда кода и сдобрив это невнятными каментами?

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

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

Тебе кто-то запрещает использовать этот кодек для большего?

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

> сдобрив это невнятными каментами?
Ты что тоже с будуна ? Или на тебя жара повлияла ? :)
Перечитай что они написали ;)))

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

Денис, перелогиньтесь хотябы.

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

>>Ты что тоже с будуна ? Или на тебя жара повлияла ? :)

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

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

Не запрещает, никто не запрещает и speex использовать для музыки... Я к тому что VP8 на что то большее может и замахивался, но его быстро поставили на место.

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

> Перечитал.
Не походу до тебя не дошло :(((
Ладно постараюсь объяснить - нахер смотреть в исходники если по их
утверждениям спеки и есть копипаста исходников ;)

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

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

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

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

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

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

> 3 раза предложение перечитал так и не врубился ;)

детям до шести лет противопоказано

Cargo
()

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

чем-то это напоминает привычки MS ^_^

а по сабжу - здорово, рад за ffmpeg

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

> Тебе кто-то запрещает использовать этот кодек для большего?

Отсутствие IP Core запрещает

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

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

усложнение понимания?

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

>>Отсутствие IP Core запрещает

Все открыто и свободно. Это отговорки.

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

>>VP8 выигрывает только у базового профиля H.264, более продвинутым профилям он сливает.

Реально объективных тестов мало, чтобы судить по ним. В одном сливает, в другом выигрывает.

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

> уместился всего лишь в 1400 строк кода

Што то мне кажется, за жопу всё равно возьмут патентные тролли

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

>Реально объективных тестов мало, чтобы судить по ним. В одном сливает, в другом выигрывает.

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

http://www.compression.ru/video/codec_comparison/h264_2010/appendixes.html#Ap...

anonymous
()

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

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

А что плохого? или у нас поток видео стал непрерывным?

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

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

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

> Покадровое сравнение для видеокодеков? Они там в своём уме?

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

Evtomax
()

> 1400 строк кода в файле vp8.c (включая пробелы и пустые строки)

Что означает фраза «включая пробелы»? Это строки вида 'chr(0x20)\n'? Она от этого перестала быть пустой?

anonymous
()

немножко добра тебе в карму, за годно оформленную новость.

По сабжу - радостный и вообще

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