I' like to set up three web cameras on a Windows 10 computer, to allow simultaneous video capture from all three of them. All three USB2.0 cameras are connected to a powered USB3.0 hub, which is connected to the PC. The cameras will be used in a low-resolution, low-FPS mode, so the bandwidth of the USB3.0 (and even that of the USB2.0) will be enough for all three of these low-res, low-FPS streams.
The problem is, however, that the cameras are reporting the bandwidth requirement of their maximum-resolution, maximum-FPS stream to the controller, so the UVC driver won't allow using three cameras at the same time (not even two either) if connected to the same USB host controller.
I've managed to set up three cameras using three separate USB controllers, (one built-in in my laptop, and two in my docking station, one of these is a USB2.0 and one in a USB3.0 port), so the problem is clearly caused by connecting these to the same controller using a hub.
Unfortunately, the requirement is to build a final product containing the three cameras, and to have a single USB port from the outside, therefore we need to use a hub.
We've tried the Linux version of this setup, and managed to get this working using one of the 'quirks' modes of the Linux uvcvideo driver, called UVC_QUIRK_FIX_BANDWIDTH:
Try to estimate the bandwidth required for uncompressed streams instead on relying on the value reported by the camera. See FAQ 7 for more information.
As the uvcvideo driver has no way to know how much bandwidth a device will require, devices are responsible for reporting the amount of needed bandwidth to the driver as accurately as possible. Each alternate setting of the video streaming interface corresponds to one possible bandwidth value for the associated endpoint, and the driver then selects the alternate setting with the lowest bandwidth higher than or equal to the bandwidth requested by the device.
While most devices implement several alternate settings and only request the amount of bandwidth they really need, some just always request the maximum bandwidth available to a single endpoint, equal to 198.608 Mb/s excluding protocol overhead. Twice that bandwidth would exceed the high speed USB limit, resulting in -27 (-ENOSPC) errors.
If the device implements several alternate settings the driver could ignore the requested bandwidth and select a lower bandwidth alternate setting. This behaviour is currently implemented through the FIX_BANDWIDTH quirk when using an uncompressed format. Compressed formats are more difficult to work around as the driver has no way to estimate how much bandwidth the device could really require.
The FIX_BANDWIDTH quirk can be safely enabled without risking any adverse effect on the system stability, as it only affects UVC devices. In rare cases it could theoretically underestimate the required USB bandwidth, resulting in loss of USB packets and corrupt images. No such case has been reported in practice as of today.
You can find how how much bandwidth the device requests and which alternate setting the driver selects by setting the uvcvideo module trace parameter to 0x400. The driver will print bandwidth-related information to the kernel log.
More info on this here: http://www.ideasonboard.org/uvc/faq/
So, I'd like to do something similar on Windows, making the UVC driver ignore the bandwidth reported by the cameras, as the actual bandwidth will be much lower than the reported.
Is there any way I can do that? Like using some alternative drivers, or modifying the current ones to allow this 'quirk'?
