The following list shows the advantages of using DMOs:

• They are generally smaller and simpler than DirectShow filters because they support less functionality.
  
  
• They are more flexible than DirectShow filters because they do not require a filter graph. You can use them with DirectShow when you need the services that DirectShow provides, such as graph synchronization, intelligent connection, automatic handling of data flow, and thread management.
  
  If you do not need these services, you can access the DMO directly.
  
  
• DMOs always perform synchronous data processing, which eliminates many of the threading issues that filter developers must consider.
  
  
• Unlike Audio Compression Manager (ACM) and Video Compression Manager (VCM) codecs, DMOs are based on the Component Object Model (COM), so they can be extended through the QueryInterfacemethod.
  
  
• DMOs support a more generalized streaming model than ACM or VCM codecs. Like DirectShow filters, DMOs can support multiple inputs and multiple outputs.
  
  

For these reasons, you should implement a DMO rather than a DirectShow filter whenever possible. However, there may be situations when a DMO is not suitable. The following list shows two of the reasons for choosing not to implement a DOM:

• Unusual transport requirements. The DMO Wrapperfilter uses the IMemInputPintransport. If you need some other transport mechanism within a DirectShow application, you must write a filter.
  
  
• Dynamic graph building. If your application performs dynamic graph building, you might need to write your own filter. For example, you might need to control how allocators are created.
  
  

See Also