我编写的 DirectShow Filter 在 Skype 视频通话中 10-24 秒后失效
我使用 Delphi Pro 6 和 DSPACK DirectShow 库编写了一个与 Skype 一起使用的 DirectShow 推送过滤器。在预览模式下，当您在 Skype 客户端视频设置窗口中测试视频输入设备时，我的过滤器可以完美运行。我可以让它运行很多分钟而不会出现错误。
然而，当我在 10 到 24 秒（绝不会更长）后开始视频通话时，视频画面就会冻结。通话继续正常，通话时间计数器点击秒数，但视频源已停止，卡在冻结发生的任何帧上（尽管很长一段时间后它变黑，我相信这意味着 Skype 已经放弃了过滤器）。我尝试从调试器附加到进程，并在每个方法调用上设置一个断点，一旦冻结发生，它们都不会被命中。就好像代表 Skype 对我的筛选器进行 DirectShow FillBuffer() 调用的线程已死亡或已关闭。
我无法在调试器中跟踪我的过滤器，因为在 Skype 通话期间，当 Skype 视频通话正在进行时，我会收到奇怪的 int 1 和 int 3 调试器硬中断调用。即使我选择了标准网络摄像头输入设备并且我的 DirectShow 过滤器完全未注册为 ActiveX 服务器，也会发生此行为。我怀疑这可能是一些“反调试”代码，因为它不会在视频输入预览模式下发生。无论哪种方式，这就是为什么我必须在事后附加到该进程，以查看我调用的 FillBuffer() 是否仍在被调用，而不是发现它似乎已经死了。
请注意，我的普通 USB 网络摄像头的 DirectShow 过滤器不会表现出冻结行为，并且可以正常工作很多分钟。 Skype 不喜欢我的过滤器。我尝试过不同时间间隔的 Sleep() 语句，没有 Sleep 语句，在 FillBuffer() 调用中几乎没有执行任何操作。没有任何帮助。
如果有人对这里的罪魁祸首有任何想法，我想知道。
谢谢， 罗伯特
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
死锁是 DirectShow 中的一个常见问题，听起来就是这样。你说你可以在你的进程冻结后附加一个调试器？如果你在那时强行破坏它，线程在哪里？如果任何线程在堆栈上有您的代码，那么这可以给您提示正在发生的事情，即使它实际上深陷在 DirectShow 代码中。
如果调试器确实无法正常工作，那么下一个后备措施是在代码中添加日志消息，以查看冻结之前发生的情况。
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.