我可以指望能够在筛选器图表之间共享 DirectShow 捕获筛选器吗？
我今天使用我组装的 DirectShow 图进行了测试，该图在图的顶部分配了一个分配给我的 VOIP 电话的捕获过滤器。该应用程序从捕获过滤器获取音频并写入 WAV 文件，作为过滤器图表操作的一部分。出于好奇，我运行了该程序的两个副本，完全期望其中一个会抛出错误，抱怨捕获设备“正在使用”。令我惊讶的是，该程序的两个副本都运行良好，并且每个副本都创建了自己的录制音频 WAV 文件。两个文件中的音频都很流畅，没有问题，并且就所包含的音频数据而言是双胞胎。
我可以依靠所有 DirectShow 捕获过滤器来展示在多个过滤器图表之间共享的能力吗？或者每个设备/驱动程序都不同？
I ran a test today with a DirectShow graph I assembled that had a Capture Filter assigned to my VOIP phone at the top of the graph. The app takes the audio from the capture filter and writes a WAV file, as part of the filter graph's operations. Out of curiosity I ran two copies of the program, fully expecting one of them to throw an error complaining that the capture device was "in use". Much to my surprise both copies of the program worked fine and each created its own WAV file of the recorded audio. The audio in both files was smooth and without problem and twins of each other in regards to the contained audio data.
Can I count on all DirectShow capture filters to exhibit the ability to be shared between multiple filter graphs? Or is every device/driver different?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果过滤器实例不在内部共享任何独占访问资源（例如硬件、特定 TCP 端口等），您可以在一个进程或多个进程中自由复制它们。特定过滤器仅在整个系统的单个实例中处于活动状态并不意味着。
重要示例包括：
USB 视频捕获：视频捕获设备通常仅供一个应用程序使用，因此一旦它处于活动状态，它就会被锁定，其他应用程序或过滤器实例都无法从中捕获
音频播放：流行的用户模式 API音频是实际播放实现之上的一层，内部由驱动程序混合来自多个支持音频的应用程序的音频；因此，当您播放音频时，不涉及独占锁，因为实际上设备在应用程序之间共享，并且运行着代码，透明地组合来自应用程序的音频。
If the filter instances don't share internally any exclusive access resources (such as hardware, specific TCP ports etc), you are free to duplicate them within a process, or in multiple processes. There are no implications as for specific filter to be only active in a single instance throughout the system.
Important example include:
USB video capture: a video capture device is normally intended to be used by one application only, so as soon as it is active it is locked no other application or filter instance can capture from it
Audio playback: popular user mode API for audio is a layer on top of actual playback implementation, internally a driver mixes audio from mutliple audio-enabled applications; so when you play audio, there is no exclusive lock involved because actualy device is shared between applications and there is code running around which combines audio from the applications transparently.