Guide de conception Device MFT

La pile de capture vidéo dans Windows prend en charge une extension en mode utilisateur sous la forme de DMFT. Il s’agit d’un composant d’extension par dispositif fourni par les IHVs, et le pipeline de capture l’insère comme première transformation, après la capture. Le DMFT reçoit des cadres post-traités du dispositif. D’autres opérations de post-traitement sur les cadres peuvent être effectuées à l’intérieur du DMFT. Le DMFT peut recevoir des cadres de tous les flux du dispositif et il peut exposer un nombre quelconque de flux de sortie selon les besoins.

Cet article présente la conception d’une extension pour l’ensemble du dispositif fonctionnant en mode utilisateur, pouvant être utilisée pour effectuer un post-traitement commun à tous les flux.

Terminologie

Objectifs de conception

• Extension en mode utilisateur pour l’ensemble du filtre de dispositif ayant la même durée de vie que le filtre de dispositif

• Prend en charge un nombre quelconque d’entrées provenant du dispositif

• Prend en charge un nombre quelconque de sorties (le besoin actuel est de trois flux : aperçu, enregistrement et photo)

• Routage de tous les contrôles du dispositif vers Device MFT de dispositif (qui les gère éventuellement ou les transmet au dispositif)

• Post-traitement parallèle du flux capturé

• Permet un traitement 3A indépendant du taux de trames

• Permet de partager des métadonnées entre différents flux

• Accès aux ressources GPU

• Accès aux files d’attente de travail MMCSS de MF

• Accès à l’allocation de MF

• Interface simple (similaire à MFT)

• Architecture interne flexible pour l’extensibilité des IHV/OEM

Contraintes de conception

• Aucun changement dans la surface de l’API de capture

• Compatibilité totale avec les versions antérieures. Par exemple, aucune régression lors du travail avec des applications et des scénarios hérités.

Architecture de la pile de capture

Cet article décrit la prise en charge d’une extension en mode utilisateur pour l’ensemble du filtre de capture. Ce composant a accès aux API MF, aux pools de threads, aux ressources GPU et ISP. L’extension pour l’ensemble du filtre offre la flexibilité d’avoir un nombre quelconque de flux entre elle et le filtre Ks du dispositif. Cette flexibilité permet une communication hors bande transparente entre l’extension en mode utilisateur et le pilote, pouvant être utilisée pour des flux de métadonnées et de traitement 3A dédiés.

Gestionnaire de transformation de dispositif (DTM)

La pile de capture introduit un nouveau composant fourni par le système, le Gestionnaire de transformation de dispositif (DTM). Il réside à l’intérieur de DeviceSource et gère Devproxy MFT et Device MFT. DTM effectue la négociation des MediaTypes, la propagation des échantillons et toute la gestion des événements MFT. Il expose également l’interface IMFTransform à DeviceSource et autres interfaces privées nécessaires que DeviceSource doit gérer pour les flux de dispositif. Ce composant abstrait Devproxy et Device MFT du pipeline. Le pipeline ne voit que le DTM comme le dispositif et les flux provenant du DTM comme les flux d’appareil.

Devproxy

Devproxy est un MFT asynchrone qui assure la médiation des commandes et des trames vidéo entre le pilote de la caméra AVStream et Media Foundation. Ce dernier est fourni par Windows et prend en charge n sorties du pilote de la caméra. Il possède également les allocateurs pour toutes les broches exposées par le dispositif.

MFT de dispositif

Device MFT est une extension en mode utilisateur pour le pilote de capture. C’est un m x n MFT asynchrone. Il est installé sur le système avec le pilote de capture et est fourni par le fournisseur de pilote de capture.

Le nombre de flux d’entrée du Device MFT doit être identique au nombre de broches Ks exposées par le dispositif. Les types de média pris en charge par les flux d’entrée du Device MFT doivent être identiques à ceux exposés par les broches KS.

Le nombre de flux de sortie exposés par le Device MFT sont les flux vus par DeviceSource et la pile de capture, l’API de capture et les applications, et peuvent être un, deux ou trois flux. Les nombres de flux d’entrée et de sortie du Device MFT n’ont pas besoin d’être identiques. De plus, les flux d’entrée et de sortie n’ont pas besoin d’avoir les mêmes types de média, et ont généralement des types de média différents. Les nombres de types de média n’ont pas besoin de correspondre non plus.

La première broche Ks représentée en mode utilisateur par le flux de sortie de Devproxy est associée au premier flux d’entrée du Device MFT, la deuxième broche Ks représentée en mode utilisateur par le flux de sortie de Devproxy au deuxième flux d’entrée du Device MFT, et ainsi de suite.

Le Device MFT reçoit un pointeur vers Devproxy, l’appareil DX et l’ID de la file d’attente de travail de MF. Les trames provenant du dispositif sont directement introduites dans l’entrée correspondante du Device MFT sous forme d’échantillons MF. Avec tout cela, le Device MFT peut post-traiter les échantillons capturés et servir des échantillons aux broches d’aperçu, d’enregistrement et de photo.

Toutes les commandes et contrôles allant au dispositif sont redirigés vers le Device MFT. Le Device MFT gère les contrôles ou les transmet au pilote via Devproxy. Cela rationalise la gestion des commandes par la pile de pilotes de capture.

Vue d’ensemble fonctionnelle

Lors de l’initialisation du pipeline de capture, s’il existe un Device MFT, DeviceSource instancie DTM. Il passe une instance de Devproxy représentant le dispositif à la routine d’initialisation de DTM. DTM co-crée Device MFT et effectue des validations de base, par exemple, vérifie que le nombre de broches de sortie de Devproxy est identique au nombre de broches d’entrée de Device MFT, prend en charge les interfaces obligatoires, etc.

DeviceSource interroge DTM pour obtenir les types de média de sortie pris en charge. DTM obtient cela à partir des broches de sortie du Device MFT. DeviceSource expose le descripteur de présentation et le descripteur de flux basé sur ces informations au pipeline de capture.

SourceReader utilise les types de média exposés de DeviceSource et définit les types de média par défaut sur chaque flux. En retour, DeviceSource définit les types de média par défaut sur les flux de sortie de DTM. DTM définit le type de média sur le flux de sortie du Device MFT en utilisant la méthode SetOutputStreamState.

Lorsque SetOutputStreamState est appelé, le Device MFT poste un message à DTM pour changer le type de média de son flux d’entrée en fonction du type de média de sortie sélectionné et attend. En réponse à ce message, DTM interroge le type de média d’entrée préféré pour le flux d’entrée du Device MFT en utilisant GetPreferredInputStreamState. Cela définit le type de média sur le flux de sortie correspondant de Devproxy. Si cela réussit, alors DTM définit ce même type de média sur le flux d’entrée du Device MFT en utilisant SetInputStreamState. Après avoir reçu cet appel, le Device MFT complète SetOutputStreamState.

CaptureEngine sélectionne les flux individuels en activant des flux spécifiques sur DeviceSource. Cela est propagé au Device MFT par DTM via un appel SetOutputStreamState. Le Device MFT place les flux de sortie spécifiques dans l’état demandé. Comme mentionné ci-dessus, le Device MFT informe également DTM des flux d’entrée nécessaires qui doivent être activés. Cela entraîne la propagation de la sélection de flux à Devproxy par DTM. À la fin de ce processus, tous les flux nécessaires, dans Devproxy et Device MFT, sont prêts à diffuser.

SourceReader démarre DeviceSource lorsque CaptureEngine appelle ReadSample. En retour, DeviceSource démarre DTM en envoyant les messages MFT_MESSAGE_NOTIFY_BEGIN_STREAMING et MFT_MESSAGE_NOTIFY_START_OF_STREAM indiquant le début du pipeline. DTM démarre Devproxy et Device MFT en propageant les messages MFT_MESSAGE_NOTIFY_BEGIN_STREAMING et MFT_MESSAGE_NOTIFY_START_OF_STREAM.

DTM appelle SetOutputStreamState sur les sorties du Device MFT avec le paramètre d’état de diffusion. Le Device MFT commence à diffuser dans ces flux de sortie. DTM démarre la diffusion sur les flux de sortie de Devproxy ayant des types de média valides définis. Devproxy alloue les échantillons et les récupère du dispositif. Ces échantillons sont introduits dans le Device MFT par la broche d’entrée correspondante. Le Device MFT traite ces échantillons et les donne à DeviceSource. De DeviceSource, les échantillons passent par SourceReader jusqu’à CaptureEngine.

CaptureEngine arrête les flux individuels en désactivant les flux individuels via une interface interne sur DeviceSource. Cela est traduit par la désactivation de flux de sortie spécifiques sur le Device MFT via SetOutputStreamState. En retour, le Device MFT peut demander la désactivation de flux d’entrée spécifiques via l’événement METransformInputStreamStateChanged. DTM propage cela aux flux correspondants de Devproxy.

Tant que le Device MFT lui-même est en état de diffusion, il peut demander à n’importe quel flux d’entrée de passer à l’un des états valides de DeviceStreamState. Par exemple, il pourrait l’envoyer à DeviceStreamState_Stop ou DeviceStreamState_Run ou DeviceStreamState_Pause, etc., sans affecter les autres flux.

Cependant, la transition de flux de sortie est contrôlée par le pipeline de capture. Par exemple, les flux d’aperçu, d’enregistrement et de photo sont activés ou désactivés par le pipeline de capture. Même lorsque les sorties sont désactivées, un flux d’entrée pourrait encore être en cours de diffusion tant que le Device MFT lui-même est en état de diffusion.

Durée de vie du Device MFT

Le Device MFT est chargé après la création du filtre KS. Il est déchargé avant la fermeture du filtre KS.

Du point de vue du pipeline, lorsque DeviceSource est créé, le Device MFT est créé, et lorsque DeviceSource est arrêté, le Device MFT est arrêté de manière synchrone.

Pour prendre en charge l’arrêt, le Device MFT doit prendre en charge l’interface IMFShutdown. Après que Device MFT->Shutdown soit appelé, tout autre appel d’interface dans le Device MFT doit renvoyer une erreur MF_E_SHUTDOWN.

Type de mémoire

Les trames peuvent être capturées dans des tampons de mémoire système ou des tampons de mémoire DX, selon la préférence du pilote de la caméra. Quel que soit le tampon provenant du pilote de la caméra, il est directement introduit dans le Device MFT pour un traitement ultérieur.

Devproxy alloue les tampons en fonction de la préférence du pilote. Nous demandons au Device MFT d’utiliser les API d’allocation MF pour allouer les échantillons nécessaires pour ses broches de sortie pour les transformations non in-place.

Changement de type de média en cours de diffusion

Les clients de SourceReader peuvent voir les types de média exposés par les flux de sortie du Device MFT comme des types de média pris en charge nativement. Lorsque le type de média natif est modifié, SourceReader envoie des appels de notification de type de média dans le Device MFT via DeviceSource. Il est de la responsabilité du Device MFT de purger tous les échantillons en attente de la file d’attente de ce flux et de passer au nouveau type de média sur ce flux en temps opportun. S’il est nécessaire de changer le type de média d’entrée, il doit alors changer le type de média d’entrée actuel pour celui-ci. DTM obtient le type de média actuel à partir du flux d’entrée du Device MFT et le définit sur les flux de sortie de Devproxy et l’entrée du Device MFT après chaque changement de type de média natif.

Changement de type de média d’entrée dans le Device MFT

Étant donné qu’il s’agit d’un m x n MFT, il peut y avoir des répercussions sur les types de média et les changements d’état des broches de diffusion d’entrée lorsque les types de média ou les états des broches de diffusion de sortie changent. En particulier lorsque les changements suivants se produisent :

• Changements de type de média de sortie

  • Lorsqu’une application modifie le type de média natif, cela se répercute à travers la pile de capture dans le Device MFT sous forme de changement de type de média de broche de sortie.

  • Lorsque le type de média de sortie change, cela peut déclencher un changement de type de média d’entrée. Par exemple, supposons que toutes les broches de sortie diffusent en 720p. Cela entraîne la diffusion depuis la caméra en 720p. Ensuite, supposons que le flux d’enregistrement change son type de média natif en 1080p. Dans ce cas, un des flux d’entrée du Device MFT qui fournissait des données au flux d’enregistrement devra changer son type de média.

• La broche de sortie est désactivée

  • Lorsqu’une application désactive une des sorties du Device MFT alors que la même entrée est partagée par plusieurs sorties, pour optimiser, l’entrée peut devoir changer le type de média. Par exemple, si un flux de sortie 1080p s’arrête, et que tous les autres flux, partageant une entrée, diffusent en 720p, alors le flux d’entrée devrait changer son type de média en 720p pour économiser de l’énergie et améliorer les performances.

DTM gère les notifications METransformInputStreamStateChanged du Device MFT pour changer le type de média et l’état sur l’entrée du Device MFT et la sortie de Devproxy dans ces conditions.

Types de média de sortie préférés du Device MFT

Nous recommandons que le Device MFT produise des types de média de sortie utilisant le format NV12. YUY2 est la meilleure alternative suivante. Les types de média MJPEG et RGB ne sont pas recommandés.

Purger le Device MFT

Deux types de purge sont nécessaires lors de la gestion du Device MFT :

• Purge globale

  • Purge à l’échelle du Device MFT. Cela se produit généralement lorsque DTM est sur le point d’envoyer un message d’arrêt de diffusion au Device MFT.

  • Le Device MFT doit abandonner tous les échantillons de ses files d’attente d’entrée et de sortie et retourner de manière synchrone.

  • Le Device MFT ne doit pas demander de nouvelles entrées ni envoyer de notification sur une nouvelle sortie disponible.

• Purge locale

  • Purge spécifique à la broche de sortie. Cela se produit généralement lorsqu’un flux est arrêté.

Tous les événements postés avant la purge sont abandonnés par le gestionnaire du Device MFT. Après la purge, le Device MFT réinitialise son compte de suivi interne METransformHaveOutput.

Vidage du Device MFT

Le Device MFT ne recevra pas de message de vidage séparé puisqu’il n’y a pas besoin de vidage dans une source de capture en direct.

Déclencheur de photo

Dans ce modèle, au lieu d’envoyer directement le déclencheur de photo et les déclencheurs de début et de fin de séquence photo au pilote, ils sont redirigés vers le Device MFT. Le Device MFT gère le déclencheur ou le transmet au besoin au pilote de la caméra.

Démarrage rapide

DeviceSource tente de démarrer rapidement un flux de sortie spécifique en passant le flux à l’état de pause. En retour, DTM appelle la méthode IMFDeviceTransform::SetOutputStreamState sur le Device MFT pour passer un flux de sortie spécifique à l’état de pause. Cela entraîne la mise en pause du flux d’entrée correspondant. Cela est réalisé par le Device MFT en demandant METransformInputStreamStateChanged à DTM et en gérant la méthode IMFDeviceTransform::SetInputStreamState.

Séquence photo variable

Avec cette architecture, la séquence photo est mise en œuvre avec le pilote du dispositif de la caméra et le Device MFT, réduisant considérablement la complexité du pilote du dispositif de la caméra. Les déclencheurs de début et de fin de séquence photo sont envoyés au Device MFT et gèrent la séquence photo plus facilement.

Confirmation de photo

Le Device MFT prend en charge la confirmation de photo via l’interface IMFCapturePhotoConfirmation. Le pipeline récupère cette interface via la méthode IMFGetService::GetService.

Métadonnées

Devproxy interroge le pilote pour connaître la taille du tampon de métadonnées et alloue la mémoire pour les métadonnées. Les métadonnées provenant du pilote sont toujours définies par Devproxy sur l’échantillon. Le Device MFT consomme les métadonnées de l’échantillon. Les métadonnées peuvent soit être transmises avec l’échantillon via son flux de sortie, soit être utilisées pour son post-traitement.

Avec le Device MFT prenant en charge un nombre quelconque d’entrées, une broche d’entrée dédiée pourrait être utilisée juste pour les métadonnées ou les métadonnées hors bande. Le type de média pour cette broche est personnalisé et le pilote décide de la taille et du nombre de tampons.

Ce flux de métadonnées est exposé au-delà de DTM. Le flux peut être mis en état de diffusion lorsque le Device MFT commence à diffuser. Par exemple, lorsque les flux de sortie sont sélectionnés pour la diffusion, le Device MFT peut demander à DTM de démarrer un ou plusieurs flux vidéo, ainsi que le flux de métadonnées, en utilisant l’événement METransformInputStreamStateChanged.

Remarque : Il n’est pas nécessaire que le nombre de broches d’entrée corresponde au nombre de broches de sortie dans ce modèle. Il peut y avoir une broche séparée dédiée aux métadonnées ou 3A.

Gestion des événements du Gestionnaire de transformation de dispositif (DTM)

Les événements du Gestionnaire de transformation de dispositif sont définis dans les articles de référence suivants :

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

Interface IMFDeviceTransform

L’interface IMFDeviceTransform est définie pour interagir avec le Device MFT. Cette interface facilite la gestion de m entrées et n sorties de Device MFT. Avec d’autres interfaces, le Device MFT doit implémenter cette interface.

Propagation générale des événements

Lorsqu’un événement se produit dans Devproxy (ou à l’intérieur du dispositif), nous devons le propager au Device MFT et à DeviceSource.

Exigences pour les Device MFT

Exigences d’interface

Les Device MFT doivent prendre en charge les interfaces suivantes :

• IMFDeviceTransform

• IKsControl

  • Cela permet à toutes les ksproperties, événements et méthodes de passer par le Device MFT. Cela donne au Device MFT la capacité de gérer ces appels de fonction à l’intérieur du Device MFT ou de simplement les transmettre au pilote. Dans le cas où il gère les méthodes KsEvent, alors le Device MFT doit effectuer les étapes suivantes :

    • Si le Device MFT gère un événement KSEVENT_TYPE_ONESHOT, alors il duplique le handle lorsqu’il reçoit KSEVENT_TYPE_ENABLE.

    • Lorsqu’il a terminé de définir ou de lever l’événement, il appelle CloseHandle sur le handle dupliqué.

    • Si le Device MFT gère des événements non KSEVENT_TYPE_ONESHOT, alors il doit dupliquer le handle lorsqu’il reçoit KSEVENT_TYPE_ENABLE et appeler CloseHandle sur le handle dupliqué lorsque l’événement ks est désactivé en appelant la fonction KsEvent avec le premier paramètre (ID de l’événement ks) et le deuxième paramètre (longueur de l’événement) définis à zéro. Les données de l’événement et la longueur sont valides. Les données de l’événement identifient de manière unique un événement ks spécifique.

    • Si le Device MFT gère des événements non KSEVENT_TYPE_ONESHOT, alors il doit dupliquer le handle lorsqu’il reçoit KSEVENT_TYPE_ENABLE et doit appeler CloseHandle sur les handles dupliqués lorsque les événements ks sont désactivés en appelant la fonction KsEvent avec tous les paramètres définis à zéro.

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• IMFShutdown

• IMFSampleAllocatorControl

Exigences de notification

Les Device MFT doivent utiliser les messages suivants pour informer DTM de la disponibilité des échantillons, de tout changement d’état de flux d’entrée, etc.

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

Exigences de thread

Le Device MFT ne doit pas créer ses propres threads. Il doit plutôt utiliser les files d’attente de travail Media Foundation, qui sont allouées en fonction de l’ID passé au DMFT via l’interface IMFRealTimeClientEx. Cela permet de s’assurer que tous les threads exécutés dans le Device MFT obtiennent la priorité correcte à laquelle le pipeline de capture fonctionne et évite les inversions de priorité de thread.

Configuration requise pour InputStream

Nombre de flux

• Le nombre de flux d’entrée dans le Device MFT doit être le même que le nombre de flux pris en charge par le pilote.

MediaTypes

• Le nombre de types de média et les types de média réels pris en charge par l’entrée du Device MFT doivent correspondre au nombre et aux types de média pris en charge par le pilote.

• Le nombre pourrait être différent uniquement si les types de média pris en charge par l’entrée du Device MFT sont un sous-ensemble des types de média pris en charge par le pilote.

• Les types de média pris en charge par le pilote et l’entrée du Device MFT pourraient être des types de média standard ou personnalisés.

Comment enregistrer le Device MFT

Le fichier INF du dispositif de caméra doit avoir l’entrée d’interface de dispositif suivante qui spécifie le CLSID de la CoClass du Device MFT.

[CaptureAvstrm.Device.NTarm.Interfaces]
AddInterface = %KSCATEGORY_VIDEO_CAMERA%, %Capture.FilterDescBack%, Capture.FilterBack

[Capture.FilterBack]
AddReg = Capture.FilterBack.AddReg, PinNames.AddReg

[Capture.FilterBack.AddReg]
HKR,,FriendlyName,,%Capture.FilterDescBack%
HKR,,CameraDeviceMftClsid,,%CameraDeviceMFT.Clsid%

Ces entrées INF résultent en l’enregistrement des clés de registre suivantes :

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{E5323777-F976-4f5b-9B55-B94699C46E44}\##?#USB#VID_045E&PID_075D&MI_00#8&23C3DB65&0&0000#{E5323777-F976-4f5b-9B55-B94699C46E44}\#GLOBAL\Device Parameters]
"CLSID"="{17CCA71B-ECD7-11D0-B908-00A0C9223196}"
"FriendlyName"="USB Video Device"
"CameraDeviceMftClsid"="{3456A71B-ECD7-11D0-B908-00A0C9223196}"<<< Device MFT CoClass ID >>>

Chaînage du Device MFT

Le Device MFT est le mécanisme de plugin en mode utilisateur recommandé pour les IHVs et OEMs pour étendre la fonctionnalité de la caméra sous Windows.

Avant Windows 10, version 1703, le pipeline de la caméra ne prenait en charge qu’un seul plugin d’extension DMFT.

À partir de Windows 10, version 1703, le pipeline de la caméra de Windows prend en charge une chaîne optionnelle de DMFTs avec un maximum de deux DMFTs.

À partir de Windows 11, version 22H2, le pipeline de la caméra de Windows prend en charge une chaîne optionnelle de DMFTs avec un maximum de quatre DMFTs.

Cela offre une plus grande flexibilité aux OEMs et IHVs pour fournir une valeur ajoutée sous la forme de flux de caméra de post-traitement. Par exemple, un dispositif pourrait utiliser PDMFT ainsi qu’un DMFT d’IHV et un DMFT d’OEM.

La figure suivante illustre l’architecture impliquant une chaîne de DMFTs.

Les échantillons de capture passent du pilote de la caméra à DevProxy, puis traversent les chaînes de DMFT. Chaque DMFT dans la chaîne a la possibilité de traiter l’échantillon. Si le DMFT ne souhaite pas traiter l’échantillon, il peut agir comme un simple relais et transmettre l’échantillon au DMFT suivant.

Pour les contrôles comme KsProperty, l’appel remonte le flux - le dernier DMFT dans la chaîne reçoit l’appel en premier. L’appel peut être traité là ou transmis au DMFT précédent dans la chaîne.

Les erreurs sont propagées du DMFT à DTM puis aux applications. Pour les DMFTs IHV/OEM, l’échec de l’instanciation de l’un des DMFTs est une erreur fatale pour DTM.

Exigences pour les DMFTs :

• Le nombre de broches d’entrée du DMFT doit correspondre au nombre de broches de sortie du DMFT précédent. Sinon, DTM échouerait lors de l’initialisation. Cependant, les nombres de broches d’entrée et de sortie du même DMFT n’ont pas besoin de correspondre.

• Le DMFT doit prendre en charge les interfaces - IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl et IMFMediaEventGenerator; IMFTransform peut être nécessaire si MFT0 est configuré ou si le DMFT suivant dans la chaîne nécessite la prise en charge d’IMFTransform.

• Sur les systèmes 64 bits qui n’utilisent pas Frame Server, les DMFTs 32 bits et 64 bits doivent être enregistrés. Étant donné qu’une caméra USB pourrait être branchée sur un système arbitraire, pour les caméras USB « externes » (ou non incluses), le fournisseur de la caméra USB doit fournir des DMFTs 32 bits et 64 bits.

Configurer la chaîne DMFT

Un dispositif de caméra peut éventuellement fournir un objet COM DMFT dans une DLL en utilisant un fichier INF personnalisé qui utilise des sections du fichier INF USBVideo inclus.

Dans la section « Interface AddReg » du fichier .INF personnalisé, spécifiez les CLSID des DMFTs en ajoutant l’entrée de registre suivante :

CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%

Comme indiqué dans les paramètres d’exemple INF ci-dessous (remplacez les %Dmft0.CLSID% et %Dmft1.CLSID% par les chaînes CLSID réelles que vous utilisez pour vos DMFTs), un maximum de 2 CLSIDs est autorisé dans Windows 10, version 1703, et le premier est le plus proche de DevProxy et le dernier est le dernier DMFT dans la chaîne.

Le CLSID du DMFT de la plateforme est {3D096DDE-8971-4AD5-98F9-C74F56492630}.

Quelques exemples de paramètres CameraDeviceMftCLSIDChain :

• Aucun DMFT IHV/OEM ou DMFT de la plateforme

  • CameraDeviceMftCLSIDChain = "" (ou il n’est pas nécessaire de spécifier cette entrée de registre)

• IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = %Dmft.CLSID%

• DMFT de la plateforme <-> DMFT IHV/OEM

  • CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%

  • Voici une capture d’écran de la clé de registre résultante pour une caméra USB avec DMFT de la plateforme et un DMFT (avec le GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) dans la chaîne.

• IHV/OEM DMFT0 <-> IHV/OEM DMFT1

  • CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,

Si CameraDeviceMftCLSIDChain est configuré, les paramètres CameraDeviceMftCLSID hérités sont ignorés par DTM.

Si CameraDeviceMftCLSIDChain n’est pas configuré et que le paramètre CameraDeviceMftCLSID hérité est configuré, alors la chaîne serait comme suit (si sa caméra USB est prise en charge par le DMFT de la plateforme et si le DMFT de la plateforme est activé) DevProxy <–> DMFT de la plateforme <–> DMFT OEM/IHV ou (si la caméra n’est pas prise en charge par le DMFT de la plateforme ou si le DMFT de la plateforme est désactivé) DevProxy <-> DMFT OEM/IHV.

Paramètres de fichier INF d’exemple :

[USBVideo.Interface.AddReg]
HKR,,CLSID,,%ProxyVCap.CLSID%
HKR,,FriendlyName,,%USBVideo.DeviceDesc%
HKR,,RTCFlags,0x00010001,0x00000010
HKR,,EnablePlatformDmft,0x00010001,0x00000001
HKR,,DisablePlatformDmftFeatures,0x00010001,0x00000001
HKR,,CameraDeviceMftCLSIDChain, 0x00010000,%Dmft0.CLSID%,%Dmft1.CLSID%

Enregistrement des objets COM et des MFT du Device MFT

Plutôt que d’enregistrer globalement l’objet COM du pilote, l’objet COM du pilote est enregistré sous la clé de l’appareil. Cela permet l’enregistrement du COM MFT à partir du conteneur et empêche la création de clés de registre globales, préservant ainsi l’isolation du package du pilote. Les MFTs sont également enregistrés sous la clé de l’appareil pour des raisons similaires.

Modifications du fichier INF du pilote

Lors de l’installation du pilote de dispositif, le fichier INF doit désormais effectuer tous les enregistrements d’objet COM et MFT sous la clé de l’appareil. Les enregistrements MFT et COM doivent être modifiés comme indiqué ici :

Enregistrements MFT

Enregistrements COM

Dans Windows 26100 et versions ultérieures, tous les enregistrements COM pour les DMFTs de dispositif doivent utiliser les directives AddComServer/AddComClass dans le fichier INF. Un exemple de syntaxe est montré ici :

[AvsCamera.COM]
AddComServer = AvsCameraMFT,,AvsCamera.COMInstall

[AvsCamera.COMInstall]
ServerType = 1; in-proc
ServerBinary = %13%\AvsCameraDMFT.dll
AddComClass = %DMFT.CLSID%,, AvsCamera.COMClassInstall


[AvsCamera.COMClassInstall]
ThreadingModel = Both
Description = %AvsCamera.ComServerDescription%

Les versions précédentes de l’enregistrement COM du Device MFT utilisaient AddReg pour installer manuellement la classe COM.

La syntaxe INF pour différencier en fonction de la version du système d’exploitation peut être trouvée dans La combinaison d’extensions de plateforme avec des versions du système d’exploitation. À partir de Window 11 25300, l’INF doit se conformer à ces nouvelles clés de registre. Les versions de système d’exploitation plus anciennes utilisent les clés de registre traditionnelles pour la compatibilité. L’INF doit configurer ces clés de registre dans l’emplacement ancien sur les anciennes versions de système d’exploitation et créer les nouvelles clés dans leur nouvel emplacement pour les versions de système d’exploitation plus récentes. Par exemple, pour un enregistrement MFT sur une version plus ancienne, l’INF crée la clé sous l’entrée de registre suivante :

HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\ 

Pour un enregistrement MFT sur une nouvelle version, l’INF crée la clé sous l’entrée de registre suivante :

**software key**\MediaFoundation\Transforms\{clsid}\ 

Cette entrée définit où clé de logiciel représente la clé de logiciel d’un dispositif.

Pour plus d’informations, veuillez consulter la section Ouverture de la clé logicielle d’un appareil.

Un exemple de syntaxe de ciblage des différentes versions de système d’exploitation est montré ici :

[Manufacturer] 
%Msft% = Msft, NTamd64,NTamd64.10.0...25300 

; -------------- ; 
; Models Section ; 
; -------------- ; 

; Targets old builds
[Msft.NTamd64] 
%DeviceDesc% = ExampleDDInstall_Old, ExampleHardwareId

[ExampleDDInstall_Old]
 AddReg = MFT_Registration_Old

[MFT_Registration_Old]
; INF work for older build here

; Windows 10 build with build number equal to or greater than 25300 
[msft.ntamd64.10.0...25300]  
%DeviceDesc% = ExampleDDInstall_New, ExampleHardwareId

[ExampleDDInstall_new]
AddReg = MFT_Registration_new

[MFT_Registration_new]
; INF work for newer build here