Media sdk что это за программа
SDK и API: в чем разница?
Разработчики программного обеспечения пользуются основными инструментами: SDK и API. По сути, как SDK, так и API позволяют улучшить функционал приложений, не прибегая к большим усилиям.
Что такое SDK?
Аббревиатура SDK расшифровывается как software development kit. SDK, или devkit, — это набор средств для разработки ПО под определенную платформу. Он содержит компоновочные блоки, средства отладки, а зачастую фреймворк или группу библиотек кода, например набор подпрограмм для определенной операционной системы.
В стандартном SDK могут присутствовать как некоторые, так и все компоненты из списка ниже:
Как работает SDK
SDK предоставляет инструменты, которые способствуют ускорению и стандартизации разработки приложений.
Примеры использования SDK
SDK — неотъемлемая часть разработки мобильных приложений. SDK имеют множество областей применения:
Преимущества SDK
Что такое API?
Аббревиатура API расшифровывается как application programming interface (интерфейс программирования приложений). API — и как отдельное решение, и в составе SDK — облегчает обмен данными между двумя платформами и позволяет сторонним разработчикам использовать функционал проприетарного ПО.
API можно рассматривать как соглашение между двумя сторонами. API не только обеспечивает возможность обмена данными, но и устанавливает его правила.
Поскольку некоторые API предоставляют интерфейс напрямую, термины API и «интерфейс» иногда взаимозаменяемы.
Чтобы внести ясность, стоит отметить, что API может состоять из двух компонентов:
Что представляет вызов API с технической точки зрения:
Нужно ли выбирать между SDK и API?
Нет, ведь как сказано выше, SDK зачастую имеет по меньшей мере один API. Они выполняют разные функции, но могут работать и помогать вместе.
Следует иметь в виду, что с использованием API и SDK связаны некоторые сложности. Одна из них заключается в потенциальных уязвимостях. Другая сложность, относящаяся к SDK, — частота обновлений. Поэтому важно, чтобы команды DevOps держали вопрос информационной безопасности в поле зрения, а также следили за своевременным обновлением компонентов.
Оригинальный материал на английском языке доступен по ссылке.
Intel Media SDK стал open source проектом
В блоге Intel мы уже неоднократно рассказывали о Intel Media SDK — полезном наборе библиотек для аппаратно-ускоренного кодирования, декодирования и обработки видео данных. Сейчас, можно сказать, SDK стал для кого-то еще полезнее, ведь исходный код его базовой части открыли под лицензией MIT и выложили на GitHub. Пользуясь случаем, приведем краткое описание этого продукта.
Intel Media SDK позволяет кодировать с аппаратным ускорением видео в форматах HEVC, AVC, MPEG-2, JPEG; декодировать форматы HEVC, AVC, VP8, MPEG-2, VC1, JPEG. Список фильтров обработки в настоящее время включает преобразование цветов, деинтерлейсинг, понижение уровня шума, изменение размера, поворот кадра.
Для использования Intel Media SDK аппаратная платформа должна быть построена на базе
процессоров семейства Intel Xeon E3-1200 v4 с чипсетом C226, семейств Intel Xeon E3-1200 и E3-1500 v5 с чипсетом C236, либо процессоров Intel Core пятого и шестого поколения.
На сегодняшний день open source компоненты Intel Media SDK протестированы только с операционной системой CentOS 7.2; в планах сообщества — расширение поддерживаемых аппаратных и программных платформ. Для работы SDK требуется графический драйвер, устанавливаемый вместе с Intel Media Server Studio for Linux.
Открывая код Media SDK, Intel преследовала несколько целей: ускорить исправление ошибок и внедрение нового функционала, улучшить качество конечного продукта, сделать проще портирование на другие операционные системы. Надеемся, что все эти цели будут достигнуты.
Страница проекта на GitHub находится здесь. Другие open source проекты Intel смотрите на 01.org.
Повышение производительности мультимедиа приложений с помощью аппаратного ускорения
Вычислительная архитектура: от суперскалярной до разнородной
Чтобы оценить важность развития ГП, давайте начнем с истории совершенствования архитектуры ЦП.
Вернемся в девяностые годы. Первый серьезный этап в развитии — появление суперскалярной архитектуры, в которой была достигнута высокая пропускная способность за счет параллельной обработки на уровне инструкций в пределах одного процессора.
Рисунок 1. Суперскалярная архитектура
Рисунок 2. Многоядерная архитектура
Современная разнородная архитектура
В разнородной архитектуре может быть несколько процессоров, использующих общий конвейер данных, которые можно оптимизировать для отдельных функций кодирования, декодирования, преобразования, масштабирования, применения чересстрочной развертки и т. д.
Другими словами, благодаря этой архитектуре мы получили ощутимые преимущества как в области производительности, так и в области потребления электроэнергии, недоступные ранее. На рис. 3 показано развитие ГП за пять последних поколений: графические процессоры приобретают все более важное значение. И при использовании h.264, и при переходе на самые современные кодеки h.265 графические процессоры предоставляют значительную вычислительную мощность, благодаря которой обработка видео с разрешением 4K и даже с более высоким разрешением не только становится возможной, но и выполняется достаточно быстро.
Рисунок 3. Развитие разнородной архитектуры
Поколения производительности ГП
На рис. 4 показано резкое повышение вычислительной мощности всего за несколько поколений, в которых графические процессоры конструктивно размещались на одном кристалле с ЦП. Если в вашем приложении используется обработка мультимедиа, необходимо задействовать разгрузку на ГП, чтобы добиться ускорения в 5 раз или более (в зависимости от возраста и конфигурации системы).
Рисунок 4. Усовершенствование обработки графики в каждом поколении процессоров Intel
Приступая к программированию ГП
На шаге 1 обычно измеряется производительность H.264, чтобы можно было в дальнейшем оценивать изменение производительности по мере доработки кода. FFmpeg часто используется для измерения производительности и для сравнения скорости при использовании аппаратного ускорения. FFmpeg — очень мощный, но при этом достаточно простой в использовании инструмент.
На шаге 2 проводится тестирование с разными кодеками и в разных конфигурациях. Можно включить аппаратное ускорение, просто заменив кодек (замените libx264 на h264_qsv) на использующий Intel Quick Sync Video.
На шаге 3 добавлено использование Intel Media SDK.
Примечание. В этой публикации рассматривается использование этих инструментов в операционной системе Windows*. Если вас интересует реализация для Linux*, см. Доступ к Intel Media Server Studio для кодеков Linux с помощью FFmpeg.
▍Кодирование и декодирование FFmpeg
Начните с H.264 (AVC), поскольку h264: libx264 является программной реализацией в FFmpeg по умолчанию и выдает высокое качество исключительно программными средствами. Создайте собственный тест, затем снова измерьте производительность, сменив кодек с libx264 на h264_qsv. Позднее мы поговорим о кодеках H.265.
Если вы хотите поэкспериментировать с Quick Sync Video в FFmpeg, необходимо добавить libmfx. Самый простой способ установить эту библиотеку — использовать версию libmfx, упакованную разработчиком lu_zero.
Пример кодирования с аппаратным ускорением Quick Sync Video:
Кодек h264_qsv работает очень быстро, но видно, что даже самый медленный режим работы с аппаратным ускорением значительно быстрее только программного кодирования при самом низком качестве и самой высокой скорости.
При тестировании с кодеками H.265 вам потребуется либо получить доступ к сборке с поддержкой libx265, либо собрать собственную версию согласно инструкциям в Руководстве по кодированию для FFmpeg и H.265 или в документации X265.
Пример H.265:
Использование Intel Media SDK (sample_multi_transcode)
Рисунок 5. Примеры характеристик производительности H264 по отношению к целевому использованию
Используйте другие программные средства Intel
Для дальнейшей доработки кода можно использовать средства оптимизации и профилирования Intel, в том числе Intel Graphics Performance Analyzer (GPA) и Intel VTune Amplifier. Кроме того, инструменты Intel Video Pro Analyzer и Intel Stress Bitstreams and Encoder помогут добиться высокого качества видео и поточной передачи, улучшить работу кодировщиков и декодеров, а также ускорить проверку, чтобы можно было быстрее выпускать решения на рынок.
Заключение
Компьютерная архитектура претерпела значительные изменения за последние 20 лет, причем ее развитие лишь в течение последних пяти лет дало существенный рост производительности. Теперь ЦП Intel могут обрабатывать мультимедиа непосредственно на ГП, благодаря чему становятся доступными новые модели использования как для конечных потребителей, так и для компаний.
Вы можете самостоятельно измерить повышение производительности с помощью FFmpeg, а также дополнительно оптимизировать код с помощью бесплатных интерфейсов API Intel Media SDK. Переход от программной обработки к аппаратному ускорению повышает производительность системы и снижает расход электроэнергии (и затраты), а также предоставляет дополнительные вычислительные ресурсы, достаточные, чтобы со временем перейти на семейство кодеков H.265.
SDK тебе, SDK мне, SDK всем! Как делать SDK и зачем это нужно
Наша компания делает сервис для хранения и обработки данных с промышленных устройств (насосы, буры и прочая промышленная техника). Мы храним данные наших клиентов и предоставляем функционал для их анализа: построение отчетов, графиков и еще много чего.
И в ходе работы мы заметили, что интеграция каждого нового клиента сильно затягивается, а количество различных ошибок постоянно возрастает. Тогда стало понятно, что пора с этим разобраться. Как показал анализ ситуации, IT отдел каждого нашего клиента разрабатывал свое решение для локального сбора данных с устройств и отправки к нам в сервис. Все усложняет то, что с учетом специфики отрасли, не всегда есть доступ к интернету и необходимо хранить данные локально и отправлять при первой возможности. И таких нюансов достаточно большое количество, что и приводит к росту количества ошибок.
И тогда мы поняли, что лучшим решением в данной ситуации будет разработать SDK и предоставлять его клиенту. Сразу же начал искать лучшие практики и рассуждения на тему разработки SDK и сильно удивился — в рунете об этом практически ничего нет, а в басурманских интернетах очень мало информации и она разрознена. Ну что ж, задача понятна, обдумана и реализована.
Пора определяться
Начнем с того, что определим, что такое SDK и зачем он может быть нужен.
SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ. SDK использует преимущества каждой платформы и сокращает время на интеграцию.
…
Инженер-программист обычно получает SDK от разработчика целевой системы.
Что ж, логично. Простыми словами, SDK — это пакет библиотек, для того, чтобы клиент мог легко и быстро начать работать с вашей системой (в данной статье речь пойдет про наш сервис, но всё изложенное в статье применимо и к другим видам SDK) или выполнять однотипные действия.
Но, как и у любого подхода, у «Пути SDK» есть как преимущества, так и недостатки.
Преимущества
Высокая скорость интеграции нового клиента — вашим клиентам нужно писать меньше кода.
Переиспользование кода — один и тот же код используется сразу в нескольких местах. Можно сказать, что это дублирование предыдущего пункта, но речь идет о том, что логика работы везде одинокава, из чего следует
Предсказуемость поведения — использование одних и тех же библиотек приводит поведение систем к определенному стандарту, что сильно облегчает поиск и устранение ошибок и уязвимостей.
Качество кода — много где любят экономить на тестировании (жалко бюджета, горят сроки и прочие причины). Понятно, что в реальном мире покрыть тестами все участки проекта это учень трудоемкая задача. Но качественно протестировать все модули SDK, а затем использовать их — это путь повышения процента покрытия тестами, что приведет вас к снижению количества ошибок.
Документация — тот же сценарий, что и с тестами. Покрыть документацией весь проект достаточно проблематично. Переиспользование модулей SDK повышает процент покрытия документацией, что снижает порог вхождения новых сотрудников в проект и вообще помогает по жизни.
Все преимущества, по сути, это следствия самого главного — мы очень качественно пишем код один раз, а затем его переиспользуем.
Недостатки
Высокие требования к качеству кода SDK — следствие главного преимущества. Ошибка в SDK породит ошибки во всех системах, его использующих.
Установка ограничений — SDK — это набор библиотек для реализации стандартных сценариев. Иногда разработчики SDK полагают, что кроме реализации одного из предусмотренных сценариев клиенту ничего не потребуется, что клиенту проще сделать все с нуля самостоятельно, чем строить пьедестал из костылей для SDK.
Dependency hell и обновления — при расширении функционала (например, кастомизации решения под конкретного клиента), вы выпустите новую версию библиотеки. Но существуют зависимости, различные наборы версий библиотек у разных клиентов, и нужно очень тщательно следить за обратной совместимостью или строгим версионированием.
Когда SDK действительно нужен
У вас есть несколько стандартных сценариев, которые реализуются заново из раза в раз — собственно, наш случай.
Внутренние разработки — в разных проектах вы используете системы логирования, конфигурирования систем, работу с HttpRequest, БД, файлами? Выработайте внутренний SDK — набор библиотек для внутреннего использования. Вы в любой момент можете расширить функционал SDK, но скорость разработки новых проектов, процент покрытия тестами и документацией вырастет, а порог вхождения новых разработчиков снизится.
Когда SDK скорее всего будет лишним
Сценарии использования не определены или постоянно меняются — оставьте реализацию кастомных решений клиентам и помогите им. Не надо городить вундервафлю, которая будет только мешать. Очень актуально для молодых компаний и стартапов.
Вы не умеете делать качественно — у меня для вас плохая новость: пора учиться. Но отдавать кривое решение клиенту это очень, очень неправильно. Клиентов надо уважать, в конце концов.
Итак, мы определились, что такое SDK, с его преимуществами и недостатками и когда он нам нужен. Если после этого вы поняли, что SDK действительно нужен — приглашаю вас встать на «путь SDK» и разобраться, а каким он должен быть и как его, черт подери, делать?
«А вы любите Lego?» — Модульность
Представим все возможные сценарии использования SDK (вы же уже определились, зачем он вам нужен, правда?) и сделаем по библиотеке на сценарий. Чем не выход? Но это плохой подход, и так мы делать не будем. А будем так:
Например, с учетом специфики задачи, нам необходимо, чтобы вся логика задавалась из конфигов. Реализуем модуль работы с конфигами (чтения, записи, обновления, валидации и обработки конфигураций) и будем использовать его во всех остальных модулях.
А для реализации стандартных сценариев мы действительно сделаем модули — этакие «управляющие» модули, каждый из которых реализуют один конкретный сценарий, используя другие модули того же SDK. Таким образом для реализации стандартных сценариев клиент должен лишь подключить управляющий модуль сценария (а он сам подтянет все зависимости), а для реализации нестандартных — используем базовые модули, так же переиспользуя код.
Именно этим обусловлено то, что SDK не должен быть одной библиотекой (хотя очень хочется, понимаю. Ведь когда весь SDK в одной библиотеке, можно забыть о зависимостях и всем, что с ними связано), а быть комплектом библиотек. Дополнительным плюсом данного подхода будет уменьшение «веса» программы клиента — он будет тянуть тяжеловесный SDK, а подтянет только необходимые модули.
Но не стоить плодить модули как попало, ведь чем больше модулей, тем больше головной боли от их зависимостей! Т.е. важно правильно разбить логику на модули, соблюдая баланс между решением «все в одном» и «на каждую функцию свой модуль».
«А что, так можно было?!» — Универсальность
Предоставьте клиенту различные интерфейсы для работы с вашей библиотекой. Приведу пример:
Если предоставить только синхронную версию, то при реализации асинхронного приложения клиент вынужден будет делать асинхронные обертки вашего синхронного метода. Если предоставить только асинхронную версию — ситуация похожа. Дайте клиенту и то и другое и он скажет вам спасибо.
Приятным плюсом будут дженерики. Например, у нас есть класс для работы с конфигурациями, реализующий методы упаковки конфига в строку, загрузки конфига из файла и т.д. Конфигурация конкретного модуля будет наследоваться от нашего базового класса, но для работы с новым классом нам необходимо также предоставить методы распаковки.
Таким образом мы предоставили клиенту аж три реализации, которые он может использовать. Дженерики очень удобны, но при работе с динамическими типами их можно вызывать только через рефлексию, что накладно. Общий принцип универсальности, надеюсь, понятен.
«Родитель 1, Родитель 2, Дети[ ]» — Именование
Что самое трудное в работе программиста? Выдумывать имена для переменных.
И тем не менее… Правильное именование модулей, классов, свойств и методов сильно помогут тем, кто будут с вашим SDK работать. Пример, не требующих комментариев:
Kinect 2.0 SDK example
Всё ясно из названий классов и методов. А если есть автодополнение кода в вашей IDE, то зачастую можно и в документацию не заглядывать, если и так все понятно.
Но даже если у вас очень красиво и актуально названы все модули, классы, методы и свойства, документацию все равно необходимо написать. Во-первых, это очень сильно сбережет вам нервы (количество вопросов клиентов уменьшается на порядок. Все есть в документации), а во-вторых, всегда понятно, почему вы сделали так, а не иначе.
Документация, в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK.
Мы выбрали самый простой путь — summary + articles. Мы добавляем Xml атрибуты для методов и классов, которые светятся в intellisense как подсказки. Используя Docfx мы строим документацию по этим атрибутам и получаем подробную и удобную документацию, которую дополняет статьями, описывающими сценарии использования и примеры.
«— Чтобы чисто было! — Как я буду вилкой-то чистить?» — Тестирование
Что можно сказать про тестирование в рамках обсуждения SDK… Must have! Лучшим решением будет TDD (несмотря на то, что я негативно отношусь к данному подходу, в данном случае я решил использовать именно его). Да, долго. Да, нудно. Но зато в будущем вы не повеситесь от постоянных падений SDK на стороне и следствий этого падения.
Основной сок ситуации заключается в том, что отдавая SDK клиенту вы теряете контроль: вы не можете быстро пофиксить ошибку, сложно эту самую ошибку найти, да и выглядеть в такой ситуации вы будете достаточно глупо. Поэтому — тестируйте. Тестируйте лучше. И еще раз. И, на всякий случай, протестируйте ваши тесты. И тесты тестов. Так, что-то я увлекся, но важность тестирования SDK, надеюсь, понятна.
«Жертва, которая не могла противостоять своему прошлому, была поглощена им» — Логи
Поскольку вы отдаете SDK сторонней компании, в следствие чего теряете контроль над ситуацией, в случае ошибки (на этапе тестирования вы все-так решили «и так сойдёт», да?) вас ждет достаточно долгий и болезненный процесс поиск этой самой ошибки. Именно тут вам на помощь придут логи.
Логируйте все, абсолютно все, а в случае возникновения ошибки запросите у вашего клиента логи. Таким образом вы сэкономите много времени и сможете не потярять лицо перед клиентом.
«Alarm! Achtung! Attention!» — Ошибки
Долго размышляя на тему ошибок я пришел к интересному выводу — ни один метод в вашем SDK не должен отдавать ошибку, не описанную в документации. Согласитесь, очень неприятно, когда вы подключаете стороннюю библиотеку для работы с HttpRequest, а она вываливает на вас какой-нибудь NullPointerException и StackTrace, который уводит в недра библиотеки. И вам приходиться погружаться в эти самые «недра», пытаясь понять, насколько глубока кроличья нора, и в чем, собственно, проблема.
Поэтому я предлагаю следующее решение — декларируйте закрытый список возможных исключений и документируйте их. Но, т.к. нельзя быть увереннным, что вы предусмотрели все, оберните метод в try-catch, а пойманную ошибку — в задекларируему. Например, ConfigurationException, который будет содержать InnerException — пойманную ошибку. Это позволит стороннему разработчику поймать все возможные ошибки, но в случае чего быстро разобраться в чем дело.
Версии или «как не укусить себя за хвост»
Во избежание проблем в будущем крайне рекомендую использовать строгое версионирование. Выберете подходящую вам систему построения версий и используйте ее. Но если новая версия библиотеки не имеет обратной совместимости — это необходимо указать. Как это разруливать — думать вам. Но подумать об этом точно стоит.
«Паровозик, который смог» — Deploy
Необходимость актуальности документации и версий порождают требование к корректности деплоя. В своем решении мы используем следующее решение (костыли, но работают).
Когда надо выпустить нвый релиз, разработчик дергает bat’ник с указанием номера релиза, а затем батник:
На выходе получаем обновленную версию сайта с документацией, откуда можно скачать архив с последней версией SDK.
В планах на будущее — упаковка всего в Nuget пакеты и публикация в локальный Nuget репозиторий.
Рекоммендую обратить внимание на этот пункт, ведь вы можете существенно снизить количество головной боли, вызванной отсутствием актуальной информации о новой версии библиотеки.
«-А так можешь? — Фигня. Смотри как надо!» — Примеры & toolkit
Заключение
Разработка SDK стало для меня интересной новой задачей, поднявшей много важных архитектурных вопросов. Многое описанное в статье является очевидными вещами (для меня), но считаю важным огласить даже очевидные вещи, чтобы получить четкую общую картину.
Спасибо за прочтение, буду рад вашим комментариям. Надеюсь, эта статья будет для вас полезной.
990x.top
Простой компьютерный блог для души)
Windows SDK AddOn — что это за программа и нужна ли она?
Приветствую друзья! В Windows могут появиться программы, которые вы не устанавливали. Многих пользователей этим не удивишь, привыкли уже к такому беспределу)) Но откуда они берутся? Некоторые появились при установке других прог, некоторые установила сама Windows при обновлении, а третьи могут вообще быть вирусами или потенциально опасными, шпионскими там.. Но сегодня у нас пойдет речь про нормальную прогу для программистов))
Разбираемся
Windows SDK — пакет для создания приложений. В него входят новейшие заголовки, библиотеки, метаданные, и другие компоненты. Слово AddOn означает как дополнение, то есть дополнительный компонент.
Версия для Windows 10 позволяет создавать как классические, так и универсальные приложения.
Как я понимаю, классические приложения — это обычные привычные нам проги, которые можно скачать из интернета и установить. А вот универсальные — это уже метро-приложения, те самые модные плиточные проги, которые есть в меню пуск Windows 10, да и в Windows 8 они вроде тоже есть. Их еще можно скачать с магазина приложений (Microsoft Store).
Как пакет мог попасть на ПК:
Что интересно — разработка приложений UWP для десятки версии LTSB не поддерживается:
Инфа с офф сайта)
Версия для десятки, а точнее для билда 1809, содержит новые API-интерфейсы и обновленные средства для разработки приложений.
Вот картинка, видим что прога установлена среди остальных, но что главное — размер ее небольшой, всего 152 КБ:
Размер просто крохотный — поэтому можно оставить ее и не думать об удалении))
Тоже самое, но здесь прогу видим в списке окна Программы и компоненты:
Для вызова такого окна есть трюк — зажимаете Win + R, пишите команду appwiz.cpl, нажимаете ОК. В итоге откроется окно со списком установленного софта.
Установочное окно, где видим, то данная прога существовала еще во времена Windows XP:
Software Development Kit — набор средств разработки для программистов.
А вот и студия Visual Studio, где видим, что она при установке также может поставить Windows SDK:
Вывод — если вы программист — данный компонент у вас спокойно может быть.
Можно ли удалить данную программу?
Места на диске она занимает оч мало, но при этом является прогой от Майкрософт (значит точно безопасна). В процессах не висит, в автозагрузке ее тоже не должно быть.
Тем не менее, если вы хотите удалить прогу — лучше сначала сделать точку восстановления:
Команда откроет окошко Свойства системы.
Лично я советую удалять только при наличии точки восстановления! Это важно!