Pull Model
[The feature associated with this page, DirectShow, is a legacy feature. It has been superseded by MediaPlayer, IMFMediaEngine, and Audio/Video Capture in Media Foundation. Those features have been optimized for Windows 10 and Windows 11. Microsoft strongly recommends that new code use MediaPlayer, IMFMediaEngine and Audio/Video Capture in Media Foundation instead of DirectShow, when possible. Microsoft suggests that existing code that uses the legacy APIs be rewritten to use the new APIs if possible.]
In the IMemInputPin interface, the upstream filter determines what data to send, and it pushes the data to the downstream filter. For some filters, a pull model is more appropriate. Here, the downstream filter requests data from the upstream filter. Samples still travel downstream, from output pin to input pin, but the downstream filter initiates the data flow. This type of connection uses the IAsyncReader interface.
The typical use for the pull model is in file playback. For example, in an AVI playback graph, the Async File Source filter performs generic file reading operations and delivers the data as a byte stream, with no format information. The AVI Splitter filter reads the AVI headers and parses the stream into video and audio samples. The AVI Splitter can determine what data it needs better than the Async File Source filter, and therefore it uses IAsyncReader instead of IMemInputPin.
To request data from the output pin, the input pin calls one of the following methods:
The first method is asynchronous, to support multiple overlapped reads. The others are synchronous.
In theory, any filter can support IAsyncReader, but in practice it is designed for source filters that connect to parser filters. The parser acts very much like a source filter in the push model. When it pauses, it creates a streaming thread that pulls data from the IAsyncReader connection and pushes it downstream. The output pins use IMemInputPin, and the rest of the graph uses the standard push model.
Related topics