Matériel MFTs
Notes
cette rubrique s’applique à Windows 7 ou version ultérieure.
Cette rubrique explique comment écrire une Media Foundation transformation (MFT) qui agit en tant que proxy à un encodeur, à un décodeur ou à un processeur de signal numérique (DSP) matériel.
Important
Si un codec matériel utilise le pilote de classe multimédia AVStream, il ne nécessite pas de MFT personnalisé. Media Foundation fournit un proxy AVStream à cet effet. Les informations contenues dans cette rubrique s’appliquent uniquement dans le cas particulier où le codec matériel n’utilise pas AVStream. Pour plus d’informations, consultez prise en charge du codec matériel dans AVStream.
Cette rubrique contient les sections suivantes :
- Introduction
- Attributs MFT du matériel
- Séquence de négociation matérielle
- Traitement des données
- Décodeur/encodeur couplé
- Rubriques connexes
Introduction
Tout codec matériel qui n’est pas basé sur AVStream doit fournir sa propre table MFT pour agir en tant que proxy du pilote. Un codec matériel peut incorporer plusieurs blocs fonctionnels distincts :
- Encodeur
- Décodeur
- Mise à l’échelle des frames/conversion de format
Chacune de ces fonctions doit être gérée par une table MFT distincte. Une table MFT matérielle ne doit jamais jouer le rôle d’un « transcodeur polyvalent ». Au lieu de cela, placez les fonctions d’encodage dans un encodeur MFT et décodez les fonctions dans une table MFT de décodage. Si le matériel offre des conversions de format et de mise à l’échelle des frames, placez ces fonctions dans un processeur vidéo distinct, inscrit dans la catégorie de _ _ _ processeur vidéo de catégorie MFT . Si le matériel ne prend pas en charge la mise à l’échelle des cadres ou la conversion de format, Media Foundation fournit un processeur vidéo logiciel.
Les MFTs matériels présentent les conditions générales suivantes :
- Le matériel MFTs doit utiliser le nouveau modèle de traitement asynchrone, comme décrit dans MFTS asynchrone.
- Le matériel MFTs doit prendre en charge les modifications de format dynamique, comme décrit dans modifications de format dynamique.
Attributs MFT du matériel
Une table MFT matérielle doit implémenter les méthodes suivantes liées aux attributs :
- IMFTransform :: GetAttributes: retourne un magasin d’attributs pour les attributs MFT globaux.
- IMFTransform :: GetInputStreamAttributes: retourne un magasin d’attributs pour un flux d’entrée.
- IMFTransform :: GetOutputStreamAttributes: retourne un magasin d’attributs pour un flux de sortie.
Lorsque la table MFT est créée pour la première fois, elle doit définir les attributs suivants sur son propre magasin d’attributs global (autrement dit, le magasin d’attributs retourné par GetAttributes) :
| Attribut | Description |
|---|---|
| _transformation MF _ asynchrone | Doit avoir la valeur true. Indique que la table MFT effectue un traitement asynchrone. |
| Attribut de l' _ _ URL matérielle de l’ÉNUMÉRation MFT _ _ | Contient le lien symbolique pour le périphérique matériel. Le chargeur de topologie utilise la présence de cet attribut pour déterminer si un MFT représente un périphérique matériel. |
| _modification du _ format dynamique de la prise en charge de _ MFT _ | Doit avoir la valeur true. Indique que la table MFT prend en charge les modifications de format dynamiques. |
Séquence de négociation matérielle
Si deux MFTs représentent le même appareil physique, ils peuvent échanger des données au sein du matériel, par exemple sur un bus matériel. Il n’est pas nécessaire de copier les données dans la mémoire système, puis de les replacer sur l’appareil.
Dans le diagramme suivant, le MFTs intitulé « A » et « B » représentent des blocs fonctionnels au sein du même matériel. Par exemple, dans un scénario de transcodage, « A » peut représenter un décodeur matériel et « B » peut représenter un encodeur matériel. Le passage de données entre « A » et « B » se produit au sein du matériel. La table MFT intitulée « C » est une table MFT de logiciel. Le passage de données de « B » à « C » utilise la mémoire système.

Pour établir une connexion matérielle, les deux MFTs matériels doivent utiliser un canal de communication privé. Cette connexion est établie lors de la négociation de format, avant que les types de média ne soient définis et avant le premier appel à ProcessInput. Le processus de connexion fonctionne comme suit :
Le chargeur de topologie vérifie à la fois MFTs la présence de l’attribut d' _ _ _ _ attribut d’URL matériel de l’énumération MFT . Notez qu’elle n’examine pas la valeur de cet attribut.
Si l’attribut de l' _ _ _ _ URL matérielle de l’énumération MFT est présent sur les deux MFTS, le chargeur de topologie effectue les opérations suivantes :
- Le chargeur de topologie appelle IMFTransform :: GetOutputStreamAttributes sur la table MFT en amont (A). Cette méthode retourne un pointeur IMFAttributes . Laissez ce pointeur dénoté pUpstream.
- Le chargeur de topologie appelle IMFTransform :: GetInputStreamAttributes sur la MFT en aval (B). Cet appel retourne également un pointeur IMFAttributes . Laissez ce pointeur dénoté pDownstream.
- Le chargeur de topologie définit l’attribut d' _ _ _ attribut de flux connecté MFT sur PDownstream en appelant IMFAttributes :: setunknown,. La valeur de l’attribut est le pointeur pUpstream .
- Le chargeur de topologie affecte la valeur true à l’attribut MFT _ Connected _ to _ HW _ Stream sur pDownstream et pUpstream.
À ce stade, la table MFT en aval a un pointeur vers le magasin d’attributs de la MFT en amont, comme indiqué dans le diagramme suivant.

Notes
Par souci de clarté, ce diagramme montre les flux et les magasins d’attributs en tant qu’objets distincts, mais cela n’est pas nécessaire pour l’implémentation.
La table MFT en aval utilise le pointeur IMFAttributes pour établir un canal de communication privé avec la table MFT en amont. Étant donné que le canal est privé, le mécanisme exact est défini par l’implémentation. Par exemple, la table MFT peut demander une interface COM privée.
À l’étape 4, la MFT en aval doit vérifier si les deux MFTs partagent le même appareil physique. Si ce n’est pas le cas, ils doivent revenir à l’utilisation de la mémoire système pour le transport des données. Cela permet à la MFT de fonctionner correctement avec les MFTs logicielles et d’autres périphériques matériels.
Si le protocole de transfert s’effectue correctement et que les deux MFTs partagent un canal de données privé, ils n’utilisent pas le modèle de traitement de données standard (décrit dans la section suivante) au niveau du point de connexion. Plus précisément, la MFT en aval n’envoie pas d’événements METransformNeedInput ; Pour plus d’informations, reportez-vous à la section suivante de cette rubrique.
Traitement des données
Lorsqu’une table MFT matérielle utilise la mémoire système pour le transport de données, le processus fonctionne comme suit :
- Pour demander plus d’entrées, la table MFT envoie un événement METransformNeedInput .
- L’événement METransformNeedInput fait en sorte que le pipeline appelle IMFTransform ::P rocessinput.
- Lorsque la table MFT contient des données de sortie, la table MFT envoie un événement METransformHaveOutput .
- L’événement METransformHaveOutput fait en sorte que le pipeline appelle IMFTransform ::P rocessoutput.
Pour plus d’informations, consultez MFTS asynchrone.
Toutefois, si la table MFT utilise un canal matériel, elle n’envoie pas ces événements au point de connexion matériel, car tous les transferts de données s’effectuent en interne au sein du matériel. Par conséquent, le pipeline n’appelle pas ProcessInput ou ProcessOutput sur le point de connexion.
Par exemple, considérons le premier diagramme de cette rubrique. Compte tenu de cette configuration, le traitement des données se produit comme suit :
- « A » envoie METransformNeedInput pour demander des données.
- Le pipeline appelle ProcessInput sur « A ».
- « A » et « B » traitent les données dans le matériel.
- Une fois le traitement terminé, « B » envoie un événement METransformHaveOutput .
- Le pipeline appelle ProcessOutput sur « B ».
Décodeur/encodeur couplé
Si un décodeur et un encodeur se trouvent sur la même puce matérielle, il peut être préférable de les utiliser ensemble lors du transcodage. Autrement dit, la sélection de l’une d’entre elles doit entraîner la sélection de l’autre dans le pipeline de transcodage. Pour vous assurer que les codecs matériels correspondants sont choisis, les MFTs de codec doivent offrir un type de média personnalisé. Pour créer un type de média personnalisé :
- Définissez l’attribut de _ type de _ majeure _ série MF MT sur MFMediaType _ audio ou MFMediaType _ Video, selon le cas.
- Définissez l’attribut de _ sous- _ type MF MT sur une valeur Guid personnalisée.
Les autres attributs de type sont facultatifs. Le décodeur retourne le type personnalisé à partir de son IMFTransform :: GetOutputAvailableType, et l’encodeur retourne le type personnalisé à partir de sa méthode IMFTransform :: GetInputAvailableType . Dans les deux cas, le type personnalisé doit être la première entrée de la liste (dwTypeIndex = 0).
Pour fonctionner avec les codecs logiciels, le codec doit également retourner au moins un format standard, tel que NV12 pour la vidéo. Les formats standard doivent apparaître après le type personnalisé (dwTypeIndex > 0). Si les deux codecs doivent toujours être couplés et ne peuvent pas interagir avec les codecs logiciels, MFTs doit retourner uniquement le format personnalisé et ne retourne pas de formats standard.
Notes
Si un décodeur ne retourne pas de formats standard, il ne peut pas être utilisé pour la lecture avec le convertisseur vidéo amélioré. Dans ce cas, elle doit être inscrite en tant que décodeur de transcodage uniquement. Consultez décodeurs de transcodage uniquement.