Movement of Data Through the Filter Graph (Windows Embedded CE 6.0)
1/6/2010
Data flows in the form of media samples from the output pin of one filter to the input pin of the next filter downstream. Media samples are COM objects that support the IMediaSample or IMediaSample2 interface. All samples are time-stamped and the flow of all streams is synchronized to a common clock, typically the system's sound card. DirectShow uses a push model: all filters push against the renderer filter, which can block the flow if it is put into a stop or paused state. For this reason, renderers are the only filters that actually care what state they are in. The renderer filter also controls the data rate, except in cases where the incoming stream has a variable bit rate, such as Internet streaming.
Filters can have three states: stopped, paused or running. In the stopped state, no data is flowing. The filter should release as many resources as possible although this is not always possible, especially if a filter is holding special hardware resources. The paused state is just like on a VCR; it is an intermediate state in which only the first frame in the video stream is processed, with no audio. Pause can also be used for prerolling or loading the filter graph's buffers with media samples that are ready to be rendered immediately once the filter goes into a running state. In the running state, the data is accepted from the input pin, processed, and sent to the output pin. All state transitions are valid: run to pause, pause to stop, stop to run, and so on. An application can call a filter's IMediaFilter::GetState method to determine what state it is in, but this is rarely necessary because the Filter Graph Manager handles the state transitions of filters. There is an ordering dependency in which filters in a graph are paused, so that none throw away data.