Filters and Pins

The two basic components used in the stream architecture are filters and pins. A filter is a COM object that performs a specific task, such as reading data from a disk. For each stream it handles, it exposes at least one pin. A pin is a COM object created by the filter, that represents a point of connection for a unidirectional data stream on the filter, as shown in the following illustration.

Input pins accept data into the filter, and output pins provide data to other filters. A source filter provides one output pin for each stream of data in the file. A typical transform filter, such as a compression/decompression (codec) filter, provides one input pin and one output pin, while an audio output filter typically exposes only one input pin. More complex arrangements are also possible.

You can name pins anything you want. If your pin name begins with the tilde (~) character, the filter graph will not automatically render that pin when an application calls IGraphBuilder::RenderFile. This can apply to pins that are just informational and are not meant to be rendered, or need to be enumerated so that their properties can be set. The tilde (~) prefix only affects the behavior of RenderFile and intelligent connect (IGraphBuilder::Connect). Note that intelligent connect can still be used to connect pins with this property if they implement the IPin::Connect method. However, output pins of intermediate filters which are being used to complete the connection which have the tilde at the start of their name will not be connected as part of the intelligent connection attempt.

At a minimum, a filter exposes the IBaseFilter interface. This interface provides methods that allow the enumeration of the pins on the filter and return filter information. It also provides the inherited methods from IMediaFilter; these methods allow control of state processing (for example running, pausing, and stopping) and synchronization, and are called primarily by the filter graph manager.

In addition, a filter might expose several other interfaces, depending on the media types supported and tasks performed. For example, a filter can expose the ISpecifyPropertyPages interface to support a property page.

Pins are responsible for providing interfaces to connect with other pins and for transporting the data. The pin interfaces support the following:

The transfer of time-stamped data using shared memory or other resource.
Negotiation of data formats at each pin-to-pin connection.
Buffer management and buffer allocation negotiation designed to minimize data copying and maximize throughput.

Pin interfaces differ slightly, depending on whether they are output pins or input pins.

An output pin typically exposes the following interfaces.

IPin methods are called to allow the pin to be queried for pin, connection, and data type information, and to send flush notifications downstream when the filter graph stops.
IMediaSeeking allows information about the stream's duration, start time, and stop time to be relayed from the renderer. The renderer passes the media position information upstream to the filter (typically the source filter) responsible for queuing the stream to the appropriate position.
IQualityControl passes quality-control messages upstream from the renderer to the filter that is responsible for increasing or decreasing the media supply.

An input pin typically exposes the following interfaces.

IPin allows the pin to connect to an output pin and provides information about the pin and its internal connections.
IMemInputPin allows the pin to propose its own transport memory allocator, to be notified of the allocator that an output pin is supplying, to receive media samples through the established allocator, and to flush the buffer. This interface can create a shared memory allocator object if the connected pin does not supply a transport memory allocator.

The standard transport interface, IMemInputPin, provides data transfer through shared memory buffers, although other transport interfaces can be used. For example, where two components are connected directly in hardware, they can connect to each other by using the IPin interface, and then seek a private interface that can manage the transfer of data directly between the two components.