Compartir a través de

Lavado

  • Artículo

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

Mientras se ejecuta el grafo de filtro, las cantidades arbitrarias de datos se pueden mover a través del gráfico. Algunos de estos podrían estar en colas, esperando que se entreguen. Hay ocasiones en las que el gráfico de filtros necesita quitar estos datos pendientes lo antes posible y reemplazarlos por nuevos datos. Después de un comando seek, por ejemplo, el filtro de origen genera muestras a partir de una nueva posición en el origen. Para minimizar la latencia, los filtros de bajada deben descartar los ejemplos que se crearon antes del comando seek. El proceso de descarte de muestras se denomina vaciado. Permite que el gráfico tenga mayor capacidad de respuesta cuando los eventos modifican el flujo de datos normal.

El vaciado se controla ligeramente de forma diferente por el modelo de extracción que el modelo de inserción. Este artículo comienza por describir el modelo de inserción; a continuación, describe las diferencias en el modelo de extracción.

El vaciado se produce en dos fases.

  • En primer lugar, el filtro de origen llama a IPin::BeginFlush en el pin de entrada del filtro de bajada. El filtro de bajada comienza a rechazar muestras de nivel superior. También descarta las muestras que contiene y envía la llamada BeginFlush de bajada al siguiente filtro.
  • Cuando el filtro de origen está listo para enviar nuevos datos, llama a IPin::EndFlush en el pin de entrada. Esto indica el filtro de bajada que puede recibir nuevas muestras. El filtro de bajada envía la llamada a EndFlush al siguiente filtro.

En el método BeginFlush , el pin de entrada hace lo siguiente:

  1. Llama a BeginFlush en patillas de entrada de bajada.
  2. Rechaza cualquier otra llamada que transmita datos, incluidos Receive y EndOfStream.
  3. Desbloquea los filtros ascendentes que están bloqueados esperando una muestra del asignador del filtro. Algunos filtros descommiten sus asignadores para este fin.
  4. Sale de cualquier espera que bloquee el streaming. Por ejemplo, los filtros del representador se bloquean cuando se pausan. También bloquean cuando esperan representar un ejemplo en el momento correcto de la secuencia. El filtro debe desbloquearse para que se puedan entregar y rechazar muestras en cola ascendentes. Este paso garantiza que todos los filtros ascendentes se desbloqueen finalmente.

En el método EndFlush , el pin de entrada hace lo siguiente:

  1. Espera a que se descarten todas las muestras en cola.
  2. Libera los datos almacenados en búfer. Este paso se puede realizar a veces en el método BeginFlush . Sin embargo, BeginFlush no está sincronizado con el subproceso de streaming. El filtro no debe procesar ni almacenar en búfer más datos entre la llamada a BeginFlush y la llamada a EndFlush.
  3. Borra las notificaciones de EC_COMPLETE pendientes.
  4. Llama a EndFlush de bajada .

En este momento, el filtro puede volver a aceptar ejemplos. Se garantiza que todas las muestras sean más recientes que el vaciado.

En el modelo de extracción, el filtro del analizador inicia el vaciado, en lugar del filtro de origen. No solo llama a IPin::BeginFlush e IPin::EndFlush en el filtro de bajada, también llama a IAsyncReader::BeginFlush e IAsyncReader::EndFlush en el pin de salida del filtro de origen. Si el filtro de origen tiene solicitudes de lectura pendientes, las descartará.

Vaciado de datos