Rinçage

  • 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.]

Pendant l’exécution du graphe de filtre, des quantités arbitraires de données peuvent être déplacées dans le graphique. Certaines d’entre elles peuvent se trouver dans des files d’attente, en attente d’être livrées. Parfois, le graphe de filtre doit supprimer ces données en attente aussi rapidement que possible et les remplacer par de nouvelles données. Après une commande de recherche, par exemple, le filtre source génère des exemples à partir d’une nouvelle position dans la source. Pour réduire la latence, les filtres en aval doivent ignorer tous les exemples créés avant la commande seek. Le processus d’abandon des échantillons est appelé vidage. Il permet au graphique d’être plus réactif lorsque des événements modifient le flux de données normal.

Le vidage est géré légèrement différemment par le modèle de tirage et par le modèle push. Cet article commence par décrire le modèle push ; ensuite, il décrit les différences dans le modèle d’extraction.

Le vidage se produit en deux étapes.

  • Tout d’abord, le filtre source appelle IPin::BeginFlush sur la broche d’entrée du filtre en aval. Le filtre en aval commence à rejeter des exemples de amont. Il ignore également tous les exemples qu’il contient et envoie l’appel BeginFlush en aval au filtre suivant.
  • Lorsque le filtre source est prêt à envoyer de nouvelles données, il appelle IPin::EndFlush sur la broche d’entrée. Cela indique au filtre en aval qu’il peut recevoir de nouveaux exemples. Le filtre en aval envoie l’appel EndFlush au filtre suivant.

Dans la méthode BeginFlush , la broche d’entrée effectue les opérations suivantes :

  1. Appelle BeginFlush sur les broches d’entrée en aval.
  2. Rejette tous les autres appels qui diffusent des données, y compris Receive et EndOfStream.
  3. Débloque tous les filtres amont qui sont bloqués en attente d’un exemple à partir de l’analyseur du filtre. Certains filtres dégagent leurs allocateurs à cet effet.
  4. Quitte toutes les attentes qui bloquent la diffusion en continu. Par exemple, les filtres de renderer bloquent en cas d’interruption. Ils se bloquent également lorsqu’ils attendent de restituer un exemple à l’heure de flux appropriée. Le filtre doit débloquer afin que les exemples mis en file d’attente amont puissent être remis et rejetés. Cette étape garantit que tous les filtres amont finissent par se débloquer.

Dans la méthode EndFlush , la broche d’entrée effectue les opérations suivantes :

  1. Attend que tous les exemples mis en file d’attente soient ignorés.
  2. Libère toutes les données mises en mémoire tampon. Cette étape peut parfois être effectuée dans la méthode BeginFlush . Toutefois, BeginFlush n’est pas synchronisé avec le thread de diffusion en continu. Le filtre ne doit pas traiter ou mettre en mémoire tampon des données supplémentaires entre l’appel à BeginFlush et l’appel à EndFlush.
  3. Efface toutes les notifications EC_COMPLETE en attente.
  4. Appelle EndFlush en aval.

À ce stade, le filtre peut à nouveau accepter des exemples. Tous les échantillons sont garantis plus récents que le vidage.

Dans le modèle d’extraction, le filtre de l’analyseur lance le vidage, plutôt que le filtre source. Non seulement il appelle IPin::BeginFlush et IPin::EndFlush sur le filtre en aval, mais il appelle également IAsyncReader::BeginFlush et IAsyncReader::EndFlush sur l’épingle de sortie du filtre source. Si le filtre source a des demandes de lecture en attente, il les ignore.

Vidage des données