What debugging tools are available for directshow filters? Presently, I have a project that compiles and registers a video source filter that I then setup a graph in GraphEdit. I am using c++ in visual studio 2008. Is it possible to get a debugger attached to the filter in any way where I could set break points, inspect variables, etc? Barring that is there a way to log diagnostic information somewhere that I can view in real time?
In this article. The following DirectShow interfaces have been deprecated. They are still supported for backward compatibility with existing applications, but new applications should not use them.
DirectShow provides a set of default filters in Windows. These filters support many data formats while providing a high degree of hardware independence. An application can also register and install custom filters on the target system.
DirectShow simplifies media playback, format conversion, and capture tasks. At the same time, it provides access to the underlying stream control architecture for applications that require custom solutions. You can also create your own DirectShow components to support new formats or custom effects.
There should be no problem with attaching a debugger. Set graphedt.exe as the debug target in your filter's Visual Studio project and you should be able to set breakpoints in your code. If you're having difficulty with this, it might be because of the anti-debugging logic in some decoders — you'll have to avoid using those.
You can also get useful debug information by logging the deliveries and their timestamps and latency. The best way I find to do ths is to use a pass-through filter. There is an example monitor filter like this available in source and binary form from www.gdcl.co.uk/mobile (win32 and win mobile).
G
In a debug build, the DirectShow base classes already include a flexible logging mechanism controlled by registry keys. The base classes themselves use this mechanism to log their own operation. If required it should be possible to modify the base classes so that logging is available in a diagnostic release build.
A simple example:
DbgLog(( LOG_TIMING, 1, TEXT(__FUNCTION__ " : Frame:%d, Stream Time:%dms, Sample Time:%dms"),
(int)currentFrame, (int)currentTime, (int)sampleTime ));
This produces log output prefixed by the name of the calling function if the logging level for the 'TIMING' category is set to >=1. Logging levels for each category are configured in the registry under the key below. There is a 'GLOBAL' sub-key for the minimum logging level for all filters and sub-keys for extra logging by filter file name.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectShow\Debug HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectShow\Debug (32bit code on x64 Windows).
Edit the 'LogToFile' key for each filter to specify a logging destination. This defaults to 'Debug' (debugger output) but can also be 'Console' to log to a console window, or a file name to log to. Other types of logging could be added too.
The console option is particularly convenient for live monitoring without a debugger. On my system the base classes fail to open a console window if not already open so I added the following tweak in wxdebug.cpp to open a console unconditionally if console output is requested.
if (!lstrcmpi(szFile, TEXT("Console"))) {
AllocConsole (); // modification - always allocate console if using Console output
See DirectShow Debug Output Functions for further information.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With