Considérations pour les MFT de pilote sur les caméras à broches multiples (applications UWP pour périphériques)

Windows 8.1 offre aux IHV et aux OEM système la possibilité de créer des plug-ins de traitement vidéo sous forme de transformation de fondation multimédia (MFT), appelés MFT de pilote de caméra. Une fois installés, ces MFT de pilote peuvent être utilisés par les applications UWP pour périphérique pour activer des effets vidéo spéciaux. Certaines caméras fournissent des vues séparées pour l’aperçu, la capture et les photos fixes. Ces caméras multi-vues posent des problèmes uniques pour les développeurs. Cette rubrique aborde certains points à considérer lors du développement d’un MFT (Media Foundation Transform) de pilote de caméra sur une caméra multi-vues. Pour plus d’informations sur la création d’un MFT de pilote de caméra, consultez la rubrique Création d’un MFT de pilote de caméra.

Introduction

Le MFT de pilote est également appelé MFT0 pour indiquer qu’il s’agit du premier MFT à fonctionner dans le lecteur source. Une instance distincte de MFT0 est attachée à chaque broche sur la source de capture. Pour certains OEM système, le pilote de capture AVStream doit prendre en charge une broche de prévisualisation, une broche de capture et une broche fixe. Cela signifie qu’il peut y avoir trois instances de MFT0. Ce schéma illustre cette architecture, avec trois copies du plug-in IHV MFT, une pour chaque flux.

capture extension plug-in model in mf.

Les scénarios typiques pour MFT0 peuvent présenter des défis. Deux fonctions populaires pour MFT0 sont :

  • Analyse du flux vidéo pour fournir des commentaires à la caméra pour une capture améliorée (comme la mise au point automatique et l’exposition automatique basées sur l’hôte)

  • Ajout d’effets vidéo

Webcam à une broche

Historiquement, les caméras ont été exposées à Windows sous forme d’une seule broche de capture.Historiquement, les caméras ont été exposées à Windows sous la forme d’une seule broche de capture. Ce schéma représente le fonctionnement d’une webcam à une broche :

one-pin webcam.

Dans ce cas, à la fois le contrôle de la caméra et les effets vidéo fonctionnent comme prévu car la prévisualisation et les images fixes sont dérivées de la broche de capture après l’application du contrôle de la caméra et des effets vidéo. Le résultat est que le fichier enregistré ou l’interlocuteur de chat de l’utilisateur verra les mêmes effets vidéo que l’utilisateur voit dans sa prévisualisation, et qu’il n’y a qu’une seule instance de la fonction de contrôle de la caméra. S’il existe une application UWP pour appareil associée, l’application est connectée au MFT0 sur la broche de capture, de sorte que le MFT0 obtient les messages de contrôle de l’application (c’est-à-dire de l’utilisateur).

Webcam à trois broches

Une caméra à trois broches peut avoir jusqu’à trois instances de MFT0, en fonction des besoins de l’application. Ce schéma représente le fonctionnement d’une caméra à trois broches :

three-pin webcam.

Cette situation présente plusieurs défis. Tout d’abord, dans le cas d’une solution d’exposition automatique basée sur l’hôte, qui nécessite un contrôle direct des paramètres du capteur de caméra et de l’ISP, trois MFT0 peuvent essayer de contrôler la caméra en même temps. Cela casse le système de contrôle.

Ensuite, il y a potentiellement trois instances d’effets vidéo. Outre le coût de trois fois les calculs, les trois instances du MFT0 doivent maintenant communiquer de manière à ce que chaque trame vidéo ait toujours le même effet dans le même état. Sinon, ce que l’utilisateur voit ne sera pas ce qui est enregistré ou partagé.

De plus, il y a deux facteurs finaux aggravants :

  • Chaque instance du MFT0 peut être créée ou arrêtée à tout moment

  • L’application UWP pour appareil est connectée à une seule instance du MFT0

Vidéo compressée

Une webcam ou un OEM système peut choisir de compresser la vidéo avant qu’elle ne soit présentée sur la broche de capture (c’est-à-dire sur la webcam elle-même). Décharger la compression vers une webcam permet aux PC moins puissants de sauvegarder et de partager des vidéos HD. Ce flux vidéo compressé ne peut généralement pas être analysé pour prendre en charge le contrôle de la caméra, ni pour appliquer des effets vidéo. Cela pose le défi de faire comprendre à toutes les instances de MFT0 (et à l’application Microsoft Store, si elle est présente) qu’aucun effet ne sera appliqué au flux de capture. Ce schéma représente la vidéo compressée :

compressed video.

Si un utilisateur applique un effet vidéo au flux de prévisualisation, il ne peut pas être appliqué au flux de capture ou à la broche fixe. Par conséquent, l’utilisateur voit un effet vidéo qui n’est pas appliqué à la vidéo enregistrée ou diffusée. Si le flux de prévisualisation est interrompu, l’application Microsoft Store pour appareil essaiera alors de se connecter au flux de capture. Lorsqu’un utilisateur diffuse une vidéo compressée, cela ne permet pas de nombreuses fonctionnalités.

Communication entre les instances de MFT0

Si les trois instances de MFT0 peuvent communiquer entre elles, cela peut résoudre la plupart des problèmes. La manière dont ces instances se découvrent les unes les autres est à la discrétion de l’IHV. Une fois que tous les MFT0 peuvent communiquer, l’instance du MFT0 connectée à l’application Microsoft Store pour appareil peut informer les autres instances de l’effet appliqué et de son état actuel. De plus, les trois instances peuvent déterminer quelle instance applique le contrôle de la caméra. Enfin, la broche de prévisualisation peut déterminer si la broche de capture diffuse une vidéo encodée. La broche de prévisualisation peut alors désactiver les effets vidéo.

Bien que la communication entre les instances de MFT0 résolve les principaux problèmes d’expérience utilisateur, trois instances d’effets vidéo doivent toujours fonctionner simultanément. Certains effets vidéo peuvent utiliser la plupart des ressources CPU disponibles, notamment lors de la prévisualisation en plein écran et de la capture en même temps. Il s’agit de problèmes sérieux. Pour des raisons de performance, chaque ISV devrait considérer quel traitement peut être effectué une seule fois, comme la détection de visage, et partagé avec toutes les instances de MFT0.