 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Because every copy operation uses valuable CPU cycles, filter developers are encouraged to avoid copying the media samples, if possible. It is best to write the filter to modify media samples in place on an allocator acquired from another filter. In some cases, this is not possible, and a copy operation must be performed.
Where no copy is needed, the run-time overhead of a transform-inplace filter is scarcely more than that of a function; however, by packaging the transform as a filter, you get the full flexibility of the filter graph architecture.
Some reasons that a filter might be written as a copy transform filter rather than a transform-inplace filter include the following:
- If the transformation generates more data on output than space provided in the allocator of the input (for example, a decompressor filter), or if the transformation generates less data on output and must consolidate memory.
- If the original media data must be preserved; this is the case with the splitter, where the transform filter splits off a stream of data.
- If a decompressor filter is performing temporal compression, relying on adjacent frames for delta information. In this case, a separate copy must be made, primarily because the decompressor cannot allow another filter to have access to the original data to modify it.
- If the filter relies on a queue; for example, a filter that
creates a queue to help smooth the delivery of irregularly spaced
video frames would need to copy the samples.
Last updated on Tuesday, May 18, 2004