Rediger

Del via

CTransInPlaceFilter class

  • Artikkel

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

ctransinplacefilter class hierarchy

The CTransInPlaceFilter class is designed for in-place transform filters, which are filters that modify the input data rather than copying the data across buffers.To use this class, derive a new class from CTransInPlaceFilter and implement the following methods:

This class uses the CTransInPlaceInputPin class for its input pin, and the CTransInPlaceOutputPin class for its output pin. Typically, you do not need to override these pin classes. The filter creates both pins in the CTransInPlaceFilter::GetPin method. If you do override the pin classes, you must override GetPin to create your custom pins.

This class is designed so the input type always matches the output type. Whenever possible, the filter uses a single allocator for both pin connections.

Preferred Media Types

If the output pin is already connected, the input pin offers the downstream filter's preferred types. (In fact it simply returns the downstream filter's enumerator object.) Otherwise, it has no preferred types. The output pin has the same behavior, but in reverse: If the input pin is already connected, the output pin offers the upstream filter's preferred types. Otherwise, it has no preferred types

Pin Connections

When one pin connects, the filter generally reconnects the other pin, to make sure that both pins use the same media type and the same allocator. (The mechanism for reconnecting pins is described in Reconnecting Pins.) Two scenarios are possible: Either the input pin connects first, or the output pin connects first.

Suppose the input pin connects first. The following steps occur:

  1. The input pin calls the filter's CheckInputType method to check the media type.
  2. The upstream filter selects an allocator. At this point, the input pin has no allocator requirements, and it accepts any allocator for the connection. If the upstream filter requests an allocator, the pin creates a new one. For reasons described shortly, this allocator will not be used in the final connection. It is provided only to help finish this stage of the connection process.

Later, when the output pin connects:

  1. The output pin calls the filter's CheckInputType method to check the media type. It also calls IPin::QueryAccept on the upstream filter. This ensures that the input pin can change its media type to match.
  2. The output pin calls the filter's CheckInputType method to check the media type. It also calls IPin::QueryAccept on the upstream filter. This ensures that the input pin can change its media type to match.
  3. The output pin calls the filter's CheckInputType method to check the media type. It also calls IPin::QueryAccept on the upstream filter. This ensures that the input pin can change its media type to match.
  4. This time, the input pin's GetAllocator method returns the downstream allocator, and GetAllocatorRequirements returns the downstream filter's allocator requirements. The input pin accepts whatever allocator the upstream filter chooses.
  5. This time, the input pin's GetAllocator method returns the downstream allocator, and GetAllocatorRequirements returns the downstream filter's allocator requirements. The input pin accepts whatever allocator the upstream filter chooses.

Now consider the opposite scenario, where the output pin is the first pin to connect.

  1. The output pin calls the filter's CheckInputType method to check the media type.
  2. It selects an allocator, preferring to use the downstream filter's allocator.

Then, when the input pin connects:

  1. The input pin checks the media type by calling CheckInputType on the filter, and by calling QueryAccept on the downstream filter's output pin.
  2. If the input type does not match the output type, the filter reconnects the output pin.
  3. The upstream filter selects an allocator. The input pin's GetAllocator method returns the downstream allocator, and the input pin accepts whatever allocator the upstream filter selects.
  4. The filter uses the same allocator for the downstream connection, possibly overriding the original downstream allocator.

This sequence of events changes slightly if any of the allocators involved are read-only, because the downstream allocator must be writable. In that case, the filter might use two separate allocators.

For more information about using this class, see Writing Transform Filters.

Protected Member Variables Description
m_bModifiesData Indicates whether the filter modifies the sample data.
Protected Methods Description
Copy Copies a media sample.
InputPin Retrieves a pointer to the filter's input pin.
OutputPin Retrieves a pointer to the filter's output pin.
TypesMatch Determines whether the input media type matches the output media type.
UsingDifferentAllocators Determines whether the input and output pins are using different allocators.
Public Methods Description
CTransInPlaceFilter Constructor method.
GetPin Retrieves a pin.
GetMediaType Retrieves a preferred media type for the output pin.
DecideBufferSize Sets the output pin's buffer requirements.
CheckTransform Checks whether an input media type is compatible with an output media type.
CompleteConnect Completes a pin connection.
Receive Receives a media sample, processes it, and delivers it to the downstream filter.
Pure Virtual Methods Description
Transform Transforms a sample in place.

Requirements

Requirement Value
Header
Transip.h (include Streams.h)
Library
Strmbase.lib (retail builds);
Strmbasd.lib (debug builds)