Выпущена (http://lists.freedesktop.org/archives/libva/2014-September/0... версия 1.4.0 библиотеки libva, реализующей программный интерфейс VA-API (http://www.freedesktop.org/wiki/Software/vaapi/) (Video Acceleration API (http://en.wikipedia.org/wiki/Video_Acceleration_API)), в своё время созданный компанией Intel для замены XvMC. VA-API представляет унифицированный интерфейс к аппаратным и акселерированным (например, с использованием OpenCL) реализациям кодирования и декодирования видео.
Наиболее заметными нововведениями стали поддержка кодирования в формате VP8, добавление профилей кодирования и декодирования H.264 MVC (https://en.wikipedia.org/wiki/Multiview_Video_Coding), возможность управления качеством кодирования, поддержка SoC Cherryview и интерфейс экспорта буферов для улучшения переносимости со смежными API (EGL, OpenCL). Одновременно доступен (http://lists.freedesktop.org/archives/libva/2014-September/0... новый выпуск драйвера libva-intel-driver 1.4.0 с реализацией VA-API для GPU компании Intel.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTgwMDU
Новость: http://www.opennet.me/opennews/art.shtml?num=40717
Кстати, почему АМД выбрали для свободных дров не VAAPI a VDPAU?
Потому что интерфейс более удобен для использования.
+ VDPAU получил широкую популярность благодаря тем, кто первым (nVidia) реализовал рабочее аппаратное дэкодирование в мире OS Linuх в своих дровах, хоть и в проприетарных.А Va-api проблемный тем, что очень скудная документация (читай "исходники без комментариев") на этот API (так утверждали когда-то разработчики mplayer, и была раелизация в отдельной ветке mplayer-vaapi), и только VLC его както реализовал в базовой версии. Но это было год назад.
И походу VA-API это еще и реализация со стороны открытых дров Intel. И VA-API со стороны АМД понимаю как попытка унифицыровать интерфейсы аппаратного ускорения.
> в отдельной ветке mplayer-vaapi), и только VLC его както реализовал в
> базовой версии. Но это было год назад.Зато VA-API допускает мысль что можно и кодировать, а не только декодировать видео. И допускает что в природе есть бОльшее количество форматов. Хоть тот же VP8 как в сабже. У VDPAU нельзя попросить ускорение энкодинга видео: не предусмотрено. Аналогично с поддержкой VP8, etc.
> Зато VA-API допускает мысль что можно и кодировать, а не только декодировать видео.Как бы буква D неиллюзорно намекает, для чего нужен VDPAU. И надо сказать, что по сути VA-API просто предоставляет два слабо пересекающихся API - для кодирования и декодирования. В части декодирования VDPAU лучше уже хотя бы тем, что дает какие-то гарантии потокобезопасности.
> И допускает что в природе есть бОльшее количество форматов.
Ситуация с поддержкой форматов абсолютно одинакова - для какого кодека определен enum, для того и можно запросить ускорение. И то, совсем не факт, что тебе его дадут.
> - для кодирования и декодирования. В части декодирования VDPAU лучше уже
> хотя бы тем, что дает какие-то гарантии потокобезопасности.Это все круто, но смысл дергания такого API в несколько потоков из одной программы мне не очень очевиден (там и с 1 потоком загрузка проца около 0 обычно), а вот то что оно decode-only - напрягает. В конечном итоге либа у сабжа таки одна на обе операции, а то что кодирование и декодирование не похожи друг на друга - охренеть, такая неожиданность. У нвидии вообще нет решения для акселерированного энкодинга видео. Тогда как сие умеют не то что матерые GPU десктопных конкурентов, но и даже всякие пятибаксовые процы для мобилок/планшеток.
>> И допускает что в природе есть бОльшее количество форматов.
> Ситуация с поддержкой форматов абсолютно одинакова -...кроме того, что va-api развивается интелом и они в курсе этих самых кодеков, а нвидия судя по всему посчитали что их миссия выполнена и самоустранилась. В смысле, где развитие VDPAU? Интел да, живой, веселый. А у нвидии богатая история создания всяких поматросил-бросил.
> Это все круто, но смысл дергания такого API в несколько потоков из одной программы мне не очень очевиденМир не ограничен одними видео-плеерами. Есть приложения, которым надо работать сразу со многими потоками параллельно.
> а вот то что оно decode-only - напрягает.
А меня не напрягает. Я с бОльшим удовольствием для декодирования буду пользоваться VDPAU. Для кодирования придется VA-API, тут уже выбирать не приходится.
> ...кроме того, что va-api развивается интелом и они в курсе этих самых кодеков
Ну да, конечно, а Nvidia вчера родилась и про кодеки не слышала.
http://www.nvidia.com/object/tegra-superchip.html
Да, на десктопах поддержки нет. У Intel вон тоже, только в Broadwell появится.
> Мир не ограничен одними видео-плеерами. Есть приложения, которым надо работать сразу со
> многими потоками параллельно.Ну пусть они и теребят интель, если им надо. Правда, есть такое подозрение что далеко не любое железо вообще готово декодировать несколько видеопотоков и тем более кодировать их.
> А меня не напрягает. Я с бОльшим удовольствием для декодирования буду пользоваться
> VDPAU. Для кодирования придется VA-API, тут уже выбирать не приходится.А мне кажется горбатой идея использовать 2 разных апи с совсем разными закидонами.
> Ну да, конечно, а Nvidia вчера родилась и про кодеки не слышала.
Видимо не слышала - где поддержка VP8/9 в VDPAU? Оно вообще про эти форматы не в курсе. И кто это должен добавлять? В VA-API это делает интел и они похожи на тех кто еще и майнтайнить свой код готов. А нвидия - это та компания которой PM линукса факом машет? Ну да, я могу себе представить как они будут свой код/апи майнтайнить при таких славных традициях.
> http://www.nvidia.com/object/tegra-superchip.html
> Да, на десктопах поддержки нет. У Intel вон тоже, только в Broadwell появится.Вопрос в том чтобы апи для начала вообще про формат знало. Способности конкретной железки - второй вопрос уже. Это в перспективе может быть и какой-нибудь костыль типа opencl-бэкэнда и прочее, программе вообще не обязательно знать как это либой внутрях делается.
>> в отдельной ветке mplayer-vaapi), и только VLC его както реализовал в
>> базовой версии. Но это было год назад.
> Зато VA-API допускает мысль что можно и кодировать, а не только декодировать
> видео. И допускает что в природе есть бОльшее количество форматов. Хоть
> тот же VP8 как в сабже. У VDPAU нельзя попросить ускорение
> энкодинга видео: не предусмотрено. Аналогично с поддержкой VP8, etc.Ну чего не знал, того не знал. Ну и в нашем случае решает большенство. Большенству нужно декодирование, первым был доступен VDPAU. Посему победитель очевиден.
И я не против VA-API, лишь бы он был реализован на практике, в самих приложениях, а не в дровах. И что бы можно было одновременно использовать и vdpau интерфейс(есть ПО без VA-API support) и va-api (для тех кто не дружит с VDPAU) одновременно :)
> Кстати, почему АМД выбрали для свободных дров не VAAPI a VDPAU?Они вроде как его поддержку пилят нынче: VA-API позволяет также и кодировать видео, а не только декодировать. И поддерживает больше форматов. А еще VA-API умеет использовать бэкэнд VDPAU и транслировать в него, так что если некто умеет VDPAU - он и VA-API умеет, а хоть и урезанно слегка.
Наоборот тоже можно. Я даже тестил как-то из академического интереса.
> Наоборот тоже можно. Я даже тестил как-то из академического интереса.Наоборот в полноценном виде не получится. Если VDPAU не предусматривает кодирование видео - ну и загейтовать кодирование видео через VA-API в VDPAU не получится тогда. Вообще, у нвидии какая-то чисто потребццкая реализация, не допускающая мысль о том что контент еще и гененить могут, в том числе возжелав акселерированное кодирование, чтобы укладываться в реалтайм без дикого потребления и урезки качества.
> Вообще, у нвидии какая-то чисто потребццкая реализация, не допускающая
> мысль о том что контент еще и гененить могут, в том
> числе возжелав акселерированное кодирование, чтобы укладываться в реалтайм без дикого
> потребления и урезки качества.Разве в 2008-м на рынке были доступны аппаратные кодеры видео? Тогда и декодирование было в диковинку, о кодировании никто и не помышлял даже.
> Разве в 2008-м на рынке были доступны аппаратные кодеры видео?Hauppuage WinTV PVR PCI был доступен в 1998.
>> Разве в 2008-м на рынке были доступны аппаратные кодеры видео?
> Hauppuage WinTV PVR PCI был доступен в 1998.Абсолютно точный и абсолютно бесполезный ответ.
Что-то я сомневаюсь, что оно умело произвольный видеопоток с компьютера сжимать. Но если умело, все претензии по поводу API — к производителю этих PVR плат.
> Абсолютно точный и абсолютно бесполезный ответ.Каков вопрос :) Поискал точнее к тому, чтоб не жить нам одним годом.
> Что-то я сомневаюсь, что оно умело произвольный видеопоток с компьютера сжимать.
MPEG2-платы тогда как раз и применялись, т.к. на CPU было совсем тоскливо. Возможно ли было нежатые данные с хоста конкретно на эту железку засовывать -- не знаю, но вряд ли, бытовые всё-таки брали сигнал через АЦП и широкополосный по PCI не гоняли, насколько помню.
> Разве в 2008-м на рынке были доступны аппаратные кодеры видео?1) Да, были доступны. В всяких мобилах подпирание хардварными акселераторами было давно, так что если бы некто хоть немного смотрел вперед...
2) А сейчас у нас на дворе вообще 2014 год и нам как-то совсем не логично утыкаться в реалии 2008 года.> Тогда и декодирование было в диковинку, о кодировании никто и не помышлял даже.
Кроме мобилочных процов, которые как обычно на декаду впереди остальной индустрии.
> 2) А сейчас у нас на дворе вообще 2014 год и нам как-то совсем не логично утыкаться в реалии 2008 года.VDPAU потому и стал популярным, что не меняется уже долгое время. Обновления не меняли обратную совместимость, просто появилось несколько новых кодеков.
А если хочется идти в ногу со временем, твой выбор — VA-API. Поломанное ABI каждые несколько версий — в комплекте.
Потому что в тот момент в Mesa 3D (Gallium) уже был работающий state tracker для VDPAU, а для VA-API такового не было.
> Потому что в тот момент в Mesa 3D (Gallium) уже был работающий
> state tracker для VDPAU, а для VA-API такового не было.Ну знаете, а ...цать лет у меня был работающий CP/M, давайте на него ориентироваться? Он древнее :).
без вяленого не собирается. пришлось configure править
> (например, с использованием OpenCL)Уже работает где-то? Хотеть такое в ffmpeg.
О бэкэндах для OpenCL не слышал. Но оно работает с бэкэндом XVBA (закрытые дрова AMD), с бэкондом интеловских дров и с бэкэндом VDPAU для невидии и отрытых дров AMD.
Бэкэнд OpenCLвам может понадобиться, только если ваша карточка не AMD/nVidia/Intel, но при этом поддерживает OpenCL. А таких немного.
OpenCL - это не только карточки
Эти бакенды аппаратно заточены на определённые стандарты и не могут в новые, а потому находятся в морально отстающем состоянии. Сейчас кодируют во всякие HEVC, VP9 и 10-битные H.264, а мой хлам их не ускоряет.Для OpenCL, как я понимаю, для каждого нового формата надо писать новые движки, но они могут работать на любых ускорялках с поддержкой OpenCL, включая старые.
> Уже работает где-то? Хотеть такое в ffmpeg.За VA-API не скажу, а x264 нынче умеет выносить некоторые операции через opencl, если он у вас есть. Нечто типа VA-API могло бы помочь причесать весь этот зоопарк.
> Нечто типа VA-API могло бы помочь причесать весь этот зоопарк.Не могло бы.
> Не могло бы.Чего бы это вдруг? :)
месяц назад тестил из интереса гитовый x264 собранный с OpenCL.
Оно медленне чем тупо только на CPU.
железо - i7-4770k + нывидия 760 (блоб, мать его)насколько я понял x264 использует OpenCL не для самого кодирования, а для анализа (look-ahead).
если я не ошибаюсь только gstreamer умеет _кодировать_ с использованием GPU, только на AMD и со стопкой "левых" патчей.
может и амд через omx, может и интел через vaapi, никаких левых патчей не надо, только разве что для скрости, но работает и так из коробки на свежей месе.
http://www.gearsongallium.com/?p=1378
http://www.gearsongallium.com/?p=1464
Что это за кусок глючной бидонятины сыпящей ошибками? И почему результаты бенчей надо выискивать из скриншотов? На фоне таких авторов даже фороникс - профи экстра класса.
Так и есть, только в драйвере NVIDIA есть файл libnvidia-encode.so.340.24.
Для всех любителей аппаратного ускорения кодирования напоминаю, что каждая железка в каждый видеопоток вставляет свой еле заметный уникальный ватермарк. Пруфы найдёте сами.
> Пруфы найдёте сами.Круто. Громкую заяву делают одни, а обосновывать ее должны другие. Нормальный подход!
> Круто. Громкую заяву делают одни, а обосновывать ее должны другие. Нормальный подход!http://www.openbsd.org/papers/eurobsdcon2014-libressl.html
> In my commit message, I mentioned "hey there's a bug in here, but the details are secret." This was actually kind of misleading because the secret bug was in a different library, in code that had already been removed. Three days later, on July 31, two researchers found a remotely expoitable buffer overflow in the libcrypto SRP code. This is like "throw a rock; you're guaranteed to hit something." Even when you point people in the wrong direction, they still find bugs.
А это нормально - когда спрашиваешь про кодировщик видео, пруфы для openssl почему-то подгоняют? Или это такое общее рассуждение на тему "как страшно жить"?
> А это нормально - когда спрашиваешь про кодировщик видео, пруфы для openssl
> почему-то подгоняют? Или это такое общее рассуждение на тему "как страшно
> жить"?Эх, читать разучился, что ли? Вот тебе суть вкратце: некий чел вбросил паранойи в тусовку на тему уязвимостей в коде. Несмотря на то, что он имел в виду уязвимость, которую он уже устранил, пара других челов нашла ещё уязвимость, о которой первый чел не знал.
А теперь суть по полочкам. Аноним в сообщении говорит о вставке вотермарков — чел по ссылке говорит об уязвимости. Ни тот, ни другой не имеют доказательств, просто набрасывают на вентилятор. Сообщество начинает копать. Кто-нибудь находит бяку.
Это было слишком сложно, да?
Проверяется очень легко: достаточно сравнить видеофайлы, полученные из нескольких аппаратных кодировщиков одной модели с одинаковыми входными данными. Различия в файлах означают наличие водяных знаков.Отсутствие различий не гарантирует отсутствие водяных знаков, несущих информацию о модели и прошивке. Как проверить - не знаю, но это и не так страшно. Всего лишь ограничивает область поиска источника видео владельцами железок с данной моделью с прошивкой.
del
По-прежнему ждём, что о нашей безопасности позаботится кто-то другой?А мне пруфов и не надо. Ведь это так удобно - идентифицировать источник по видео или реенкоду.
> По-прежнему ждём, что о нашей безопасности позаботится кто-то другой?Добрый дядя позаботится
> Добрый дядяВернее, старший братишка.