Enxaguamento

[O recurso associado a esta página, DirectShow, é um recurso herdado. Foi substituído por MediaPlayer, IMFMediaEnginee Audio/Video Capture in Media Foundation. Esses recursos foram otimizados para Windows 10 e Windows 11. A Microsoft recomenda vivamente que o novo código utilize 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.]

Enquanto o gráfico de filtro está em execução, quantidades arbitrárias de dados podem ser movidas através do gráfico. Alguns deles podem estar em filas, esperando para serem entregues. Há momentos em que o gráfico de filtro precisa remover esses dados pendentes o mais rápido possível e substituí-los por novos dados. Após um comando seek, por exemplo, o filtro de origem gera amostras de uma nova posição na fonte. Para minimizar a latência, os filtros downstream devem descartar quaisquer amostras que foram criadas antes do comando seek. O processo de descarte de amostras é conhecido como purga. Ele permite que o gráfico seja mais responsivo quando os eventos alteram o fluxo normal de dados.

O esvaziamento é tratado de forma ligeiramente diferente pelo modelo de extração do que pelo modelo de impulso. Este artigo começa descrevendo o modelo push; em seguida, descreve as diferenças no modelo pull.

A lavagem acontece em duas fases.

• Primeiro, o filtro de origem chama IPin::BeginFlush no pino de entrada do filtro downstream. O filtro a jusante começa a rejeitar amostras a montante. Ele também descarta todas as amostras que está a segurar e envia a chamada BeginFlush para o próximo filtro.
• Quando o filtro de origem estiver pronto para enviar novos dados, ele chama IPin::EndFlush no pino de entrada. Isso sinaliza ao filtro a jusante que ele pode receber novas amostras. O filtro downstream envia a chamada EndFlush para o próximo filtro.

No método BeginFlush, o pino de entrada faz o seguinte:

1. Chama BeginFlush nos pinos de entrada descendentes.
2. Rejeita quaisquer outras chamadas que transmitam dados, incluindo Receive e EndOfStream.
3. Desbloqueia todos os filtros upstream que estão bloqueados aguardando uma amostra do alocador do filtro. Alguns filtros desautorizam seus alocadores para essa finalidade.
4. Sai de quaisquer esperas que bloqueiam o streaming. Por exemplo, os filtros do renderizador bloqueiam quando pausados. Eles também bloqueiam quando estão à espera de renderizar uma amostra no tempo de transmissão correto. O filtro deve ser desbloqueado, para que as amostras enfileiradas a montante possam ser entregues e rejeitadas. Esta etapa garante que todos os filtros upstream eventualmente sejam desbloqueados.

No método EndFlush, o pino de entrada faz o seguinte:

1. O sistema aguarda que todas as amostras enfileiradas sejam descartadas.
2. Libera todos os dados armazenados em buffer. Às vezes, essa etapa pode ser executada no método BeginFlush. No entanto, BeginFlush não está sincronizado com o thread de streaming. O filtro não deve processar ou armazenar em buffer mais dados entre a chamada para BeginFlush e a chamada para EndFlush.
3. Limpa todas as notificações de EC_COMPLETE pendentes.
4. Chama EndFlush a jusante.

Neste ponto, o filtro pode aceitar amostras novamente. É garantido que todas as amostras são mais recentes do que a descarga.

No modelo pull, o filtro do analisador inicia a lavagem, em vez do filtro de origem. Ele não só chama IPin::BeginFlush e IPin::EndFlush no filtro a jusante, mas também chama IAsyncReader::BeginFlush e IAsyncReader::EndFlush no pino de saída do filtro de origem. Se o filtro de origem tiver solicitações de leitura pendentes, ele as descartará.

Tópicos relacionados

Esvaziamento de Dados