DirectShow Technology Introduction (lengthy)-8

3.7. Graph Dynamics (dynamic graph Building)

If you need to modify a filter graph that already exists, you can stop, modify, and restart it. This is usually the best solution. However, in some cases, you might want to modify a graph when it is running, such as:

* The application needs to insert one (Video filter filter) video effect filter in the playback of videos;

*source filter changes the media format during playback, and may need to access a new decoding filter at this time;

* The application adds a new video stream to graph.

All of these are examples of graph dynamic reconstruction. All graph modifications that are made while graph is still in operation are called graph dynamic rebuilds. Dynamic rebuilds can be initiated by an application or by a filter in graph. There are three possible types of dynamic reconstructions:

* Media Format Dynamic change: A filter can change the media format in the middle of the run, without having to be replaced by another;

* Dynamic re-connect: Add or remove filter in graph

*filter Chain actions: Add, remove, control filter chain, (filter chain is a filter link connected to each other, and each filter in the link has an input pin up to one output pin)

3.7.1. Dynamic re-connection

In the vast majority of DirectShow filter, when graph is running, the pin cannot be reconnected, and the application must stop graph before reconnection. However, some filter supports dynamic re-interconnection, which can be performed either by the application or by a filter in graph.

Suppose we want to remove filter 2 from graph and replace it with another filter, and when graph is still running, you must have the following conditions:

The input pin (pin D) of *filter 3 must support the Ipinconnection interface, which can reconnect the pin without having to stop it.

The output pin (pin a) of *filter 1 must be able to block media data when it is re-connected, and data is no longer passed between pin A and pin d. In other words, the output pin must support the IPinFlowControl interface. However, if filter 1 is the filter that initiates the re-connection, it may have been blocked within it;

Dynamic re-interconnection includes the following steps:

1. Block data flow from pin a

2. Reconnect pin A and pin D, or add a new filter in the middle

3. Cancel blocking on pin a

Step 1. Blocking Data Flow

Block the data flow by calling the Ipinflowcontrol::block method on pin a. This method can be called synchronously or asynchronously. To invoke this method asynchronously, you create a Win32 event object and pass the event handle to block, and the method returns immediately, and then uses WaitForSingleObject or other functions to wait for the event to fire. When the blocking work is complete, the pin triggers the event. Such as:

Create an Event

HANDLE hevent = CreateEvent (null, FALSE, FALSE, NULL);

if (hevent! = NULL)

{

Block the data flow.

hr = Pflowcontrol->block (Am_pin_flow_control_block, hevent);

if (SUCCEEDED (HR))

{

Wait for the pin to finish.

DWORD dwres = WaitForSingleObject (hevent, dwmilliseconds);

}

}

If you are calling block synchronously, then simply set the incoming hevent parameter to NULL, at which point the method will block until the blocking work is complete. If the pin is not ready to deliver a new sample, it will be blocked all the time. If filter is in a ready state, this can take an arbitrary amount of time, so do not use synchronous calls in the main thread of the application to avoid deadlocks, open a worker thread to use synchronous calls, or simply use asynchronous calls.

Step 2. Re-connect Pin

To reconnect the pin, query the graph's Igraphconfig interface and call Igraphconfig::reconnect or igraphconfig::reconfigure. The reconnect method is relatively simple to use:

* Stop the intermediate filter (such as filter 2) and remove it

* If necessary, add a new intermediate filter

* Connect all the pins

*pause or Run all new filter so that its state is the same as graph

The Reconnect method has parameters that you can use to specify the media type and intermediate filter for the PIN connection. Such as:

Pgraph->addfilter (Pnewfilter, L "New Filter for the Graph");

Pconfig->reconnect (

Ppina,//reconnect this output pin ...

Ppind,//... to the this input pin.

Pmediatype,//Use the This media type.

Pnewfilter,//Connect them through this filter.

Null

0);

If reconnect is not enough to meet our requirements, then you can use the Reconfigure method, which invokes an application-defined callback function to re-connect the pins. To invoke this method, you need to implement the Igraphconfigcallback interface in your application.

Block the output pin's data flow as previously described before calling reconfigure. Then push the data in the pending state, as shown below:

1. Call the Ipinconnection::notifyendofstream method on the longest downstream input pin (pin D in the example) on the re-connected link, and the parameter of the method is a Win32 event handle;

2. Increase the Ipin::endofstream method on the input pin that is directly connected to the output pin that is blocking the data. (In the example, the output PIN to block is pin A, then the input pin that is directly connected to it is pin B);

3. Wait for the event to fire. Enter a PIN (PIN D) to trigger an event when it receives a End-of-stream event advertisement. This means that no more data needs to be transferred, and it can be securely re-connected at this point.

Note: The Igraphconfig::reconnect method automatically handles the above steps, and you only need to handle them when you call the reconfigure method.

When the data completes the push, call reconfigure, passing in a pointer to the Igraphconfigcallback callback function. The Filter Graph Manager calls the Igraphconfigcallback::reconfigure method.

Step 3. Suppress blocking of data streams

When you have finished the re-connection, by calling Ipinflowcontrol::block, the first parameter is zero blocking.

Note: If the dynamic re-connect is performed by a filter, then you need to know a little bit about threading issues. If the filter Graph manager tries to stop the filter, it may deadlock because graph waits for the filter to stop, while the filter may be waiting for the data to complete the push in graph. To prevent this possible deadlock problem, as described earlier, can be handled with an event mechanism.

3.7.2. Filter chain (filter chains)

A filter chain is a series of mutually connected filters with the following conditions:

* Each filter in the chain has a maximum of one connected input pin and one connected output pin;

The data stream in the *filter link does not depend on the other filter outside the link

For example, in the following figure, filter a-b,c-d and f-g-h are a filter chains. The sub-chains (F-g and G-h) in each f-g-h are also a filter chain. A filter chain can also be composed of a single filter, so a, B, C, D, F, G, and H are also filter chain. Filter E is not a filter chain because it has two input connections, so any series of filter containing e is not.

The Ifilterchain interface provides the following methods to control the filter chain:

Ifilterchain::startchain Open a chain

Ifilterchain::stopchain Stop a chain

Ifilterchain::P ausechain suspend a chain

Ifilterchain::removechain remove a chain from graph

There is no special way to add a chain, to add a chain, to insert a new filter by calling the Ifiltergraph::addfilter method, and then call Igraphbuilder::connect,igraphbuilder:: Render or a similar method to connect them.

When graph is running, a filter chain can switch between the run and stop states. When graph is in a ready state, it can switch between ready and stopped states. Here are the two only filter chain state transitions possible.

Filter Chain Guide

When you use the Ifilterchain method, it is necessary to confirm that the filter in graph supports the filter chain operation, otherwise a deadlock or graph error may occur. The filter connection to the chain must occur after the chain state changes.

The best case for using Ifilterchain is to use a filter that is designed with a system for chaining. Use the following guidelines to ensure that your filter is safe for chain operation.

* Data processing that is invoked on the filter chain boundary must be completed before the filter chain state changes. This rule applies to imeminputpin::receive, Ipin::newseqment, and Ipin::endofstream methods. The filter in the chain must be returned from these method calls implemented by the out-of-chain filter, and the filter outside the chain must be returned from these method calls that are implemented by the filter in the chain.

For example, in the above figure, filter B must complete all the data processing calls on filter a, and filter E must complete the call from Filter d. If the pin exposes the IPinFlowControl and Ipinconnection interfaces, as described in the dynamic re-connect section, you can call Ipinflowcontrol::block and igraphconfig: Pushthroughdata method to push data. Filter may also push data in its own way.

* Upstream filter must be changed along with the state of the chain. For example, in the above illustration, if the chain is stopped, but filter a calls the Imeminputpin::receive method, the call fails, and as a response, filter a stops the flow. When the application re-opens the chain, there is no effect because filter a no longer breathed data flow.

* Downstream filter must also change with the state of the chain, otherwise, the downstream filter will deadlock when it waits for sample, because sample will not come again. For example, the multiplexing (MUX) filter always requires data on all of its input pins, and if one of the input pins is suspended, stream processing on the other input pins is blocked. This will cause graph deadlock

* The pin of each external filter connected to the internal filter of the chain must have its own allocator (allocator), which cannot be shared by other pin connections. When the state of the chain changes or is removed from graph, the allocator is unavailable, and if there are other connections using the allocator, they will no longer be able to process the sample.

* Do not remove the chain unless the filter supported by the link is dynamically disconnected. Typically, the connected filter supports the ipinconnection or IPinFlowControl interface, or replaces it with its own defined interface.