Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 appareil fourni par IHV, et le pipeline de capture insère comme première transformation, post-capture. Le DMFT reçoit des images post-traitées de l’appareil. Des opérations de post-traitement supplémentaires sur les images peuvent être effectuées à l’intérieur du DMFT. Le DMFT peut recevoir des images de tous les flux de l’appareil et peut exposer n’importe quel nombre de flux de sortie en fonction de l’exigence.
Cet article décrit la conception d’une extension à l’échelle de l’appareil s’exécutant en mode utilisateur qui peut être utilisée pour effectuer un post-traitement commun à tous les flux.
Terminologie
| Terme | Descriptif |
|---|---|
| KS | Pilote de streaming du noyau |
| AVStream | Modèle de pilote de streaming vidéo audio |
| Filtre | Objet qui représente une instance d’appareil |
| MFT de l’appareil | Extension de pilote de capture en mode utilisateur fournie par les IHV |
| Devproxy | MF <-> Marshaler AVStream |
| DTM | Gestionnaire de transformation d’appareil qui gère devproxy et Device MFT. Représente l’appareil dans le pipeline MF. |
Objectifs de conception
Extension en mode utilisateur spécifique au filtre d’appareil, ayant la même durée de vie que le filtre d’appareil.
Prend en charge n’importe quel nombre d’entrées provenant de l’appareil
Prend en charge un nombre quelconque de sorties (l’exigence actuelle est de trois flux : aperçu, enregistrement et photo)
Route tous les contrôles d’appareil vers Device MFT (qui le gère ou le transmet éventuellement à l’appareil)
Traitement post-traitement parallèle du flux capturé
Autoriser le traitement 3A indépendamment de la fréquence d’images
Autoriser les métadonnées d’un flux à partager entre d’autres flux
Accès aux ressources GPU
Accès aux files d’attente de travail MF MMCSS
Accès à MF Allocator
Interface simple (similaire à MFT)
Architecture interne flexible pour l’extensibilité IHV/OEM
Contraintes de conception
Aucune modification de l’interface de l’API Capture
Compatibilité descendante totale. Par exemple, aucune régression lors de l’utilisation d’applications et de 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 à l’échelle du filtre pour le pilote de capture. Ce composant a accès aux API MF, aux pools de threads, aux ressources GPU et ISP. L’extension à l’échelle du filtre offre la flexibilité d’avoir un nombre quelconque de flux entre lui-même et le filtre Ks de l’appareil. Cette flexibilité permet une communication hors bande transparente entre l’extension en mode utilisateur et le pilote qui peuvent être utilisés pour les métadonnées dédiées et les flux de traitement 3A.
Gestionnaire de transformation d’appareil (DTM)
La pile de capture introduit un nouveau composant fourni par le système, le Gestionnaire de transformation des appareils (DTM). Cela réside dans DeviceSource et gère Devproxy MFT et Device MFT. DTM effectue la négociation MediaType, la propagation d’échantillons et la gestion des événements MFT. Il expose également l’interface IMFTransform à DeviceSource et à d’autres interfaces privées nécessaires dont DeviceSource a besoin pour gérer les flux d’appareils. Ce composant extrait Devproxy et Device MFT du pipeline. Le pipeline voit simplement la DTM comme l’appareil, et les flux provenant de la DTM comme des flux d'appareil.
Devproxy
Devproxy est un MFT asynchrone qui marshale les commandes et les images vidéo entre le pilote de caméra AVStream et Media Foundation. Cela est fourni par Windows et prend en charge n nombre de sorties du pilote de caméra. En outre, il détient les allocateurs pour tous les connecteurs rendus accessibles par l'appareil.
MFT de l’appareil
L’appareil MFT est une extension en mode utilisateur du 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 pilotes de capture.
Le nombre de flux d'entrée de Device MFT doit être identique au nombre de broches Ks exposées par l'appareil. Les types de média pris en charge par les flux d'entrée du Device MFT doivent être identiques aux types de média exposés par les broches KS.
Le nombre de flux de sortie exposés par Device MFT est le flux affiché par DeviceSource et la pile de capture, l’API de capture et les applications et peut être un, deux ou trois flux. Le nombre de flux d’entrée et de sortie de Device MFT n’a pas besoin d’être identique. En outre, les flux d’entrée et de sortie n’ont pas besoin d’avoir les mêmes types de médias, et ont généralement différents types de médias. Le nombre de types de supports n’a pas besoin de correspondre non plus.
Le premier Ks Pin représenté en mode utilisateur par le flux de sortie de Devproxy est associé au premier flux d’entrée de Device MFT, le deuxième Ks Pin représenté en mode utilisateur par le flux de sortie de Devproxy est associé au deuxième flux d’entrée de Device MFT, et ainsi de suite.
L’appareil MFT reçoit un pointeur vers Devproxy, l’appareil DX et l’ID MF WorkQueue. Les trames provenant de l’appareil sont transmises directement à l’entrée de la Device MFT correspondante en tant que MF Samples. Avec tous ces éléments, Device MFT peut traiter après coup les échantillons capturés et fournir des échantillons à l’aperçu, à l’enregistrement et aux connecteurs photo.
Toutes les commandes et contrôles destinés à l’appareil sont redirigés vers l’appareil MFT. L’appareil MFT gère les contrôles ou les transmet au pilote via Devproxy. Cela simplifie la gestion des commandes par la pile de pilotes de capture.
Vue d’ensemble fonctionnelle
Lors de l'initialisation du pipeline de capture, si un Device MFT est disponible pour l'appareil, DeviceSource instancie DTM. Il transmet une instance de Devproxy qui représente l’appareil à la routine d’initialisation de la DTM. DTM cocré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, la prise en charge des interfaces obligatoires, et ainsi de suite.
DeviceSource interroge DTM pour obtenir les types de média de sortie pris en charge. DTM obtient ceci à partir des broches de sortie de Device MFT. DeviceSource expose le descripteur de présentation et le descripteur de flux en fonction de ces informations au pipeline de capture.
SourceReader utilise les types de médias exposés de DeviceSource et définit les types de médias par défaut sur chaque flux. À son tour, DeviceSource définit les types multimédias par défaut sur les flux de sortie de la DTM. DTM définit le type de média sur le flux de sortie de l’appareil MFT à l’aide de la méthode SetOutputStreamState .
Lorsque SetOutputStreamState est appelé, Device MFT publie un message vers DTM pour modifier le type de média de son flux d’entrée en fonction du média de sortie sélectionné et attend. En réponse à ce message, DTM interroge le média d’entrée préféré pour le flux d’entrée de l’appareil MFT à l’aide de GetPreferredInputStreamState. Cela définit le mediatype sur le flux de sortie correspondant de Devproxy. Si cela réussit, DTM définit ce même type de média sur le flux d’entrée de l’appareil MFT à l’aide de SetInputStreamState. Après avoir reçu cet appel, Device MFT termine SetOutputStreamState.
CaptureEngine sélectionne des flux individuels en activant des flux spécifiques sur DeviceSource. Cette opération est propagée à Device MFT by DTM via un appel SetOutputStreamState . L’appareil MFT place les flux de sortie spécifiques dans l’état demandé. Comme mentionné ci-dessus, Device MFT informe également DTM sur les flux d’entrée nécessaires qui doivent être activés. Cela entraîne la propagation de la sélection de flux par DTM vers Devproxy. À la fin de ce processus, tous les flux nécessaires, dans Devproxy et Device MFT, sont prêts à être diffusés.
SourceReader démarre DeviceSource lorsque CaptureEngine appelle ReadSample. À son tour, DeviceSource démarre la DTM en envoyant des 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 des messages MFT_MESSAGE_NOTIFY_BEGIN_STREAMING et MFT_MESSAGE_NOTIFY_START_OF_STREAM.
Remarque
Allouez les ressources nécessaires au démarrage de la diffusion en continu au lieu d’initialiser Device MFT.
DTM appelle SetOutputStreamState sur les sorties de Device MFT avec le paramètre d’état de streaming. L’appareil MFT commence à diffuser en streaming dans ces flux de sortie. DTM démarre la diffusion en continu sur les flux de sortie Devproxy dont le type multimédia est valide. Devproxy alloue les exemples et les extrait à partir de l’appareil. Ces échantillons sont injectés dans l'appareil MFT sur la broche d’entrée correspondante. Device MFT traite ces exemples et donne la sortie à DeviceSource. À partir de DeviceSource, les exemples transitent par SourceReader vers CaptureEngine.
CaptureEngine arrête les flux individuels en désactivant des flux individuels via une interface interne sur DeviceSource. Cela est traduit en désactivation spécifique du flux de sortie sur device MFT via SetOutputStreamState. À son tour, Device MFT peut demander de désactiver des flux d’entrée spécifiques via l’événement METransformInputStreamStateChanged . DTM propage cela aux flux Devproxy correspondants.
Tant que l'appareil MFT est lui-même 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 peut l’envoyer à DeviceStreamState_Stop ou DeviceStreamState_Run ou DeviceStreamState_Pause, et ainsi de suite, sans affecter d’autres flux.
Toutefois, la transition du 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 peut toujours être en streaming tant que l’appareil MFT lui-même est dans l’état de diffusion en continu.
Durée de vie de l’appareil MFT
L’appareil 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 le DeviceSource est créé, le Device MFT est créé, et lorsque le DeviceSource est arrêté, le Device MFT est arrêté de façon synchrone.
Pour permettre l'arrêt, le dispositif MFT doit prendre en charge l'interface IMFShutdown. Une fois que Device MFT->Shutdown est appelé, tout autre appel d’interface dans le Device MFT doit retourner une erreur MF_E_SHUTDOWN.
Type de mémoire
Les images peuvent être capturées dans des mémoires tampons système ou des mémoires tampons DX, selon la préférence du pilote de caméra. Quelle que soit la mémoire tampon sortie du pilote de caméra, elle est directement transmise à l’appareil MFT pour un traitement ultérieur.
Devproxy alloue les mémoires tampons en fonction de la préférence du pilote. Nous demandons à Device MFT d'avoir recours aux API d’allocator MF pour allouer les échantillons nécessaires pour ses broches de sortie pour les transformations non-in situ.
Modification du type multimédia lors de la diffusion en continu
Les clients de SourceReader sont en mesure de voir les types de média exposés par les flux de données de sortie du dispositif MFT en tant que 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 multimédia dans l’appareil MFT via DeviceSource. Il est de la responsabilité de l’appareil MFT de vider tous les échantillons en attente de la file d’attente de ce flux et de basculer vers le nouveau type de média sur ce flux en temps opportun. S’il est nécessaire de modifier le type de média d’entrée, il doit remplacer le type de média d’entrée actuel par celui-ci. DTM obtient le médiatype actuel à partir du flux d’entrée de l’appareil MFT et le définit sur les flux de sortie de Devproxy et l’entrée de Device MFT après chaque modification du type multimédia natif.
Modification du type multimédia d’entrée dans Device MFT
Étant donné qu’il s’agit d’un M x n MFT, il peut y avoir des répercussions sur les types multimédias et les changements d’état de la broche de diffusion en continu d’entrée lorsque les types de médias ou les modifications d’état de la broche de diffusion en continu de sortie sont modifiées. Plus précisément lorsque les modifications suivantes se produisent :
Modifications du type multimédia de sortie
Lorsqu’une application modifie le type multimédia natif, ce changement se propage à travers la pile de capture jusqu'à MFT du périphérique, en tant que modification du type multimédia de la broche de sortie.
Lorsque le type multimédia de sortie change, il peut déclencher une modification de type multimédia d’entrée. Par exemple, supposons que tous les ports de sortie diffusent en 720p. Cela entraîne la diffusion en continu à partir de la caméra à 720p. Ensuite, supposons que le flux d’enregistrements change son type de média natif à 1080p. Dans ce cas, l’un des flux d’entrée MFT de l’appareil qui récupérait des données dans le flux d’enregistrement aurait à modifier son type de média.
La broche de sortie est désactivée
- Lorsqu’une application désactive l’une des sorties de Device MFT lorsque la même entrée est partagée par plusieurs sorties, pour l’optimisation, l’entrée peut avoir à modifier 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, sont en streaming à 720p, le flux d’entrée doit changer son type de média en 720p pour économiser de l’énergie et améliorer les performances.
DTM gère les notifications METransformInputStreamStateChanged de Device MFT pour modifier le type de média et l’état sur l’entrée Device MFT et la sortie Devproxy dans ces conditions.
Types de médias de sortie préférés de l’appareil MFT
Nous avons recommandé que le MFT du dispositif produise des types de supports de sortie en utilisant le format NV12. YUY2 est la meilleure alternative suivante. Les types de supports MJPEG et RVB ne sont pas recommandés.
Purger le dispositif MFT
Deux types de vidage sont nécessaires lors de la gestion de l’appareil MFT :
Vidage global
Vidage MFT à l’échelle de l’appareil. Cela se produit généralement lorsque la DTM est sur le point d’envoyer un message d’arrêt de diffusion en continu à l’appareil MFT.
Device MFT doit supprimer tous les échantillons de ses files d’attente d’entrée et de sortie et retourner synchronement.
L’appareil MFT ne doit pas demander une nouvelle entrée ou envoyer une notification sur la 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 publiés avant le vidage sont supprimés par Device MFT Manager. Après le vidage, l'appareil MFT réinitialise sa métrique de suivi METransformHaveOutput interne.
Vidange du dispositif MFT
L’appareil MFT ne recevra pas de message de vidange distinct, car il n’est pas nécessaire de vidanger dans une source de capture en direct.
Déclencheur photo
Dans ce modèle, au lieu d’envoyer directement au pilote le déclencheur de photo et le déclencheur de démarrage et d'arrêt de séquence de photos, ils sont redirigés vers Device MFT. L’appareil MFT gère le déclencheur ou le transfère au pilote de la caméra si nécessaire.
Démarrage chaud
DeviceSource tente de démarrer un flux de sortie spécifique en faisant passer le flux à l’état de pause. À son tour, DTM appelle la méthode IMFDeviceTransform ::SetOutputStreamState sur 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. Pour ce faire, device MFT demande METransformInputStreamStateChanged à DTM et gère la méthode IMFDeviceTransform ::SetInputStreamState .
Séquence de photos variable
Avec cette architecture, la séquence de photos est implémentée avec le pilote de périphérique de caméra et device MFT, ce qui réduit considérablement la complexité du pilote de périphérique de caméra. Les déclencheurs de séquence de démarrage et d’arrêt de la photo sont envoyés à Device MFT et gèrent plus facilement la séquence de photos.
Confirmation de la photo
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 la taille de la mémoire tampon des métadonnées et alloue la mémoire pour les métadonnées. Les métadonnées provenant du pilote sont définies par Devproxy sur l'échantillon. Device MFT consomme les métadonnées de l’exemple. Les métadonnées peuvent être transmises avec l’exemple via son flux de sortie ou utilisées pour son post-traitement.
Avec le Device MFT prenant en charge tous les nombres d'entrées, un pin d’entrée dédié peut être utilisé uniquement pour les métadonnées ou les métadonnées hors bande. Le type de média de cette broche est personnalisé et le pilote décide de la taille et du nombre de mémoires tampons.
Ce flux de métadonnées est exposé au-delà de DTM. Le flux peut être placé dans l’état de diffusion en continu lorsque Device MFT démarre la diffusion en continu. Par exemple, lorsque des flux de sortie sont sélectionnés pour la diffusion en continu, Device MFT peut demander à DTM de démarrer un ou plusieurs flux vidéo, ainsi que le flux de métadonnées, à l’aide de 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 distincte dédiée aux métadonnées ou à l'option 3A.
Gestion des événements du Gestionnaire de Transformation d'Appareil (DTM)
Les événements Device Transform Manager sont définis dans les articles de référence suivants :
Interface IMFDeviceTransform
L’interface IMFDeviceTransform est définie pour interagir avec Device MFT. Cette interface facilite la gestion des m entrées et n sorties de périphérique MFT. En plus d’autres interfaces, 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 de l’appareil), nous devons le propager à l’appareil MFT et à DeviceSource.
Exigences pour les appareils MFT
Configuration requise pour l’interface
Les MFT d’appareil doivent prendre en charge les interfaces suivantes :
-
Cela permet à toutes les ksproperties, événements et méthodes de passer par le MFT de l’appareil. Cela permet à Device MFT de gérer ces appels de fonctions à l’intérieur de Device MFT ou simplement de les transférer au pilote. Dans le cas où il gère les méthodes KsEvent, l’appareil MFT doit effectuer les étapes suivantes :
Si Device MFT gère un événement KSEVENT_TYPE_ONESHOT , il duplique le handle lorsqu’il reçoit KSEVENT_TYPE_ENABLE.
Une fois l'événement configuré ou déclenché, il appelle CloseHandle sur le handle dupliqué.
Si Device MFT gère les événements non KSEVENT_TYPE_ONESHOT, il doit dupliquer le handle lorsqu’il reçoit KSEVENT_TYPE_ENABLE et appelle CloseHandle sur le handle dupliqué lorsque l’événement ks est désactivé en appelant la fonction KsEvent avec le premier paramètre (ID d’événement ks) et le deuxième paramètre (longueur d’événement) défini sur zéro. Les données et la longueur de l’événement sont valides. Les données d’événement identifient de manière unique un événement ks spécifique.
Si Device MFT gère les événements non KSEVENT_TYPE_ONESHOT, 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 sur zéro.
Exigences en matière de notification
Les MFT d’appareil doivent utiliser les messages suivants pour informer DTM sur la disponibilité des échantillons, toute modification de l’état du flux d’entrée, et ainsi de suite.
Configuration requise pour les threads
L’appareil MFT ne doit pas créer ses propres threads. Au lieu de cela, il doit utiliser les files d’attente de travail Media Foundation, qui sont allouées en fonction de l’ID transmis au DMFT via l’interface IMFRealTimeClientEx . Cela permet de s’assurer que tous les threads en cours d’exécution dans device MFT obtiennent la priorité correcte à laquelle le pipeline de capture est en cours d’exécution et évitent les inversions de priorité des threads.
Configuration requise pour InputStream
Nombre de flux
- Le nombre de flux d’entrée dans Device MFT doit être identique au nombre de flux pris en charge par le pilote.
Types de médias
Le nombre de mediatypes et les types de supports réels pris en charge par l’entrée de Device MFT doivent correspondre au nombre et aux types de médias pris en charge par le pilote.
Le nombre ne peut être différent que si les mediatypes pris en charge par l’entrée de Device MFT sont un sous-ensemble des mediatypes pris en charge par le pilote.
Les types multimédias pris en charge par le pilote et l’entrée de Device MFT peuvent être des types multimédias standard ou personnalisés.
Comment inscrire device MFT
L'INF de l'appareil photo doit avoir l'entrée d'interface de l'appareil suivante qui spécifie le CLSID de la CoClass du MFT de l'appareil.
[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 entraînent l’entrée des clés de Registre suivantes :
Remarque
Il s’agit d’un exemple uniquement (pas la clé de registre)
[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 MFT de l’appareil
Device MFT est le mécanisme de plug-in en mode utilisateur recommandé pour les IHVS et les OEM afin d’étendre la fonctionnalité de caméra sur Windows.
Avant Windows 10, version 1703, le pipeline de caméra n’a pris en charge qu’un seul plug-in d’extension DMFT.
À partir de Windows 10, version 1703, le pipeline de caméra Windows prend en charge une chaîne facultative de DMFT avec un maximum de deux DMFT.
À partir de Windows 11, version 22H2, la chaîne de traitement vidéo de Windows permet la mise en œuvre d'une série optionnelle de DMFT avec un maximum de quatre DMFT.
Cela offre une plus grande flexibilité pour les OEM et les IHVS afin de fournir une valeur ajoutée sous la forme de flux de caméra post-traitement. Par exemple, un appareil peut utiliser PDMFT avec un DMFT IHV et un DMFT OEM.
La figure suivante illustre l’architecture impliquant une chaîne de DMFTs.
Les échantillons circulent depuis le pilote de caméra vers DevProxy, puis passent par les chaînes 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 en tant que transitaire en transférant simplement l'échantillon au DMFT suivant.
Pour les contrôles comme KsProperty, l'appel monte dans la chaîne : le dernier DMFT dans la chaîne reçoit l'appel en premier. L’appel peut être géré là-bas ou transmis à DMFT précédent dans la chaîne.
Les erreurs sont propagées de DMFT à DTM, puis aux applications. Pour les DMFT IHV/OEM, l’échec de l’un des DMFT à s'instancier constitue une erreur irrécupérable pour DTM.
Exigences concernant les DMFT :
Le nombre de broches d'entrée du DMFT doit correspondre au nombre de broches de sortie du DMFT précédent. Sinon, la DTM échoue lors de l’initialisation. Toutefois, les nombres d’broches d’entrée et de sortie du même DMFT n’ont pas besoin de correspondre.
DMFT doit prendre en charge les interfaces - IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl et IMFMediaEventGenerator ; IMFTransform peut avoir besoin d’être pris en charge s’il existe MFT0 configuré ou si le DMFT suivant dans la chaîne nécessite la prise en charge de IMFTransform.
Sur les systèmes 64 bits qui n’utilisent pas Frame Server, les DMFT 32 bits et 64 bits doivent être enregistrés. Étant donné qu'une caméra USB peut être branchée à un système quelconque, pour les caméras USB « externes » (ou non fournies en standard), le fournisseur de la caméra USB doit fournir des DMFT en versions 32 et 64 bits.
Configurer la chaîne DMFT
Un appareil photo peut éventuellement fournir un objet DMFT COM dans une DLL à l’aide d’un fichier INF personnalisé qui utilise des sections de la boîte de réception USBVideo.INF.
Dans la section « Interface AddReg » du fichier .INF personnalisé, spécifiez les CLSID DMFT en ajoutant l’entrée de Registre suivante :
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft. CLSID%,%Dmft2.CLSID%
Comme indiqué dans l’exemple de paramètres INF ci-dessous (remplacez les% 0.CLSID %Dmftet % Dmft1.CLSID% par les chaînes CLSID réelles que vous utilisez pour vos DMFTs), il existe au maximum 2 CLSID autorisés dans Windows 10, version 1703, et la première est la plus proche de DevProxy et la dernière est la dernière DMFT dans la chaîne.
La plateforme DMFT CLSID est {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Voici un exemple de paramètres CameraDeviceMftCLSIDChain :
Aucune DMFT d'IHV/OEM ni de DMFT de plateforme
- CameraDeviceMftCLSIDChain = « » (ou aucune nécessité de spécifier cette entrée de Registre)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
Plateforme DMFT <-> IHV/OEM DMFT
CameraDeviceMftCLSIDChain = « {3D096DDE-8971-4AD5-98F9-C74F56492630} »,%Dmft.CLSID%
Voici une capture d’écran de la clé de Registre du résultat d’une caméra USB avec la plateforme DMFT ainsi qu'un DMFT (avec GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) dans la chaîne.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Remarque
CameraDeviceMftCLSIDChain peut avoir un maximum de 2 CLSID.
Si CameraDeviceMftCLSIDChain est configuré, les paramètres hérités de CameraDeviceMftCLSID sont ignorés par DTM.
Si CameraDeviceMftCLSIDChain n’est pas configuré et que le CameraDeviceMftCLSID hérité est configuré, la chaîne se présenterait ainsi : (si c'est une caméra USB et qu'elle est prise en charge par Platform DMFT et que Platform DMFT est activée) DevProxy <–> Platform DMFT <–> OEM/IHV DMFT, ou (si la caméra n’est pas prise en charge par Platform DMFT ou que Platform DMFT est désactivée) DevProxy <–> OEM/IHV DMFT.
Exemple de paramètres de fichier INF :
[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%
Objet COM et inscription des MFT de périphériques
Au lieu d’inscrire l’objet COM du pilote globalement, l’objet COM du pilote est inscrit sous la clé de périphérique. Cela permet l'enregistrement COM de MFT à partir du conteneur et empêche la création de clés de registre globales, préservant ainsi l'isolation du paquet de pilotes. Les MFT sont également inscrits sous la clé du dispositif pour des raisons similaires.
Modifications apportées au pilote INF
Lors de l’installation du pilote de périphérique, le fichier INF doit maintenant effectuer tous les enregistrements des objets COM et des MFT sous la clé du périphérique. Les inscriptions MFT et COM doivent changer comme indiqué ici :
Inscriptions pour MFT
| Avant | Après |
|---|---|
| Inf AddReg : HKCR, MediaFoundation\Transforms\{clsid}\... |
Per-Instance logiciel de périphérique INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\... |
| Emplacement du Registre : HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Emplacements du Registre : clé logicielle\MediaFoundation\Transforms\{clsid}\... |
Inscriptions de COM
Dans Windows 26100 et versions ultérieures, tous les enregistrements COM pour les MFT d’appareil doivent utiliser les directives AddComServer/AddComClass dans le fichier INF. Voici un exemple de syntaxe :
[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 de Device MFT ont utilisé AddReg pour installer manuellement la classe COM.
| Avant | Après |
|---|---|
| Inf AddReg : HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Per-Instance logiciel du périphérique INF AddReg : HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
La syntaxe INF pour la différenciation basée sur la version du système d’exploitation est disponible dans La combinaison d’extensions de plateforme avec des versions du système d’exploitation. À partir de Windows 11 25300, l'INF doit être conforme à ces nouvelles clés de Registre. Les versions antérieures du système d’exploitation utilisent les clés de Registre traditionnelles pour la compatibilité. Le fichier INF doit définir ces clés de registre à l'ancien emplacement pour les anciennes versions du système d'exploitation, et créer les nouvelles clés dans leur nouvel emplacement pour les versions du système d'exploitation plus récentes. Par exemple, pour un enregistrement MFT sur une version antérieure, l'INF crée la clé sous l'entrée de Registre suivante :
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
Pour une inscription 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 l’emplacement où la clé logicielle représente la clé logicielle d’un appareil.
Pour plus d’informations, consultez Ouverture de la clé logicielle d’un appareil.
Voici un exemple de syntaxe de ciblage de différentes versions du système d’exploitation :
[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