Differences Between DMOs and DirectShow Filters

Windows Mobile 6.5
A version of this page is also available for

DirectShow filters work only within a DirectShow filter graph. The filter graph manager mediates between the application and the filters in the graph. DMOs do not have this requirement; an application can use a DMO by itself.

In DirectShow, filters do much of the work required to stream data. The following list shows what this work includes:

  • Allocating buffers.
  • Negotiating media types and connections to other filters.
  • Pushing data through the filter graph.
  • Sending events to the filter graph manager.
  • Synchronizing multiple threads.

In contrast, a DMO does none of these things. Instead, these kinds of tasks become the responsibility of the client using the DMO. The client allocates buffers and fills them with data. It then delivers the buffers to the DMO, which processes them, and the client retrieves the output buffers.

Within DirectShow, the DMO Wrapper filter is the client of the DMO, so it handles all of these tasks. Other applications can provide their own implementations.

You must implement either DMOs or a DirectShow filter in order to offload video decoding to a hardware-video decoder, or to offload audio decoding to a hardware-audio decoder.

Some advantages and disadvantages of implementing DMOs and implementing a DirectShow filter are described as follows.


  • DMOs require less methods to implement, and they provide a documented API.
  • DMOs all implement the same base interface, IMediaObject, which simplifies working with the DMOs because you can use the same object, regardless of the type of audio or video transformation being performed.


  • DMOs cannot determine the rate control; trick modes are more difficult to implement and require the use of heuristics. This can create frame dropping. DMO must discover which is the current rate so that it can decode the audio and video appropriately.
  • DMOs cannot determine when playback is paused. If the DMO has deep buffering, it will continue to play even after the playback is paused. This also affects hardware DMOs, which can have very long queues, which in turn can cause a problem for battery life. A hardware DMO is unable to turn off hardware components, even if it is necessary to preserve battery life.
  • DMOs have no control over the number of buffers or memory allocators. The IMediaObject::GetOutputSizeInfo method on the IMediaObject interface only lets you specify size and alignment.
  • DMOs cannot determine a new segment in a media stream. Therefore, DMOs cannot determine whether a channel change has occurred. This does not allow for reset of the internal state.
  • The IDMOQualityControl interface is not ideal for quality control due to the limitations of the interface itself.
  • The Overview of IMediaObjectImpl interface does not provide a method to actively set the output type, which can cause problems.


  • A DirectShow filter provides capabilities to determine all the different events that occur in the filter.


  • A DirectShow filter requires more time to build and more methods to implement.