directX开发参考资料.pdfVIP

Using Multiple Graphs in DirectShow Page 1 of 8 http://www.gdcl.co.uk 17 October 2005 Using Multiple Graphs in DirectShow Geraint Davies Introduction Overview DirectShow uses a graph of connected filters. Each filter in the graph has the same state (stopped, paused or running) and the same clock, and the data flows directly from filter to filter. While this works well for many tasks, there are a number of tasks for which it is not suited. Applications need to start and stop some filters independently of others, and to switch connections between filters dynamically. In this article, and the accompanying code, I want to demonstrate how to solve some of these problems by using multiple, related graphs of filters. First, some background. Why is it so complicated to change a graph while it’s running? The design of DirectShow is intended to make filters as lightweight as possible, to encourage developers to break down large monolithic processing engines into several separate components with no loss of efficiency. This meant allowing each filter to call directly to interfaces on other filters and not insisting on a thread switch for each filter. The result is that a single thread created by one filter can call down through several other filters and block in a number of places. This has created a low-overhead design, but sadly it has also resulted in much of the complexity of the DirectShow architecture. Only by following the strict rules of DirectShow behaviour can deadlocks be avoided. All the filters in a graph must be in the same state. But the graph itself is a very lightweight object: there is very little additional cost to having the same filters divided between several different graphs. A set of custom filters can then feed the data between graphs, outside of the DirectShow framework, and the graphs can be started and stopped independently. You can do this very straightforwardly without sharing allocators or threads between the graphs: