Click here to Skip to main content
15,884,388 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I've written a DirectShow push filter for use with Skype using Delphi Pro 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
Posted

Hello roschler,

dropped udp packages? CoInitialize/CoInitializeEx propblems?

My advice would be to wrap it into try..except and log into the system event log. You could also log the thread activity so you can detect if anything or nothing is happening. This could give you more info on what's happening and where the stalling of your filter comes from. Hopefully this helps you a bit further, good luck!!!

Etienne
 
Share this answer
 
"dropped udp packages? CoInitialize/CoInitializeEx propblems?

My advice would be to wrap it into try..except and log into the system event log. You could also log the thread activity so you can detect if anything or nothing is happening. This could give you more info on what's happening and where the stalling of your filter comes from. Hopefully this helps you a bit further, good luck!!!"

Hello Etienne,

try..except won't help with the error/failure/etc. appears to be happening outside my code and I do have the entire FillBuffer() call wrapped in one anyways. The numerous OutputDebugString() calls I do show that the FillBuffer() call successfully exits every time. There's no UDP involved from the standpoint of a DirectShow filter, I'm just delivering RGB 32 bits to Skype via the FillBuffer() call. As I said, it appears as if my code just isn't called anymore after a point.

Thanks,
Robert
 
Share this answer
 
Hello Robert,

On the skype website there is an interesting hotfix that addresses to your problem.


With this hotfix we have resolved a security vulnerability in Skype's Extras Manager and fixed video freezing issues for some of our users who were experiencing them.

http://share.skype.com/sites/garage/2009/10/skype_41_hotfix_3_for_windows.html[^]

There is also a known issue list that could maybe help you find out it's not your fault at all ;)

There is also the possibility to post your question on their developer site (maybe you already did... don't know)
https://developer.skype.com/WindowsSkype[^]

Good luck!!! Hopefully you can find some useful information on these sites. Good luck!
 
Share this answer
 
Hello E.F. Nijboer,

It turns out it's a problem that they introduced in a version some time after version 4.1.0.179. That version works fine. But the the 4.2 variants I've tried all fail. I discovered this because fortunately I had 4.1.0.179 on another station I had not upgraded and it did not show the problem. I copied that version to the station that was losing the video stream and the problem vanished immediately. I've posted a long bug report on JIRA:

https://developer.skype.com/jira/browse/SCW-2085

-- roschler
 
Share this answer
 
v2
Hello Robert,

My last answer was quite on the spot then :-D Hopefully they fix it soon and now you know it wasn't you.... and bet it makes you feel a hole lot better :)

Etienne
 
Share this answer
 
Only if they fix it soon, otherwise I'll still feel bad. :)
 
Share this answer
 
It could be memory returning problems.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900