DirectShow Filter I wrote dies after 10-24 seconds in Skype video call

I've written a DirectShow push filter for use with Skype using Delphi P开发者_如何学Goro 6 and the DSPACK DirectShow library. In preview mode, when you test a video input device in the Skype client Video Settings window, my filter works flawlessly. I can leave it up and running for many minutes without an error.

However when I start a video call after 10 to 24 seconds, never longer, the video feed freezes. The call continues fine with the call duration counter clicking away the seconds, but the video feed is dead, stuck on whatever frame the freeze happened (although after a long while it turns black which I believe means Skype has given up on the filter). I tried attaching to the process from my debugger with a breakpoint literally set on every method call and none of them are hit once the freeze takes place. It's as if the thread that makes the DirectShow FillBuffer() call to my filter on behalf of Skype is dead or has been shutdown.

I can't trace my filter in the debugger because during a Skype call I get weird int 1 and int 3 debugger hard interrupt calls when a Skype video call is in progress. This behavior happens even with my standard web cam input device selected and my DirectShow filter completely unregistered as a ActiveX server. I suspect it might be some "anti-debugging" code since it doesn't happen in video input preview mode. Either way, that is why I had to attach to the process after the fact to see if my FillBuffer() called was still being called and instead discovered that appears to be dead.

Note, my plain vanilla USB web cam's DirectShow filter does not exhibit the freezing behavior and works fine for many minutes. There's something about my filter that Skype doesn't like. I've tried Sleep() statements of varying intervals, no Sleep statements, doing virtually nothing in the FillBuffer() call. Nothing helps.

If anyone has any ideas on what might be the culprit here, I'd like to know.

Thanks, Robert

---

Deadlock is a common problem in DirectShow and it sounds like that's what's happening. You said you can attach a debugger to your process after it freezes? If you force-break it at that point, where are the threads? If any thread has your code on the stack, then that can give you a hint of what's going on, even if it's actually stuck deep in DirectShow code.

If the debugger is really not working out, then the next fallback is to pepper your code with log messages to see what happens right before the freeze.

---

As always, you can start by splitting your component code.

Turn them on again one by one until you hit the offending code.

Try isolating your problem area. Try unit tests.

You probably have a memory leak or a side-effect in your code which needs addressing.

Good luck.