GDCL Home / GMFBridge

GMFBridge

Multiple Graphs in DirectShow

Applications sometimes need to start and stop some filters independently of others, and to switch connections dynamically. GMFBridge is a multi-graph toolkit that shows how to use multiple DirectShow graphs to solve these problems. There are two example applications (in C++ and VB6)In this article, Geraint Davies shows how to solve these problems using multiple, related graphs of filters. The accompanying source code includes GMFBridge: GMFPlay shows how to view multiple clips as a single movie, and GMFPreview demonstrates how to keep showing the preview stream from a video capture device while starting and stopping capture into different files.

Published: November 2004. Latest update March 2007.

Download here:

• Multiple Graphs in DirectShow article (requires Acrobat Reader 5.0 or greater)
• Source code to GMFBridge tool and example applications

Some FAQs:

• Don't forget to register the DLLs with regsvr32.
• There are VC6 .dsp project files if you don't have VS.NET 2003. For the sample apps, you'll need WTL 7.1 which you can download here.
• With VC6, if you see an error with LONG_PTR in building GMFBridge_h.h from the idl file, make sure that your DirectX 9 SDK include files are higher on the include path than the VC98 include files.
• If you want to view the graphs used, re-enable the Running Object Table code in BridgeSink::JoinFilterGraph and BridgeSource::JoinFilterGraph and then use
• GraphEdt's Connect To Remote Graph feature. This is disabled by default as it can lead to refcount leaks.
• If you want to debug problems, a good first step is to create an empty text file "gmfbridge.txt" in C:\. If this file is present,GMFBridge will write log text to this file during execution.

I'm in the process of adding more notes as a result of all the discussions I've had about GMFBridge, in no particular order below.

1st March 2007

If you switch to a graph with a different audio format, we force a dynamic type change to the new format, and the audio renderer will normally perform this change correctly. To fit the code structure, I originally did this type change by attaching the new media type to a sample returned from the sink-input's GetBuffer, so that the type change would be on the sample as it was handled in the source graph and would then still be attached to the sample as it was passed downstream. However, it's possible for the decoder to clear the type change or simply discard this buffer unused, and in these cases, the type change would never be passed downstream to the audio renderer. The result is that some changes between files would result in the audio being played at the wrong sample rate.

In version 1.0.0.15, I've fixed this in two ways. The proxy sample stores the type change so that even if SetMediaType(NULL) is called on the sample, the bridge can still retrieve the type change and set it again before the sample passes downstream. Secondly, the sink input pin now has a boolean flag indicating that a type change is expected and if the next sample does not contain a type change, will apply the current source-graph type as a type change.

This update also contains fixes for the LOG output in unicode builds and correctly cleans up the notify window used for VB apps (pointed out by Sebastian Zierer).

22 September 2006

If the render graph has been running for a while with the bridge disconnected, and then you connect the bridge, you don't want the timestamps to start at 0. Instead you want to start them at now + however long it takes to get from source to renderer. Essentially, it's when you want the clip to start fresh instead of being contiguous with the previous clip.

In earlier versions of GMFBridge, I tried to detect this situation by heuristics, but this was not always right (generating both false positives and false negatives). In the latest update, you need to explicitly request this: if you are bridging a clip which is not contiguous with the previous clip, when the render graph has been running, then you need to call BridgeOnDiscont(x, x, TRUE) to force the now+latency timing model.

Today's update also fixes a leak in EnumOutputTypes that was pointed out to me by Svante Arvedahl.

12 April 2006 VB Support

Finally I've enabled VB support for the player app, and there is now a GMFVBPlay demo app included in the zip. The bridge controller now supports WithEvents (Connection Points) and an OnSegmentEnd event is raised, which allows the app to switch to the next graph.

As an aside, the source now includes a useful set of classes for anyone wishing to add Connection Point support to their own DirectShow filter.