Reconectando pinos

[O recurso associado a esta página, DirectShow, é um recurso herdado. Foi substituído por MediaPlayer, IMFMediaEngine e Audio/Video Capture in Media Foundation. Esses recursos foram otimizados para Windows 10 e Windows 11. A Microsoft recomenda fortemente que o novo código use MediaPlayer, IMFMediaEngine e Audio/Video Capture in Media Foundation em vez de DirectShow, quando possível. A Microsoft sugere que o código existente que usa as APIs herdadas seja reescrito para usar as novas APIs, se possível.]

Durante uma conexão de pino, um filtro pode desconectar e reconectar um de seus outros pinos, da seguinte maneira:

1. O filtro chama IPin::QueryAccept no pin do outro filtro e especifica o novo tipo de mídia.
2. Se QueryAccept retornar S_OK, o filtro chamará IFilterGraph2::ReconnectEx para reconectar os pinos.

Veja a seguir alguns exemplos de quando um filtro pode precisar reconectar pinos:

• Filtros de tee. Um filtro tee divide um fluxo de entrada em várias saídas sem alterar os dados no fluxo. Um filtro tee pode aceitar uma variedade de tipos de mídia, mas os tipos devem corresponder em todas as conexões de pino. Portanto, quando o pino de entrada se conecta, o filtro pode precisar renegociar quaisquer conexões existentes nos pinos de saída e vice-versa. Para obter um exemplo, consulte o Exemplo de filtro infTee.
• Filtros trans-in-loco. Um filtro trans-in-loco modifica os dados de entrada no buffer original em vez de copiar os dados para um buffer de saída separado. Um filtro trans-in-loco deve usar o mesmo alocador para as conexões upstream e downstream. O primeiro pino a ser conectado (entrada ou saída) negocia um alocador da maneira usual. No entanto, quando o outro pino se conecta, o primeiro alocador pode não ser aceitável. Nesse caso, o segundo pino escolhe um alocador diferente e o primeiro pino se reconecta usando o novo alocador. Para obter um exemplo de implementação, consulte a classe CTransInPlaceFilter .

No método ReconnectEx , o Gerenciador de Grafo de Filtro desconecta e reconecta os pinos de forma assíncrona. O filtro não deve tentar a reconexão, a menos que QueryAccept retorne S_OK. Caso contrário, o pino será desconectado, causando erros de grafo. Além disso, o filtro deve solicitar a reconexão de dentro do método IPin::Connect , no mesmo thread. Se o método Connect retornar em um thread, enquanto outro thread fizer a solicitação de reconexão, o Gerenciador do Gráfico de Filtro poderá executar o grafo antes de fazer a reconexão, causando erros de grafo.