Partager via

Négociation des allocateurs

  • Article

[La fonctionnalité associée à cette page, DirectShow, est une fonctionnalité héritée. Il a été remplacé par MediaPlayer, IMFMediaEngine et Audio/Video Capture dans Media Foundation. Ces fonctionnalités ont été optimisées pour Windows 10 et Windows 11. Microsoft recommande vivement au nouveau code d’utiliser MediaPlayer, IMFMediaEngine et La 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.]

Lorsque deux broches se connectent, elles ont besoin d’un mécanisme d’échange de données multimédias. Ce mécanisme est appelé transport. En général, l’architecture DirectShow est neutre en ce qui concerne 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 de la mémoire locale, dans lequel les données multimédias résident dans main mémoire. Il existe deux variantes de transport de la mémoire locale, le modèle push et le modèle pull. 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 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 Data Flow dans le graphique de filtre.

Dans le transport de la mémoire locale, l’objet responsable de l’allocation des mémoires 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 broche peut fournir un allocateur, mais la broche de sortie sélectionne l’allocateur à utiliser.

La broche de sortie définit également les propriétés de l’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 se reporter à la broche d’entrée pour les exigences de mémoire tampon.

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

  1. Si vous le souhaitez, la broche 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 la broche d’entrée, sauf s’il existe une bonne raison de ne pas le faire.
  2. Si vous le souhaitez, la broche de sortie appelle IMemInputPin::GetAllocator. Cette méthode demande un allocator à partir de la broche d’entrée. Le code pin d’entrée en fournit un ou retourne un code d’erreur.
  3. La broche de sortie sélectionne un allocateur. Il peut en utiliser une fournie par la broche d’entrée ou créer sa propre broche.
  4. La broche de sortie appelle IMemAllocator::SetProperties pour définir les propriétés de l’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. L’outpin 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 de l’allocator sont acceptables.
  7. La broche de sortie est responsable de la validation et du désengagement 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. La broche 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. La broche de sortie sélectionne un allocateur. Il peut utiliser celui fourni par la broche d’entrée, le cas échéant, ou créer sa propre broche.
  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 case activée les propriétés de l’allocator.
  4. La broche d’entrée est responsable de la validation et de la désengagement de l’allocateur.
  5. À tout moment pendant le processus de négociation de l’allocateur, l’une ou l’autre broche 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 remettre des exemples à cette broche d’entrée. Le filtre propriétaire ne doit pas utiliser l’allocateur pour remettre des exemples à d’autres broches.

Fourniture d’un outil d’allocation personnalisé