Подробный дизайн для независимых поставщиков программного обеспечения (Профиль Камеры Версия 2)

Использование профилей камеры 1507 для ISV представляет значительную проблему из-за сложного способа их представления и того факта, что профили представляли собой лишь информативные данные, базовый процесс всё равно позволял бы комбинации типов носителей и потоков, которые нарушали бы ограничения оборудования.

Поставщики ПО по-прежнему рискуют настроить цепочку обработки таким образом, что это может привести к ошибке при активации потоков.

Для профиля камеры версии 2 конфигурация выбранного профиля во время инициализации объекта захвата мультимедиа будет передана серверу кадра, а сервер кадров будет предоставлять только сочетания потоков или типов мультимедиа, допустимых в этом профиле.

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

Приложение, которое хочет предоставить как режим высококачественной фотографии, так и режим записи видео, содержащий видео с высокой частотой кадров или видео 4K, может создавать несколько экземпляров объектов захвата мультимедиа, настроенных с другим профилем для одного источника камеры. Если в данный момент времени только один из объектов захвата мультимедиа активно передаёт поток данных, переключение между объектами захвата мультимедиа вызывает небольшую задержку (как правило, стоимость нескольких вызовов RPC).

Профиль камеры 1507 предоставляет профили через объект MediaCaptureVideoProfile. Этот объект обнаруживается через фабрику MediaCapture путем предоставления определенного идентификатора устройства. Это представление, ориентированное на устройство, означает, что приложение, которое хочет включить определенный сценарий, необходимо сначала перечислить или найти выбранное устройство и использовать его для итерации с помощью доступных профилей.

Профиль камеры версии 2 расширяет API для продолжения предоставления API, ориентированного на устройство, но в дополнение к этому он также предоставит перечисление профилей, ориентированное на сценарии.

Вместо этого, начиная с конкретной камеры, приложение начинается с определенного сценария. Например, запись видео с помощью сценария камеры с видом на мир.

Эта точка входа предоставляет приложение всех доступных камер, подходящих для этого сценария. В зависимости от конкретности сценария результирующий список MediaFrameSourceGroup может содержать несколько записей. В некоторых случаях может не быть записей. Например, видеозапись с использованием наружной камеры для устройства All-In-One, которое не имеет такой камеры, будет возвращать пустой набор.

Язык, используемый для описания сценария, позволяет резервным вариантам на основе минимальных критериев. Этот язык позволяет "Запись видео с предпочтением камеры, направленной в сторону мира, и максимально возможным разрешением с минимальной частотой кадров не менее 30 fps".

Фильтрация на основе профиля

Одним из основных преимуществ использования архитектуры Frame Server является тот факт, что объект "Контекст клиента" на сервере frame, который является виртуальным представлением объекта "Захват мультимедиа" в клиентском приложении, отделяется от физического источника.

Это позволяет настроить несколько экземпляров объектов контекста клиента с использованием одного источника в определенных режимах операции, которые могут включать фильтрацию пин-кодов или типов носителей, которые могут конфликтовать с базовым вариантом использования.

Так как источники устройств не являются частью контекста клиента, создание нескольких экземпляров объектов контекста клиента с другой конфигурацией не приводит к значительным затратам (так же, как и много накладных расходов, необходимых для отслеживания внутренних структур данных).

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

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

Профиль не задан.

На приведенной выше схеме каждый из источников предоставляет три контакта: предварительный просмотр, съемка и фотография. И поскольку был задан пустой профиль, результирующий медиазахват предоставляет доступ ко всем девяти контактам для приложения. Приложение может проверять каждый пин и каждый тип медиа, доступный на каждом контакте.

Хотя это обеспечивает гибкость приложения, оно также усложняет управление конечным автоматом, определяющим, какое сочетание типов медиа и контактов может быть активировано одновременно.

Тем не менее, используя фильтрацию на основе профилей:

Фильтрация на основе профиля.

Приложение может создавать несколько экземпляров записи мультимедиа, каждая из которых настроена с определенным профилем. На приведенной выше схеме экземпляр профиля NULL остается на рисунке, приложение может не создать экземпляр профиля NULL.

Более низкие объекты захвата мультимедиа настраиваются с определенным профилем. На основе сведений профиля, опубликованных IHV/OEM источников, полученный конвейер будет извлекать только необходимые источники.

Для профиля HQ Photo с лицевая ориентация будут предъявлены только значки предварительного просмотра и Фото RGB (Источник 3), а также только типы носителей, которые IHV/OEM указали как подходящие для операций с фотографиями. Предполагается, что IHV/OEM указали, что для HQ Photo одновременная съемка невозможна. Если допускается одновременный захват, пин-код захвата, а также типы носителей, которые можно использовать для одновременных операций фото и записи, предоставляются.

Для пользователя записи будут доступны только предварительный просмотр и закрепление пин-кода RGB (источник 1). Опять же, на приведенной выше схеме предполагается, что фотографические действия невозможны при активном Capture pin.

Для профиля смешанной реальности видеопотоки "Мир, ориентированный на RGB" и "Мир, ориентированный на восприятие" будут предоставляться клиентскому приложению. И снова доступны только типы мультимедиа, которые гарантированно работают одновременно.

спецификация разработчика профиля камеры версии 2