使用的技术：
=======
申请摘要：
我在C＃/ WPF中开发了一个简单的视频编辑器，其中包含一个自定义WPF时间轴控件，该控件通过DirectShow.NET连接到DES，并且主要基于DirectShow.NET附带的DESCombine.cs示例。该应用程序的用户可以将视频和图像添加到时间线，并选择要在后台播放的歌曲。
最终目标是将时间轴内容（ds图形内容）呈现给基于wmv的文件。这主要是通过选择prx配置文件并启动正确构建的图形来完成的。
在添加到时间轴/ directshow图表之前，所有输入视频都会转换为wmv8，因此连接引脚时不需要特殊的第三方directshow过滤器。
=======
问题和疑问：
有时但并不总是，Directshow在最终视频文件的渲染过程中抓住。没有例外，cpu使用率只是降到0并且没有任何反应。由于我通过DirectShow.NET访问DirectShow并且我不知道幕后发生了什么，因此很难调试。虽然我启用了非托管调试，但没有抛出异常，我不知道出了什么问题。
我可以更频繁地告诉这个问题，因为图表的引脚越来越多。例如，渲染具有50个视频和图像的时间轴比仅渲染一些图像和视频更有可能造成这种情况。
如果没有抛出异常或错误指示，我该怎么做才能确切地找出错误以及为什么会这样？
=======
我尝试过：
设置图形的日志文件（使用IGraphBuilder :: SetLogFile）。
此日志确实表明某些引脚无法连接，但是当渲染完成并失败时，日志看起来完全相同。
IntPtr hfile = CreateFile("c:\\dslog2.txt", GENERIC_WRITE, 0, IntPtr.Zero, OPEN_EXISTING, 0, IntPtr.Zero);
m_pGraph.SetLogFile(hfile);
当我检测到它被筛选时，使用IMediaControl暂停并运行图表。这没有任何作用。
m_pControl.Pause();
Thread.Sleep(2000);
m_pControl.Run();
=======
提前感谢您，非常感谢任何帮助。
答案 0 :(得分：0)
如果你有一个包含许多来源的时间表，你很有可能从DES中获得“内存不足”的错误。或DES简单地破坏，因为DES是DirectShow中真正有缺陷的部分。听起来你没有使用动态模式？ Dynamic mode会自动重新连接DES-Filter并删除未使用的源，因此内存消耗不会太大。