How to debug c++ DirectShow filter

Question

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?

Crescantia

Answer 1

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

Clapboard

Omigod. I had no idea you could attach the debugger like that. That is spectacular. – Crescantia

Answer 2

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.

Oddity

Answer 3

Some tools for analyzing data flow between filters:

Open source graph editor GraphStudioNext analyzer filter (and analyzer file writer) will show you a visual log of activity when inserted between two filters of interest. You'll need to build it yourself to get this feature for now.

Geraint Davie's monitor filter will write a log file of activity to disk.

Oddity

Answer 4

The best way to debug real time apps is generating log files. If you want to view the log information in real time, just create a client server socket based logging. For example, your app can start listening to a port. An external viewer app (client) could connect to that port and starts receiving the log information in real time.

Lure