从 DirectShow 过滤器 FillBuffer() 调用中调用 PeekMessage/GetMessage 是否安全？
我有一个使用 DSPACK 组件库用 Delphi 6 编写的 DirectShow 过滤器。它是一个推源视频过滤器，从我也编写的外部协作进程接收其源帧。
当创建并运行调用 Filters 的 FillBuffer() 调用的工作线程时，当图表启动时，我从该工作线程中做的第一件事是使用 AllocateHWND() 创建一个隐藏窗口来处理包含外部的 WM_COPYDATA 消息生成的帧。在线程被销毁之前，我销毁了隐藏的窗口。换句话说，隐藏窗口是在调用 FillBuffer() 的工作线程的执行上下文中创建和销毁的。我的目的是让 FillBuffer() 在等待 WM_COPYDATA 或 WM_QUIT 消息时阻塞。外部协作进程将使用 WM_COPYDATA 消息和隐藏窗口的 WndProcc() 句柄将帧提交到我的过滤器。我将在引脚的 Inactive() 方法的重写中发布一条 WM_QUIT 消息（感谢@RomanR 的提示），以在过滤器关闭之前解锁 FillBuffer() 调用。
我的问题是，在这种情况下，从 FillBuffer() 调用中调用 PeekMessage() 或 GetMessage() 是否安全？或者在 DirectShow 图形执行的上下文中发生这种情况是否可能出现潜在的陷阱？另外，您是否认为我的整体方法有任何需要考虑的缺陷？
I have a DirectShow filter written in Delphi 6 using the DSPACK component library. It is a push source video filter that receives its source frames from an external cooperating process that I also wrote.
When the worker thread that calls my Filters' FillBuffer() call is created and ran, when the graph starts up, the first thing I do from that worker thread is create a hidden window using AllocateHWND() to process WM_COPYDATA messages that contain the externally generated frames. Right before the thread is destroyed I destroy the hidden window. In other words the hidden window is created and destroyed in the execution context of the worker thread that calls FillBuffer(). My intention is to let FillBuffer() block as it waits for a WM_COPYDATA or a WM_QUIT message. The external cooperating process will submit frames to my filter using a WM_COPYDATA message and the handle to my hidden windows' WndProcc(). I will post a WM_QUIT message in my override of the pin's Inactive() method (thanks for that tip @RomanR), to unblock the FillBuffer() call before the filter is shut down.
My question is, is it safe to call PeekMessage() or GetMessage() from the FillBuffer() call given this scenario? Or are there potential pitfalls that may arise from this occurring in the context of a DirectShow graph executing? Also, do you see any flaws in my overall approach here that I need to consider?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
安全，但也不太合理。 FillBuffer 正在后台工作线程上调用，该线程通常没有窗口。这可能只是您要为其实现消息循环的窗口。而窗口在这里只是为了接收
WM_COPYDATA消息。听起来好像可以解决问题，但是如果没有帮助程序窗口，您可能可以通过命名文件映射和事件在应用程序之间传递数据来轻松得多。如果是视频（有音频，对吧？），您还可以享受到更小的性能开销。Safe, but not so reasonable too.
FillBufferis being called on a background worker thread which is typically have no windows on it. It would be perhaps only your window which you are going to implement message loop for. And the window is here only for the purpose of receivingWM_COPYDATAmessages. It sounds like it can work out, but you would perhaps could do much easier without helper windows by passing your data between applications via named file mappings and events. In case of video (you have audio, right?) you would also be able to appreciate a smaller performance overhead.