opencv - 在openCV中的多个程序中打开相机

Question

如何在用 openCV 编写的多个程序中同时打开一个网络摄像头。顺便说一句，我已经连接了 3 个网络摄像头，并且在 openCV 的任何单个程序中都可以正常工作，但是为什么两个程序不能同时使用它们？

这是限制还是有任何解决方法？

Answer 1

是的，_{这是一种限制}

的意图

为什么？概念 View 与硬件控制层有关。操作系统假设有一些外围设备可以按需使用，但保持它们的使用上下文不可共享。

例如，您可以假设一个 USB 鼠标。虽然它可以在多个进程中使用，但一些推理告诉架构师，一只鼠标不应该将事件馈送到多个进程中 -_{( window )-framed} -context_{(是的，没错，又名进程)}

一些其他外围设备甚至是 EventSENSOR 和 EventCOLLECTOR 的实例，例如 USB 相机可以接收和处理来自操作系统的信号以重新调整它们的物理状态(以 Pan-Tilt-Zoom 为例)。

更明显的是 1:1 关系假设，这是我们有时可能不希望在那里硬编码的东西。另一方面，如果一个进程指示它 go-left 而另一个 go-right 同时？

同样，如果一个 USB 鼠标将它的 Action 和其他 MMI 交互事件发送到所有当前正在运行的进程，谁会高兴？至少拖放 UI 导航策略将成为一个有趣的彩票。

是的，_{有一个解决方法}

最简单的“just-enough”场景包括 aCameraControllerPROCESS，它与 USB 设备保持 1:1 关系，并具有视觉 < strong>data-获取责任。在这里纳秒很重要，所以除了将字节移入缓冲区外，不要将任何 CPU_CLK 花在任何其他事情上。所有其他处理应留在 aVisualDataViewConsumerPROCESS 上，其中 openCV 可能_(并且将)花费数十和数百微秒。

此外，它还有一个通信/服务提供部分，它允许其他分布式进程以并行方式(在非阻塞、并发 View 中)访问获取的可视化数据方式，这是分布式软实时处理所必需的)。

如果一个人的架构需要更多功能或替代方案，这种分层方法允许在添加功能的同时将控制和性能开销保持在可接受的范围内。

如果将 ZeroMQ 与它的零复制 inproc: ^{virtually abstract} 传输类，其中作为技巧的代价确实失去了几乎零延迟，但获得了强大的强大功能，可大规模分发 _{一个可以扩展到超过一个，两个，十几个，数千个......你的名字......免费主机}