| |
| |
| 3.6, KT315 (ok), 11:49, 01/10/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
 + VDPAU получил широкую популярность благодаря тем, кто первым (nVidia) реализовал рабочее аппаратное дэкодирование в мире OS Linuх в своих дровах, хоть и в проприетарных.
А Va-api проблемный тем, что очень скудная документация (читай "исходники без комментариев") на этот API (так утверждали когда-то разработчики mplayer, и была раелизация в отдельной ветке mplayer-vaapi), и только VLC его както реализовал в базовой версии. Но это было год назад.
И походу VA-API это еще и реализация со стороны открытых дров Intel. И VA-API со стороны АМД понимаю как попытка унифицыровать интерфейсы аппаратного ускорения.
| | |
| |
| 4.8, Аноним (-), 13:08, 01/10/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
> в отдельной ветке mplayer-vaapi), и только VLC его както реализовал в
> базовой версии. Но это было год назад.
Зато VA-API допускает мысль что можно и кодировать, а не только декодировать видео. И допускает что в природе есть бОльшее количество форматов. Хоть тот же VP8 как в сабже. У VDPAU нельзя попросить ускорение энкодинга видео: не предусмотрено. Аналогично с поддержкой VP8, etc.
| | |
| |
| 5.17, Аноним (-), 16:53, 01/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Зато VA-API допускает мысль что можно и кодировать, а не только декодировать видео.
Как бы буква D неиллюзорно намекает, для чего нужен VDPAU. И надо сказать, что по сути VA-API просто предоставляет два слабо пересекающихся API - для кодирования и декодирования. В части декодирования VDPAU лучше уже хотя бы тем, что дает какие-то гарантии потокобезопасности.
> И допускает что в природе есть бОльшее количество форматов.
Ситуация с поддержкой форматов абсолютно одинакова - для какого кодека определен enum, для того и можно запросить ускорение. И то, совсем не факт, что тебе его дадут.
| | |
| |
| 6.27, Аноним (-), 22:02, 01/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> - для кодирования и декодирования. В части декодирования VDPAU лучше уже
> хотя бы тем, что дает какие-то гарантии потокобезопасности.
Это все круто, но смысл дергания такого API в несколько потоков из одной программы мне не очень очевиден (там и с 1 потоком загрузка проца около 0 обычно), а вот то что оно decode-only - напрягает. В конечном итоге либа у сабжа таки одна на обе операции, а то что кодирование и декодирование не похожи друг на друга - охренеть, такая неожиданность. У нвидии вообще нет решения для акселерированного энкодинга видео. Тогда как сие умеют не то что матерые GPU десктопных конкурентов, но и даже всякие пятибаксовые процы для мобилок/планшеток.
>> И допускает что в природе есть бОльшее количество форматов.
> Ситуация с поддержкой форматов абсолютно одинакова -
...кроме того, что va-api развивается интелом и они в курсе этих самых кодеков, а нвидия судя по всему посчитали что их миссия выполнена и самоустранилась. В смысле, где развитие VDPAU? Интел да, живой, веселый. А у нвидии богатая история создания всяких поматросил-бросил.
| | |
| |
| 7.34, Аноним (-), 22:47, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Это все круто, но смысл дергания такого API в несколько потоков из одной программы мне не очень очевиден
Мир не ограничен одними видео-плеерами. Есть приложения, которым надо работать сразу со многими потоками параллельно.
> а вот то что оно decode-only - напрягает.
А меня не напрягает. Я с бОльшим удовольствием для декодирования буду пользоваться VDPAU. Для кодирования придется VA-API, тут уже выбирать не приходится.
> ...кроме того, что va-api развивается интелом и они в курсе этих самых кодеков
Ну да, конечно, а Nvidia вчера родилась и про кодеки не слышала.
http://www.nvidia.com/object/tegra-superchip.html
Да, на десктопах поддержки нет. У Intel вон тоже, только в Broadwell появится.
| | |
| |
| 8.41, Аноним (-), 03:54, 05/10/2014 [^] [^^] [^^^] [ответить] | +/– | Ну пусть они и теребят интель, если им надо Правда, есть такое подозрение что д... текст свёрнут, показать | | |
|
|
|
| 5.36, KT315 (ok), 12:37, 02/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> в отдельной ветке mplayer-vaapi), и только VLC его както реализовал в
>> базовой версии. Но это было год назад.
> Зато VA-API допускает мысль что можно и кодировать, а не только декодировать
> видео. И допускает что в природе есть бОльшее количество форматов. Хоть
> тот же VP8 как в сабже. У VDPAU нельзя попросить ускорение
> энкодинга видео: не предусмотрено. Аналогично с поддержкой VP8, etc.
Ну чего не знал, того не знал. Ну и в нашем случае решает большенство. Большенству нужно декодирование, первым был доступен VDPAU. Посему победитель очевиден.
И я не против VA-API, лишь бы он был реализован на практике, в самих приложениях, а не в дровах. И что бы можно было одновременно использовать и vdpau интерфейс(есть ПО без VA-API support) и va-api (для тех кто не дружит с VDPAU) одновременно :)
| | |
|
|
|
| 2.7, Аноним (-), 13:05, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Кстати, почему АМД выбрали для свободных дров не VAAPI a VDPAU?
Они вроде как его поддержку пилят нынче: VA-API позволяет также и кодировать видео, а не только декодировать. И поддерживает больше форматов. А еще VA-API умеет использовать бэкэнд VDPAU и транслировать в него, так что если некто умеет VDPAU - он и VA-API умеет, а хоть и урезанно слегка.
| | |
| |
| 3.9, softfire (?), 13:32, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Наоборот тоже можно. Я даже тестил как-то из академического интереса.
| | |
| |
| 4.13, Аноним (-), 15:13, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Наоборот тоже можно. Я даже тестил как-то из академического интереса.
Наоборот в полноценном виде не получится. Если VDPAU не предусматривает кодирование видео - ну и загейтовать кодирование видео через VA-API в VDPAU не получится тогда. Вообще, у нвидии какая-то чисто потребццкая реализация, не допускающая мысль о том что контент еще и гененить могут, в том числе возжелав акселерированное кодирование, чтобы укладываться в реалтайм без дикого потребления и урезки качества.
| | |
| |
| 5.16, irinat (ok), 15:39, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Вообще, у нвидии какая-то чисто потребццкая реализация, не допускающая
> мысль о том что контент еще и гененить могут, в том
> числе возжелав акселерированное кодирование, чтобы укладываться в реалтайм без дикого
> потребления и урезки качества.
Разве в 2008-м на рынке были доступны аппаратные кодеры видео? Тогда и декодирование было в диковинку, о кодировании никто и не помышлял даже.
| | |
| |
| 6.24, Michael Shigorin (ok), 20:44, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Разве в 2008-м на рынке были доступны аппаратные кодеры видео?
Hauppuage WinTV PVR PCI был доступен в 1998.
| | |
| |
| 7.25, irinat (ok), 20:52, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Разве в 2008-м на рынке были доступны аппаратные кодеры видео?
> Hauppuage WinTV PVR PCI был доступен в 1998.
Абсолютно точный и абсолютно бесполезный ответ.
Что-то я сомневаюсь, что оно умело произвольный видеопоток с компьютера сжимать. Но если умело, все претензии по поводу API — к производителю этих PVR плат.
| | |
|
| 6.28, Аноним (-), 22:03, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Разве в 2008-м на рынке были доступны аппаратные кодеры видео?
1) Да, были доступны. В всяких мобилах подпирание хардварными акселераторами было давно, так что если бы некто хоть немного смотрел вперед...
2) А сейчас у нас на дворе вообще 2014 год и нам как-то совсем не логично утыкаться в реалии 2008 года.
> Тогда и декодирование было в диковинку, о кодировании никто и не помышлял даже.
Кроме мобилочных процов, которые как обычно на декаду впереди остальной индустрии.
| | |
| |
| 7.33, irinat (ok), 22:14, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> 2) А сейчас у нас на дворе вообще 2014 год и нам как-то совсем не логично утыкаться в реалии 2008 года.
VDPAU потому и стал популярным, что не меняется уже долгое время. Обновления не меняли обратную совместимость, просто появилось несколько новых кодеков.
А если хочется идти в ногу со временем, твой выбор — VA-API. Поломанное ABI каждые несколько версий — в комплекте.
| | |
|
|
|
|
|
| 2.15, irinat (ok), 15:34, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Потому что в тот момент в Mesa 3D (Gallium) уже был работающий state tracker для VDPAU, а для VA-API такового не было.
| | |
| |
| 3.29, Аноним (-), 22:04, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Потому что в тот момент в Mesa 3D (Gallium) уже был работающий
> state tracker для VDPAU, а для VA-API такового не было.
Ну знаете, а ...цать лет у меня был работающий CP/M, давайте на него ориентироваться? Он древнее :).
| | |
|
|
| 1.10, Аноним (-), 13:45, 01/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> (например, с использованием OpenCL)
Уже работает где-то? Хотеть такое в ffmpeg.
| | |
| |
| 2.11, softfire (?), 14:17, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
О бэкэндах для OpenCL не слышал. Но оно работает с бэкэндом XVBA (закрытые дрова AMD), с бэкондом интеловских дров и с бэкэндом VDPAU для невидии и отрытых дров AMD.
Бэкэнд OpenCLвам может понадобиться, только если ваша карточка не AMD/nVidia/Intel, но при этом поддерживает OpenCL. А таких немного.
| | |
| |
| 3.21, Аноним (-), 19:28, 01/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Эти бакенды аппаратно заточены на определённые стандарты и не могут в новые, а потому находятся в морально отстающем состоянии. Сейчас кодируют во всякие HEVC, VP9 и 10-битные H.264, а мой хлам их не ускоряет.
Для OpenCL, как я понимаю, для каждого нового формата надо писать новые движки, но они могут работать на любых ускорялках с поддержкой OpenCL, включая старые.
| | |
|
| 2.14, Аноним (-), 15:15, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Уже работает где-то? Хотеть такое в ffmpeg.
За VA-API не скажу, а x264 нынче умеет выносить некоторые операции через opencl, если он у вас есть. Нечто типа VA-API могло бы помочь причесать весь этот зоопарк.
| | |
| |
| 3.18, Аноним (-), 16:56, 01/10/2014 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Нечто типа VA-API могло бы помочь причесать весь этот зоопарк.
Не могло бы.
| | |
| 3.19, Психиатр (ok), 17:11, 01/10/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
 месяц назад тестил из интереса гитовый x264 собранный с OpenCL.
Оно медленне чем тупо только на CPU.
железо - i7-4770k + нывидия 760 (блоб, мать его)
насколько я понял x264 использует OpenCL не для самого кодирования, а для анализа (look-ahead).
если я не ошибаюсь только gstreamer умеет _кодировать_ с использованием GPU, только на AMD и со стопкой "левых" патчей.
| | |
| |
| |
| 5.31, Аноним (-), 22:07, 01/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Что это за кусок глючной бидонятины сыпящей ошибками? И почему результаты бенчей надо выискивать из скриншотов? На фоне таких авторов даже фороникс - профи экстра класса.
| | |
|
| 4.38, Аноним (-), 14:33, 02/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Так и есть, только в драйвере NVIDIA есть файл libnvidia-encode.so.340.24.
| | |
|
|
|
| 1.22, Аноним (-), 19:33, 01/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Для всех любителей аппаратного ускорения кодирования напоминаю, что каждая железка в каждый видеопоток вставляет свой еле заметный уникальный ватермарк. Пруфы найдёте сами.
| | |
| |
| 2.32, Аноним (-), 22:09, 01/10/2014 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Пруфы найдёте сами.
Круто. Громкую заяву делают одни, а обосновывать ее должны другие. Нормальный подход!
| | |
| |
| 3.35, irinat (ok), 23:34, 01/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Круто. Громкую заяву делают одни, а обосновывать ее должны другие. Нормальный подход!
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. | | |
| |
| 4.42, Аноним (-), 03:58, 05/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
А это нормально - когда спрашиваешь про кодировщик видео, пруфы для openssl почему-то подгоняют? Или это такое общее рассуждение на тему "как страшно жить"?
| | |
| |
| 5.43, irinat (ok), 12:28, 05/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> А это нормально - когда спрашиваешь про кодировщик видео, пруфы для openssl
> почему-то подгоняют? Или это такое общее рассуждение на тему "как страшно
> жить"?
Эх, читать разучился, что ли? Вот тебе суть вкратце: некий чел вбросил паранойи в тусовку на тему уязвимостей в коде. Несмотря на то, что он имел в виду уязвимость, которую он уже устранил, пара других челов нашла ещё уязвимость, о которой первый чел не знал.
А теперь суть по полочкам. Аноним в сообщении говорит о вставке вотермарков — чел по ссылке говорит об уязвимости. Ни тот, ни другой не имеют доказательств, просто набрасывают на вентилятор. Сообщество начинает копать. Кто-нибудь находит бяку.
Это было слишком сложно, да?
| | |
| |
| 6.44, Аноним (-), 01:21, 06/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
Проверяется очень легко: достаточно сравнить видеофайлы, полученные из нескольких аппаратных кодировщиков одной модели с одинаковыми входными данными. Различия в файлах означают наличие водяных знаков.
Отсутствие различий не гарантирует отсутствие водяных знаков, несущих информацию о модели и прошивке. Как проверить - не знаю, но это и не так страшно. Всего лишь ограничивает область поиска источника видео владельцами железок с данной моделью с прошивкой.
| | |
|
|
|
| 3.37, Аноним (-), 13:31, 02/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
По-прежнему ждём, что о нашей безопасности позаботится кто-то другой?
А мне пруфов и не надо. Ведь это так удобно - идентифицировать источник по видео или реенкоду.
| | |
| |
| 4.39, Аноним (-), 21:14, 04/10/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> По-прежнему ждём, что о нашей безопасности позаботится кто-то другой?
Добрый дядя позаботится
| | |
|
|
|
|
