IMemAllocator：GetBuffer 挂起
有谁知道 IMemAllocator:GetBuffer 除了所有正在使用的示例之外，(Directshow) 挂起？
我有一个 directshow 应用程序，它使用 Geraint Davies 的 GMFBridge 连接两个图形。 GMFBridge 用于能够切换输入，但我在这种情况下不会进行切换。该应用程序捕获音频和视频，并且应该不间断地执行此操作。但大约10个小时后就停止了。我发现音频和视频都陷入了对 IMemAllocator:GetBuffer 的调用中：
/* _COM_SMARTPTR_TYPEDEF(IMemAllocator, IID_IMemAllocator); */
/* IMemAllocatorPtr m_pCopyAllocator; */
hr = m_pCopyAllocator->GetBuffer(&pOut, NULL, NULL, 0);
如果所有样本都在使用中，则此函数可能会阻塞，但我很确定情况并非如此。有两个线程调用此函数，一个用于视频，一个用于音频样本。音频线程首先阻塞，在 GetBuffer 返回近 60 个视频样本的缓冲区后，视频线程也阻塞。 （大约 2 秒后）
大约 8 小时后，两个线程都会继续一小段时间，首先是音频线程，返回音频样本的 45 个缓冲区后，视频线程也解除阻塞。
因此，因为两个线程不会同时阻塞，所以在我看来，所有样本都在使用中没有问题。
堆栈跟踪显示当时正在调用quartz.dll 内的一个函数。
更新
看来电脑上已安装的解码器过滤器导致了内存泄漏。该图包括 mpeg 的解码，例如使用 Cyberlink 解码器进行音频解码。安装ffdshow后，改用ffdshow音频+视频解码器，问题似乎消失了。吸取的教训是，不要自动依赖现有的过滤器。
Does anybody know any reasons why IMemAllocator:GetBuffer (Directshow) hangs, apart from all samples being in use?
I have a directshow application which uses GMFBridge by Geraint Davies to connect two graphs. The GMFBridge is used to be able to switch inputs, but I am not switching in this situation. The application captures audio and video, and should do that non-stop. But after about 10 hours it stops. I found out both audio and video got stuck in a call to IMemAllocator:GetBuffer:
/* _COM_SMARTPTR_TYPEDEF(IMemAllocator, IID_IMemAllocator); */
/* IMemAllocatorPtr m_pCopyAllocator; */
hr = m_pCopyAllocator->GetBuffer(&pOut, NULL, NULL, 0);
If all samples are in use, this function can block, but I am pretty sure this is not the case. There are two threads calling this function, one for the video and one for the audio samples. The Audio thread blocks first, and after the GetBuffer has returned a buffer for almost 60 video samples, the video thread blocks too. (this is about 2 seconds later)
After almost 8 hours both threads continue for a small period, first the audio thread, and after 45 buffers for audio samples have been returned, the video thread unblocks too.
So because both threads do not block at the same time, it looks to me there is not a problem with all samples being in use.
The stacktrace shows a function inside quartz.dll is being called at that moment.
UPDATE
It looks like there was a memoryleak caused by decoder filters already installed on the pc. The graph included decoding of mpeg, for example the audio decoding used a cyberlink decoder. After installing ffdshow, the ffdshow audio + video decoder was used instead, and the problem seems to be disappeared. Lesson learned, do not depend automatically on existing filters.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不确定我是否可以根据给出的信息进行调试。您可以创建一个日志文件（创建一个空文件 c:\gmfbridge.txt，运行直到它挂起，然后压缩该文件并通过电子邮件发送）。另外，如果您使用 _NT_SYMBOL_PATH 设置符号，则可以查看堆栈跟踪以查看各个线程在quartz.dll 中的位置。
G
Not sure that I can debug this from the info given. Can you create a log file (create an empty file c:\gmfbridge.txt, run until it hangs, then zip the file and email it). Also, if you set up your symbols with _NT_SYMBOL_PATH, you could look at the stack trace to see where in quartz.dll the various threads are.
G