MfT matériels

Notes

Cette rubrique s’applique à Windows 7 ou version ultérieure.

 

Cette rubrique explique comment écrire une transformation Media Foundation (MFT) qui joue le rôle de proxy vers un encodeur matériel, un décodeur ou un processeur de signal numérique (DSP).

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 des codecs matériels dans AVStream.

 

Cette rubrique contient les sections suivantes :

• Introduction
• Attributs MFT matériels
• Séquence d’établissement d’une liaison matérielle
• Informatique
• Décodeur/encodeur appairé
• Rubriques connexes

Introduction

Tout codec matériel qui n’est pas basé sur AVStream doit fournir son propre MFT pour agir en tant que proxy pour le pilote. Un codec matériel peut incorporer plusieurs blocs fonctionnels distincts :

• Encodeur
• Décodeur
• Mise à l’échelle/conversion de format de trame

Chacune de ces fonctions doit être gérée par un MFT distinct. Un MFT matériel ne doit jamais agir comme un « transcodeur » multi-usage. Au lieu de cela, placez les fonctions d’encodage dans un encodeur MFT et les fonctions de décodage dans un décodeur MFT. Si le matériel offre une mise à l’échelle des images et des conversions de format, placez ces fonctions dans un processeur vidéo distinct, inscrit dans la catégorie MFT_CATEGORY_VIDEO_PROCESSOR . Si le matériel ne prend pas en charge la mise à l’échelle des images ou la conversion de format, Media Foundation fournit un processeur vidéo logiciel.

Les mft matériels ont les exigences générales suivantes :

• Les mft matériels doivent utiliser le nouveau modèle de traitement asynchrone, comme décrit dans MfT asynchrones.
• Les mft matériels doivent prendre en charge les modifications de format dynamique, comme décrit dans Modifications de format dynamique.

Attributs MFT matériels

Un MFT matériel doit implémenter les méthodes suivantes relatives 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.

Lors de la première création du fichier MFT, il doit définir les attributs suivants sur son propre magasin d’attributs global (autrement dit, le magasin d’attributs retourné par GetAttributes) :

Attribut	Description
MF_TRANSFORM_ASYNC	Doit être défini sur TRUE. Indique que le MFT effectue un traitement asynchrone.
MFT_ENUM_HARDWARE_URL_Attribute	Contient le lien symbolique de l’appareil matériel. Le chargeur de topologie utilise la présence de cet attribut pour tester si un MFT représente un appareil matériel.
MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE	Doit être défini sur TRUE. Indique que MFT prend en charge les modifications de format dynamique.

 

Séquence d’établissement d’une liaison matérielle

Si deux MFT 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 revenir à l’appareil.

Dans le diagramme suivant, les mft étiquetés « 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 flux de données entre « A » et « B » se produit dans le matériel. Le MFT étiqueté « C » est un logiciel MFT. Le flux de données de « B » à « C » utilise la mémoire système.

Pour établir une connexion matérielle, les deux mft matériels doivent utiliser un canal de communication privé. Cette connexion est établie pendant la négociation de format, avant que les types de média soient définis et avant le premier appel à ProcessInput. Le processus de connexion fonctionne comme suit :

1. Le chargeur de topologie vérifie la présence de l’attribut MFT_ENUM_HARDWARE_URL_Attribute aux deux mfT. Notez qu’il n’examine pas la valeur de cet attribut.

2. Si MFT_ENUM_HARDWARE_URL_Attribute est présent sur les deux modules MFT, le chargeur de topologie effectue les opérations suivantes :

   1. Le chargeur de topologie appelle IMFTransform::GetOutputStreamAttributes sur le amont MFT (A). Cette méthode retourne un pointeur IMFAttributes . Laissez ce pointeur être désigné pUpstream.
   2. Le chargeur de topologie appelle IMFTransform::GetInputStreamAttributes sur le MFT (B) en aval. Cet appel retourne également un pointeur IMFAttributes . Laissez ce pointeur être désigné pDownstream.
   3. Le chargeur de topologie définit l’attribut MFT_CONNECTED_STREAM_ATTRIBUTE sur pDownstream en appelant IMFAttributes::SetUnknown. La valeur de l’attribut est le pointeur pUpstream .
   4. Le chargeur de topologie définit l’attribut MFT_CONNECTED_TO_HW_STREAM sur TRUE sur pDownstream et pUpstream.

3. À ce stade, le MFT en aval a un pointeur vers le magasin d’attributs amont MFT, comme illustré dans le diagramme suivant.

   

   Notes

   Pour plus 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.

    

4. Le MFT en aval utilise le pointeur IMFAttributes pour établir un canal de communication privé avec le amont MFT. Étant donné que le canal est privé, le mécanisme exact est défini par l’implémentation. Par exemple, MFT peut rechercher une interface COM privée.

À l’étape 4, le MFT en aval doit vérifier si les deux MFT 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 au MFT de fonctionner correctement avec les MFT logiciels et d’autres périphériques matériels.

Si la négociation réussit et que les deux MFT partagent un canal de données privé, ils n’utilisent pas le modèle de traitement des données standard (décrit dans la section suivante) au point de connexion. Plus précisément, le 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’un MFT matériel utilise la mémoire système pour le transport de données, le processus fonctionne comme suit :

1. Pour demander plus d’entrée, le MFT envoie un événement METransformNeedInput .
2. L’événement METransformNeedInput amène le pipeline à appeler IMFTransform::P rocessInput.
3. Lorsque le MFT a des données de sortie, le MFT envoie un événement METransformHaveOutput .
4. L’événement METransformHaveOutput amène le pipeline à appeler IMFTransform::P rocessOutput.

Pour plus d’informations, reportez-vous à MfT asynchrones.

Toutefois, si le MFT utilise un canal matériel, il n’envoie pas ces événements au point de connexion matérielle, car tous les transferts de données se produisent en interne au sein du matériel. Par conséquent, le pipeline n’appelle pas ProcessInput ou ProcessOutput au point de connexion.

Par exemple, considérez le premier diagramme de cette rubrique. Compte tenu de cette configuration, le traitement des données se produirait comme suit :

1. « A » envoie METransformNeedInput pour demander des données.
2. Le pipeline appelle ProcessInput sur « A ».
3. « A » et « B » traitent les données dans le matériel.
4. Une fois le traitement terminé, « B » envoie un événement METransformHaveOutput .
5. Le pipeline appelle ProcessOutput sur « B ».

Décodeur/encodeur jumelé

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’un 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 deux codecs MFT doivent offrir un type de média personnalisé. Pour créer un type de média personnalisé :

• Définissez l’attribut MF_MT_MAJOR_TYPEsur MFMediaType_Audio ou MFMediaType_Video, le cas échéant.
• Définissez l’attribut MF_MT_SUBTYPE sur une valeur GUID personnalisée.

D’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 utiliser des 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 associés et ne peuvent pas interagir avec des codecs logiciels, les mfts doivent retourner uniquement le format personnalisé et ne renvoyer aucun format standard.

Notes

Si un décodeur ne retourne aucun format standard, il ne peut pas être utilisé pour la lecture avec le convertisseur vidéo amélioré. Dans ce cas, il doit être inscrit en tant que décodeur transcodeur uniquement. Consultez Décodeurs transcodeurs uniquement.

 

Rubriques connexes

Écriture d’un MFT personnalisé

Implémentation d’un codec MFT

Transformations de Media Foundation