Conception détaillée pour les éditeurs de logiciels indépendants (profil d’appareil photo V2)
La consommation des profils d’appareil photo 1507 pour les éditeurs de logiciels indépendants a présenté un défi important en raison de la nature complexe de la présentation des profils et du fait que les profils n’étaient qu’un jeu de données informatif, le pipeline sous-jacent permettait toujours des combinaisons de types de médias et de flux qui violaient les contraintes matérielles.
Les éditeurs de logiciels indépendants couraient toujours le risque de configurer le pipeline de capture d’une manière qui échouerait lorsque les flux étaient activés.
Pour le profil d’appareil photo V2, la configuration d’un profil sélectionné au moment de l’initialisation de l’objet Media Capture est communiquée au serveur Frame Server et le serveur frame n’expose que des combinaisons de flux/types de médias valides dans ce profil.
En raison du faible coût de création de plusieurs objets Media Capture lors du routage via le serveur Frame, une application peut précréer plusieurs instances d’objets Media Capture à l’aide de la même source. Seul le premier créé entraînerait une latence de création de source. Les instances suivantes prennent simplement la source déjà créée sur le serveur frame et filtrent l’ensemble de flux/types de médias en fonction du profil.
Une application qui souhaite exposer à la fois un mode Photo de haute qualité et un mode Enregistrement vidéo qui contient une vidéo à fréquence d’images élevée ou une vidéo 4K, peut créer plusieurs instances d’objets Media Capture configurés chacun avec un profil différent pour la même source d’appareil photo. Tant qu’un seul des objets Media Capture est activement diffusé en continu à un moment donné, le basculement entre un objet Media Capture entraîne peu de latence (généralement le coût de quelques appels RPC).
Le profil d’appareil photo 1507 expose les profils via l’objet MediaCaptureVideoProfile. Cet objet est découvert par le biais de la fabrique MediaCapture en fournissant un ID d’appareil spécifique. Cette vue centrée sur l’appareil signifie qu’une application qui souhaite activer un scénario spécifique doit d’abord énumérer/rechercher l’appareil de votre choix et l’utiliser pour itérer au sein des profils disponibles.
Le profil de caméra V2 étend la surface de l’API pour continuer à fournir une surface d’API centrée sur l’appareil, mais en plus de cela, Le profil d’appareil photo V2 fournit également une énumération de profil basé sur un scénario.
Au lieu de cela, en commençant par une caméra spécifique, une application commence par un scénario spécifique. Par exemple, enregistrement vidéo à l’aide d’un scénario de caméra universelle.
Ce point d’entrée fournit l’application de toutes les caméras disponibles qui conviennent à ce scénario. Selon la spécificité du scénario, la liste MediaFrameSourceGroup résultante peut contenir plusieurs entrées. Dans certains cas, il est possible qu’il n’y ait pas d’entrées. Par exemple, l’enregistrement vidéo à l’aide de la caméra universelle pour un appareil tout-en-un qui n’a pas de caméra universelle retourne un ensemble vide.
Le « langage » utilisé pour décrire le scénario permet des secours en fonction de critères minimaux. C’est la langue qui permet d’enregistrer des vidéos avec une préférence pour la caméra universelle et la résolution la plus élevée possible avec une fréquence d’images minimale de 30 images/s.
Filtrage basé sur un profil
L’un des principaux avantages de l’utilisation de l’architecture Frame Server est le fait que l’objet Client Context sur le serveur Frame, qui est une représentation virtuelle d’un objet Media Capture sur l’application cliente, est dissocié de la source physique.
Cela permet à plusieurs instances d’objets de contexte client utilisant la ou les mêmes source(s) d’être configurées dans des modes de fonctionnement spécifiques, ce qui peut inclure le filtrage des broches/types de médias susceptibles d’entrer en conflit avec le cas d’usage sous-jacent.
Étant donné que les sources d’appareils ne font pas partie du contexte client, la création de plusieurs instances d’objets de contexte client avec une configuration différente n’entraîne pas de surcharge significative (tout autant de surcharge nécessaire pour suivre les structures de données internes).
La latence de création/d’initialisation d’une source est toujours là pour le premier contexte client, mais une fois créées, les instances suivantes avec la même configuration ou une configuration différente n’entraînent que la surcharge supplémentaire liée à la création des structures de données internes.
Le diagramme suivant montre comment une capture de média configurée avec un profil Null serait exposée par Frame Server via le contexte client :
Dans le diagramme ci-dessus, chacune des sources expose trois broches : Aperçu, Capture et Photo. Et comme un profil Null a été défini, la capture multimédia résultante expose les neuf broches à l’application. L’application peut examiner chaque broche et chaque type de média disponible sur chaque broche.
Bien que cela offre de la flexibilité à l’application, cela complique également la gestion de la machine à états en déterminant quelle combinaison de types/broches de média peut être activée simultanément.
Toutefois, en utilisant le filtrage basé sur le profil :
L’application peut créer plusieurs instances de Media Capture, chacune configurée avec un profil spécifique. Dans le diagramme ci-dessus, le profil Null instance est laissé dans en tant qu’illustration. L’application peut choisir de ne pas créer le profil Null instance.
Les objets Media Capture inférieurs sont chacun configurés avec un profil spécifique. En fonction des informations de profil publiées par l’IHV/OEM des sources, le pipeline résultant n’extrait que les sources nécessaires.
Pour le profil HQ Photo World Facing, seules les broches Preview et Photo de world facing RGB (Source 3) sont exposées, ainsi que les types de supports indiqués par l’IHV/OEM pour les opérations de photo. Cela suppose que l’IHV/OEM a indiqué que pour HQ Photo, la capture simultanée n’est pas possible. Si la capture simultanée est autorisée, la broche capture, ainsi que les types de supports pouvant être utilisés pour les opérations simultanées de photo et d’enregistrement sont exposés.
Pour l’enregistrement orienté utilisateur, seules les broches Aperçu et Capture du RVB orienté utilisateur (Source 1) sont exposées. Là encore, le diagramme ci-dessus suppose que les opérations de photo ne sont pas possibles lorsque l’épingle capture est active.
Pour le profil Mixed Reality, les flux vidéo RVB et World Facing Perception sont exposés à l’application cliente. Et là encore, seuls les types de médias qui fonctionnent de manière simultanée sont mis à disposition.