Classe CTransInPlaceFilter

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

La CTransInPlaceFilter classe est conçue pour les filtres de transformation sur place, qui sont des filtres qui modifient les données d’entrée plutôt que de copier les données entre les mémoires tampons. Pour utiliser cette classe, dérivez une nouvelle classe à partir de CTransInPlaceFilter et implémentez les méthodes suivantes :

• CTransformFilter::CheckInputType
• CTransInPlaceFilter::Transform

Cette classe utilise la classe CTransInPlaceInputPin pour sa broche d’entrée et la classe CTransInPlaceOutputPin pour sa broche de sortie. En règle générale, vous n’avez pas besoin de remplacer ces classes d’épingles. Le filtre crée les deux broches dans la méthode CTransInPlaceFilter::GetPin . Si vous remplacez les classes d’épingle, vous devez remplacer GetPin pour créer vos épingles personnalisées.

Cette classe est conçue de sorte que le type d’entrée corresponde toujours au type de sortie. Dans la mesure du possible, le filtre utilise un seul allocateur pour les deux connexions de broche.

Types de médias préférés

Si la broche de sortie est déjà connectée, la broche d’entrée offre les types préférés du filtre en aval. (En fait, il retourne simplement l’objet énumérateur du filtre en aval.) Sinon, il n’a pas de types préférés. La broche de sortie a le même comportement, mais à l’inverse : si la broche d’entrée est déjà connectée, la broche de sortie offre les types préférés du filtre amont. Sinon, il n’a pas de types préférés

Connexions de broches

Lorsqu’une broche se connecte, le filtre reconnecte généralement l’autre broche pour s’assurer que les deux broches utilisent le même type de média et le même allocateur. (Le mécanisme de reconnexion des broches est décrit dans Reconnecting Pins.) Deux scénarios sont possibles : soit la broche d’entrée se connecte en premier, soit la broche de sortie se connecte en premier.

Supposons que la broche d’entrée se connecte en premier. Les étapes suivantes se produisent :

1. La broche d’entrée appelle la méthode CheckInputType du filtre pour case activée le type de média.
2. Le filtre amont sélectionne un allocateur. À ce stade, la broche d’entrée n’a aucune configuration d’allocation requise et elle accepte n’importe quel allocateur pour la connexion. Si le filtre amont demande un allocator, la broche en crée un nouveau. Pour les raisons décrites ci-dessous, cet allocateur ne sera pas utilisé dans la connexion finale. Il est fourni uniquement pour vous aider à terminer cette étape du processus de connexion.

Plus tard, lorsque la broche de sortie se connecte :

1. L’épingle de sortie appelle la méthode CheckInputType du filtre pour case activée le type de média. Il appelle également IPin::QueryAccept sur le filtre amont. Cela garantit que la broche d’entrée peut changer son type de média pour qu’il corresponde.
2. L’épingle de sortie appelle la méthode CheckInputType du filtre pour case activée le type de média. Il appelle également IPin::QueryAccept sur le filtre amont. Cela garantit que la broche d’entrée peut changer son type de média pour qu’il corresponde.
3. L’épingle de sortie appelle la méthode CheckInputType du filtre pour case activée le type de média. Il appelle également IPin::QueryAccept sur le filtre amont. Cela garantit que la broche d’entrée peut changer son type de média pour qu’il corresponde.
4. Cette fois, la méthode GetAllocator de la broche d’entrée retourne l’allocateur en aval, et GetAllocatorRequirements retourne les exigences d’allocation du filtre en aval. La broche d’entrée accepte l’allocateur choisi par le filtre amont.
5. Cette fois, la méthode GetAllocator de la broche d’entrée retourne l’allocateur en aval, et GetAllocatorRequirements retourne les exigences d’allocation du filtre en aval. La broche d’entrée accepte l’allocateur choisi par le filtre amont.

Considérez maintenant le scénario inverse, où la broche de sortie est la première broche à connecter.

1. L’épingle de sortie appelle la méthode CheckInputType du filtre pour case activée le type de média.
2. Il sélectionne un allocateur, préférant utiliser l’allocateur du filtre en aval.

Ensuite, lorsque la broche d’entrée se connecte :

1. La broche d’entrée vérifie le type de média en appelant CheckInputType sur le filtre et en appelant QueryAccept sur la broche de sortie du filtre en aval.
2. Si le type d’entrée ne correspond pas au type de sortie, le filtre reconnecte la broche de sortie.
3. Le filtre amont sélectionne un allocateur. La méthode GetAllocator de la broche d’entrée retourne l’allocateur en aval, et la broche d’entrée accepte l’allocateur que le filtre amont sélectionne.
4. Le filtre utilise le même allocateur pour la connexion en aval, ce qui peut remplacer l’analyseur en aval d’origine.

Cette séquence d’événements change légèrement si l’un des allocateurs impliqués est en lecture seule, car l’allocateur en aval doit être accessible en écriture. Dans ce cas, le filtre peut utiliser deux répartiteurs distincts.

Pour plus d’informations sur l’utilisation de cette classe, consultez Écriture de filtres de transformation.

Configuration requise