Reconexión de patillas

[La característica asociada a esta página, DirectShow, es una característica heredada. Se ha reemplazado por MediaPlayer, IMFMediaEngine y Captura de audio/vídeo en Media Foundation. Esas características se han optimizado para Windows 10 y Windows 11. Microsoft recomienda encarecidamente que el nuevo código use MediaPlayer, IMFMediaEngine y Audio/Video Capture en Media Foundation en lugar de DirectShow, siempre que sea posible. Microsoft sugiere que el código existente que usa las API heredadas se reescriba para usar las nuevas API si es posible.

Durante una conexión de patillas, un filtro puede desconectar y volver a conectar uno de sus otros pines, como se indica a continuación:

1. El filtro llama a IPin::QueryAccept en el pin del otro filtro y especifica el nuevo tipo de medio.
2. Si QueryAccept devuelve S_OK, el filtro llama a IFilterGraph2::ReconnectEx para volver a conectar las patillas.

A continuación se muestran algunos ejemplos de cuándo es posible que un filtro necesite volver a conectar patillas:

• Filtros de tee. Un filtro de tee divide un flujo de entrada en varias salidas sin cambiar los datos de la secuencia. Un filtro de tee puede aceptar un intervalo de tipos de medios, pero los tipos deben coincidir entre todas las conexiones de patillas. Por lo tanto, cuando se conecta el pin de entrada, es posible que el filtro tenga que renegociar las conexiones existentes en los pines de salida y viceversa. Para obtener un ejemplo, consulte el ejemplo de filtro InfTee.
• Filtros trans-in-place. Un filtro trans-in-place modifica los datos de entrada en el búfer original en lugar de copiar los datos en un búfer de salida independiente. Un filtro trans-in-place debe usar el mismo asignador para las conexiones ascendentes y descendentes. El primer pin para conectarse (entrada o salida) negocia un asignador de la manera habitual. Sin embargo, cuando el otro pin se conecta, es posible que el primer asignador no sea aceptable. En ese caso, el segundo pin elige un asignador diferente y el primer anclaje se vuelve a conectar mediante el nuevo asignador. Para obtener una implementación de ejemplo, vea la clase CTransInPlaceFilter .

En el método ReconnectEx , Filter Graph Manager desconecta y vuelve a conectar las patillas de forma asincrónica. El filtro no debe intentar la reconexión a menos que QueryAccept devuelva S_OK. De lo contrario, el pin se dejará desconectado, lo que provocará errores de gráfico. Además, el filtro debe solicitar la reconexión desde el método IPin::Connect , en el mismo subproceso. Si el método Connect vuelve en un subproceso, mientras que otro subproceso realiza la solicitud de reconexión, el Administrador de graph de filtros podría ejecutar el gráfico antes de que realice la reconexión, lo que provoca errores de grafo.