Diseño detallado para ISV (perfil de cámara V2)
El consumo de perfiles de cámara 1507 para ISV presentó un desafío significativo debido a la compleja naturaleza de cómo se presentaron los perfiles y el hecho de que los perfiles eran simplemente un conjunto de datos informativo, la canalización subyacente seguiría permitiendo combinaciones de tipos multimedia y secuencias que infringieron las restricciones de hardware.
Los ISV todavía corrían el riesgo de configurar la canalización de captura de una manera que produciría un error cuando se activaran las secuencias.
En el caso del perfil de cámara V2, la configuración de un perfil seleccionado en el momento de la inicialización del objeto De captura multimedia se comunicará al servidor de fotogramas y el servidor de fotogramas solo expondrá combinaciones de secuencias o tipos de medios que sean válidos dentro de ese perfil.
Debido al bajo costo de crear varios objetos de captura multimedia cuando se enrutan a través de Frame Server, una aplicación podría crear previamente varias instancias de objetos de captura multimedia con el mismo origen. Solo el primero creado incurriría en una latencia de creación de origen. Las instancias posteriores simplemente toman el origen ya creado en frame Server y filtran el conjunto de flujos o tipos de medios en función del perfil.
Una aplicación que desea exponer un modo foto de alta calidad y un modo de grabación de vídeo que contenga vídeo de alta velocidad de fotogramas o vídeo 4K, podría crear varias instancias de objetos De captura multimedia cada uno configurado con un perfil diferente para el mismo origen de cámara. Siempre y cuando solo uno de los objetos de captura multimedia esté transmitiendo activamente en un momento dado, el cambio entre el objeto De captura multimedia conlleva poca latencia (normalmente el costo de algunas llamadas RPC).
El perfil de cámara 1507 expone perfiles a través del objeto MediaCaptureVideoProfile. Este objeto se detecta a través de la factoría MediaCapture proporcionando un identificador de dispositivo específico. Esta vista centrada en dispositivos significa que una aplicación que desea habilitar un escenario específico tiene que enumerar o buscar primero el dispositivo que prefiera y usarlo para recorrer en iteración los perfiles disponibles.
El perfil de cámara V2 amplía la superficie de API para seguir proporcionando una superficie de API centrada en dispositivos, pero además de esto, el perfil de cámara V2 también proporcionará una enumeración de perfil controlada por escenarios.
En lugar de empezar con una cámara específica, una aplicación comienza con un escenario específico. Por ejemplo, grabación de vídeo mediante un escenario de cámara orientada al mundo.
Este punto de entrada proporciona la aplicación de todas las cámaras disponibles que son adecuadas para ese escenario. Dependiendo de la especificidad del escenario, la lista MediaFrameSourceGroup resultante puede contener varias entradas. En algunos casos, es posible que no haya entradas. Por ejemplo, la grabación de vídeo con la cámara orientada al mundo para un dispositivo todo en uno que no tenga una cámara orientada al mundo devolvería un conjunto vacío.
El "idioma" que se usa para describir el escenario permite reservas basadas en criterios mínimos. Ese es el lenguaje permite "Grabación de vídeo con una preferencia para la cámara orientada al mundo y resolución más alta posible con una velocidad de fotogramas mínima de 30 fps".
Filtrado basado en perfiles
Una de las principales ventajas de usar la arquitectura de Frame Server es el hecho de que el objeto Context de cliente en frame Server, que es una representación virtual de un objeto De captura multimedia en la aplicación cliente, se desacopla del origen físico.
Esto permite configurar varias instancias de objetos de contexto de cliente que usan los mismos orígenes en modos de operación específicos, lo que puede incluir el filtrado de patillas o tipos de medios que pueden entrar en conflicto con el caso de uso subyacente.
Dado que los orígenes de dispositivos no forman parte del contexto de cliente, la creación de varias instancias de objetos de contexto de cliente con una configuración diferente no incurre en ninguna sobrecarga significativa (tanta sobrecarga necesaria para realizar el seguimiento de las estructuras de datos internas).
La latencia para crear o inicializar un origen sigue estando ahí para el primer contexto de cliente, pero una vez creada, las instancias posteriores con la misma configuración o con una configuración diferente solo incurrirán en la sobrecarga adicional de crear las estructuras de datos internas.
En el diagrama siguiente se muestra cómo frame Server expondría una captura de medios configurada con un perfil NULO a través del contexto de cliente:
En el diagrama anterior, cada uno de los orígenes expone tres patillas: Vista previa, Captura y Foto. Y como se estableció un perfil nulo, la captura multimedia resultante expone los nueve pines a la aplicación. La aplicación puede examinar cada patilla y cada tipo de medio disponible en cada patilla.
Aunque esto proporciona flexibilidad a la aplicación, también aumenta la complejidad de administrar la máquina de estado que determina qué combinación de tipos o patillas de medios se pueden activar simultáneamente.
Sin embargo, mediante el filtrado basado en perfiles:
La aplicación puede crear varias instancias de Media Capture, cada una configurada con un perfil específico. En el diagrama anterior, la instancia de perfil null se deja como ilustración, la aplicación puede optar por no crear la instancia de perfil null.
Los objetos de captura multimedia inferiores se configuran con un perfil específico. En función de la información de perfil publicada por el IHV/OEM de los orígenes, la canalización resultante solo extraerá los orígenes necesarios.
Para el perfil HQ Photo World Facing, solo los pins Preview y Photo del World Facing RGB (Source 3) se exponen junto con solo los tipos multimedia que el IHV/OEM ha indicado funcionará para las operaciones de fotos. Esto supone que el IHV/OEM ha indicado que para la foto HQ, la captura simultánea no es posible. Si se permite la captura simultánea, se expone el pin Capture, junto con los tipos de medios que se pueden usar para las operaciones simultáneas de fotos y grabaciones.
En el caso de la grabación orientada al usuario, solo se exponen las patillas Vista previa y Captura del RGB orientado al usuario (origen 1). De nuevo, en el diagrama anterior se supone que las operaciones de fotos no son posibles cuando el pin de captura está activo.
Para el perfil de Mixed Reality, las secuencias de vídeo World Facing RGB y World Facing Perception se exponen a la aplicación cliente. Y de nuevo, solo los tipos de medios que están garantizados para funcionar simultáneamente están disponibles.