Partager via


Négociation d’allocators

[La fonctionnalité associée à cette page, DirectShow, est une fonctionnalité héritée. Il a été remplacé par MediaPlayer, IMFMediaEngineet audio/vidéo capture dans Media Foundation. Ces fonctionnalités ont été optimisées pour Windows 10 et Windows 11. Microsoft recommande vivement que le nouveau code utilise MediaPlayer, IMFMediaEngine et capture audio/vidéo dans Media Foundation au lieu de directShow, lorsque cela est possible. Microsoft suggère que le code existant qui utilise les API héritées soit réécrit pour utiliser les nouvelles API si possible.]

Quand deux broches se connectent, ils ont besoin d’un mécanisme pour échanger des données multimédias. Ce mécanisme est appelé de transport. En général, l’architecture DirectShow est neutre sur les transports. Deux filtres peuvent accepter de se connecter à l’aide de n’importe quel transport pris en charge par les deux.

Le transport le plus courant est le transport mémoire locale, dans lequel les données multimédias résident dans la mémoire principale. Il existe deux versions du transport de mémoire locale, le modèle push et le modèle d’extraction . Dans le modèle push, le filtre source envoie des données au filtre en aval, à l’aide de l’interface IMemInputPin sur la broche d’entrée du filtre en aval. Dans le modèle d’extraction, le filtre en aval demande des données à partir du filtre source, à l’aide de l’interface IAsyncReader sur la broche de sortie du filtre source. Pour plus d’informations sur ces deux modèles de flux de données, consultez flux de données dans lefilter Graph .

Dans le transport de mémoire locale, l’objet responsable de l’allocation de mémoire tampons est appelé l’allocateur . Un allocator prend en charge l’interface IMemAllocator. Les deux broches partagent un seul allocateur. L’une ou l’autre épingle peut fournir un allocateur, mais la broche de sortie sélectionne l’allocateur à utiliser.

L’épingle de sortie définit également les propriétés d’allocateur, qui déterminent le nombre de mémoires tampons créées par l’allocateur, la taille de chaque mémoire tampon et l’alignement de la mémoire. La broche de sortie peut différer vers la broche d’entrée pour les exigences de mémoire tampon.

Dans une connexion IMemInputPin, la négociation d’allocator fonctionne comme suit :

  1. Si vous le souhaitez, l’épingle de sortie appelle IMemInputPin ::GetAllocatorRequirements. Cette méthode récupère les exigences de mémoire tampon de la broche d’entrée, telles que l’alignement de la mémoire. En général, la broche de sortie doit respecter la demande de l’épingle d’entrée, sauf s’il existe une bonne raison de ne pas le faire.
  2. Si vous le souhaitez, l’épingle de sortie appelle IMemInputPin ::GetAllocator. Cette méthode demande un allocator à partir de la broche d’entrée. La broche d’entrée fournit un code d’erreur ou retourne un code d’erreur.
  3. L’épingle de sortie sélectionne un allocateur. Il peut utiliser un fourni par la broche d’entrée ou créer son propre.
  4. L’épingle de sortie appelle IMemAllocator ::SetProperties pour définir les propriétés d’allocator. Toutefois, l’allocateur peut ne pas respecter les propriétés demandées. (Par exemple, cela peut se produire si la broche d’entrée fournit l’allocateur.) L’allocateur retourne les propriétés réelles en tant que paramètre de sortie dans la méthode SetProperties.
  5. Le pointage appelle IMemInputPin ::NotifyAllocator pour informer la broche d’entrée de la sélection.
  6. La broche d’entrée doit appeler IMemAllocator ::GetProperties pour vérifier si les propriétés d’allocator sont acceptables.
  7. L’épingle de sortie est responsable de la validation et de la suppression de l’allocateur. Cela se produit lorsque la diffusion en continu démarre et s’arrête.

Dans une connexion IAsyncReader, la négociation d’allocator fonctionne comme suit :

  1. L’épingle d’entrée appelle IAsyncReader ::RequestAllocator sur la broche de sortie. La broche d’entrée spécifie ses exigences de mémoire tampon et, éventuellement, fournit un allocateur.
  2. L’épingle de sortie sélectionne un allocateur. Il peut utiliser celui fourni par la broche d’entrée, le cas échéant, ou créer son propre.
  3. L’épingle de sortie retourne l’allocateur en tant que paramètre sortant dans la méthode RequestAllocator. La broche d’entrée doit vérifier les propriétés de l’allocateur.
  4. La broche d’entrée est responsable de la validation et de la suppression de l’allocateur.
  5. À tout moment pendant le processus de négociation de l’allocateur, l’une ou l’autre épingle peut échouer la connexion.
  6. Si la broche de sortie utilise l’allocateur de la broche d’entrée, elle peut utiliser cet allocateur uniquement pour fournir des exemples à cette broche d’entrée. Le filtre propriétaire ne doit pas utiliser l’allocateur pour distribuer des échantillons à d’autres broches.

Fournir un d’allocateur personnalisé