|Microsoft DirectX 9.0|
While the filter graph is running, arbitrary amounts of data can be moving through the graph. Some of it might be in queues, waiting to be delivered. There are times when the filter graph needs to remove this pending data as quickly as possible and replace it with new data. After a seek command, for example, the source filter generates samples from a new position in the source. To minimize latency, downstream filters should discard any samples that were created before the seek command. The process of discarding samples is called flushing. It enables the graph to be more responsive when events alter the normal data flow.
Flushing is handled slightly differently by the pull model than the push model. This article starts by describing the push model; then it describes the differences in the pull model.
Flushing happens in two stages.
In the BeginFlush method, the input pin does the following:
In the EndFlush method, the input pin does the following:
At this point, the filter can accept samples again. All samples are guaranteed to be more recent than the flush.
In the pull model, the parser filter initiates flushing, rather than the source filter. Not only does it call IPin::BeginFlush and IPin::EndFlush on the downstream filter, it also calls IAsyncReader::BeginFlush and IAsyncReader::EndFlush on the output pin of the source filter. If the source filter has pending read requests, it will discard them.