Threads de streaming e o Gerenciador de Grafo de Filtro

[O recurso associado a esta página, DirectShow, é um recurso herdado. Ele foi substituído por MediaPlayer, IMFMediaEngine e Captura de Áudio/Vídeo na 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 Captura de Áudio/Vídeo no 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.]

Quando o Gerenciador de Grafo de Filtro para o grafo, ele aguarda o desligamento de todos os threads de streaming. Isso tem as seguintes implicações para filtros:

• Um filtro nunca deve chamar métodos no Gerenciador de Grafo de Filtro de um thread de streaming.

  O Gerenciador de Grafo de Filtro usa uma seção crítica para sincronizar suas próprias operações. Se um thread de streaming tentar manter esta seção crítica, isso poderá causar um deadlock. Por exemplo: suponha que outro thread pare o grafo. Esse thread usa o bloqueio do grafo de filtro e aguarda o filtro parar de fornecer dados. Se o filtro estiver aguardando o bloqueio, ele nunca será interrompido, causando um deadlock.

• Um filtro nunca deve adicionarRef ou QueryInterface o Gerenciador de Grafo de Filtro de um thread de streaming.

  Se o filtro mantiver uma contagem de referência no Gerenciador de Grafo de Filtro (por meio de AddRef ou QueryInterface), ele poderá se tornar o último objeto a manter uma contagem de referência. Quando o filtro chama Release, o Gerenciador de Grafo de Filtro se destrói. Dentro de sua rotina de limpeza, o Gerenciador de Grafo de Filtro tenta interromper o grafo, fazendo com que ele aguarde a saída do thread de streaming. No entanto, ele está aguardando dentro do thread de streaming, portanto, o thread de streaming não pode sair. O resultado é um deadlock.