Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, reversecode, Вы писали:

R>>и с точки зрения маркетинга "более привлекательнее"
K>Специализированные решения буду ещё и более оптимальны и быстрее, но это уже заточка под архитектуру.


R>>чем то как я упомянул в посте на который вы ответили
K>Я пытаюсь понять в чём профит взять условный NVIDIA SDK, своять на нём и получить что-то что работает только на NVIDIA, но не на АМД и интел. С другой стороны, берётся ffmpeg и почти не меняя кода у нас есть поддержка nvidia, amd, mali, intel через тот же vaapi там, куда ffmpeg портирован, а портирован он много куда.

рассматривается кейс некоего транскодинга ?
если да, то условный ffmpeg может не покрывает сложных кейсов с кастомными настройками, некими другими функциями которых не вытянули в ffmpeg или багами в имплементации самого ffmpeg
амд кстати почему то многие уже забросили
intel с ваапи так себе, и он же квиксинк
nvidia набер ван по моим наблюжениям
с мали не сталкивался, но это скорее всего мобаил и делается это несколько по другому через интерфес который предоставляет сама ява андроида
или разве что какойто ембеддед без андроида

R>>кто может делает
R>>кто не может берет готовое
K>Но можно пересобрать ffmpeg без того что не нужно и он будет компактнее.

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

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