Filter 从DirectShow FillBuffer（）调用调用PeekMessage/GetMessage是否安全？

我有一个使用DSPACK组件库用Delphi6编写的DirectShow过滤器。这是一个推源视频过滤器，它从我还编写的外部协作进程接收其源帧

当创建并运行调用我的筛选器的FillBuffer（）调用的工作线程时，当图形启动时，我从该工作线程所做的第一件事是使用AllocateHWND（）创建一个隐藏窗口，以处理包含外部生成帧的WM_COPYDATA消息。就在线程被破坏之前，我破坏了隐藏的窗口。换句话说，隐藏窗口是在调用FillBuffer（）的工作线程的执行上下文中创建和销毁的。我的目的是让FillBuffer（）在等待WM_COPYDATA或WM_QUIT消息时阻塞。外部协作进程将使用WM_COPYDATA消息和隐藏窗口WndProcc（）的句柄向我的筛选器提交帧。我将在我对pin的Inactive（）方法的重写中发布一条WM_QUIT消息（感谢@RomanR的提示），以便在关闭筛选器之前取消阻止FillBuffer（）调用

---

我的问题是，在这种情况下，从FillBuffer（）调用调用PeekMessage（）或GetMessage（）是否安全？或者，在DirectShow图形执行的上下文中，是否存在由此产生的潜在陷阱？另外，你看到我在这里需要考虑的整体方法有什么缺陷吗？

< P>安全，但也不太合理。正在后台工作线程上调用代码>填充缓冲区，该线程上通常没有窗口。它可能只是您要为其实现消息循环的窗口。此窗口仅用于接收

WM_COPYDATA

消息。这听起来是可行的，但如果没有助手窗口，您可能会更容易通过命名文件映射和事件在应用程序之间传递数据。对于视频（您有音频，对吗？），您还可以享受更小的性能开销。

没有音频，只有来自外部进程处理的RTP会话的视频。此外，隐藏窗口只是默认窗口处理的借口，没有其他窗口消息处理（但我确实按照您对未处理消息的指示调用DefWindowProc（）。我尝试使用由系统页面文件支持的共享内存文件，但我发现写入之间的共享内存区域失效引发的一堆软页面错误非常令人不安（每秒25次）。为什么SendMessage（）调用要比共享内存方法慢得多？使用文件映射，您可以在一侧引发事件，在另一侧看到事件，并接管已经存在的数据。在这里，您肯定有相同的+额外的数据复制（至少一次，然后取决于操作系统实现）+窗口、消息循环+当您在接收方处理消息时，整个处理在发送方被阻止。对于拥有少量数据的音频来说，这不是什么大不了的事，但对于视频来说，它变得越来越重要。是否存在一种共享内存变体，在操作过程中不会产生软页面错误？我真的很想避免这些。链接到更多信息或示例代码（如果有的话），并且您已经拥有了它。谢谢，当然有。它很简单：文件映射+事件到“发送”/指示可用性状态。如果您已经尝试并放弃了这种方法，那么您可能做错了什么。好的，我会再试一次。当我放弃最初的方法时，我不认为我做错了什么。它运行良好，没有错误。我只是不喜欢看到任务管理器中堆积了大量的软页面错误，因为在写入操作使内存映像失效后，每次读取内存区域时都会发生软页面错误，这是操作的正常部分。