Mixing many USB web cams on the cheap for a robot drum machine
1–10 of 16 posts
Re: Mixing many USB web cams on the cheap for a robot drum machine
#2"The bottleneck here is the USB Host controller. One USB Host can theoretically take up to 127 client, but we found out only 1-2 Cameras per host controller (PCI / PICe card) work without glitches and missing frames."
Ouch. That's disappointing, but I suppose unsurprising. I wonder if USB 3 fares any better here than USB 2.
Re: Mixing many USB web cams on the cheap for a robot drum machine
#3This reminds me of the wonderful (but overly complex) Microsoft DirectX DirectShow framework. I suspect similar functionality exists there out-of-the box:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
Re: Mixing many USB web cams on the cheap for a robot drum machine
#4"The bottleneck here is the USB Host controller. One USB Host can theoretically take up to 127 client, but we found out only 1-2 Cameras per host controller (PCI / PICe card) work without glitches and missing frames." Ouch. That's disappointing, but I suppose unsurprising. I wonder if USB 3 fares any better here than USB 2.
The bottleneck is probably just the 480 Mbps of the bus itself. Each camera requires (30 fps) * 640 * 480 * (1 byte/pixel in bayer mode) * (8 bits/byte), about 72 Mbps. With various overheads, you shouldn't expect to get more than 2 working on a 480 Mbps bus.
There almost no buffering on the camera. Standard cheap USB cameras have only 1 or 2 scan lines of memory onboard, so they need to deliver a scan line every 70 uS or it gets lost.
Re: Mixing many USB web cams on the cheap for a robot drum machine
#5I recently tried researching how to mix/record not so cheap cameras on a PC/Laptop/RasPi analogue. Remarkably tricky, because of the data rates involved. So far I have not seen a single affordable, open source compatible solution for "just" taking hdmi signals in. At least not for 1080p.
I have modest hopes that such controllers might show up in the next years, maybe using USB 3 technology. There is also a Raspberry Pi module "in the works", which may be capable of at least streaming compressed 1080p from HDMI, but I'm not holding my breath.
Re: Mixing many USB web cams on the cheap for a robot drum machine
#6"The bottleneck here is the USB Host controller. One USB Host can theoretically take up to 127 client, but we found out only 1-2 Cameras per host controller (PCI / PICe card) work without glitches and missing frames." Ouch. That's disappointing, but I suppose unsurprising. I wonder if USB 3 fares any better here than USB 2.
The bottleneck is probably just the 480 Mbps of the bus itself. Each camera requires (30 fps) * 640 * 480 * (1 byte/pixel in bayer mode) * (8 bits/byte), about 72 Mbps. With various overheads, you shouldn't expect to get more than 2 working on a 480 Mbps bus. There almost no buffering on the camera. Standard cheap USB cameras have only 1 or 2 scan lines of memory onboard, so they need to deliver a scan line every 70…
2 x 72 Mbps leaves a theoretical 336 Mbps of bandwidth lost to overhead, which seems pretty bad, even for USB. But I realize that dealing with multiple simultaneous streams is a harder problem than just raw bandwith.
Your point about the scan lines is interesting. I wonder if the drivers for your typical webcam can deliver partial frames, or if they need to capture a full set of scanlines in order to not drop the frame.
Re: Mixing many USB web cams on the cheap for a robot drum machine
#7Earlier quoted context omitted.
The bottleneck is probably just the 480 Mbps of the bus itself. Each camera requires (30 fps) * 640 * 480 * (1 byte/pixel in bayer mode) * (8 bits/byte), about 72 Mbps. With various overheads, you shouldn't expect to get more than 2 working on a 480 Mbps bus. There almost no buffering on the camera. Standard cheap USB cameras have only 1 or 2 scan lines of memory onboard, so they need to deliver a scan line every 70…
2 x 72 Mbps leaves a theoretical 336 Mbps of bandwidth lost to overhead, which seems pretty bad, even for USB. But I realize that dealing with multiple simultaneous streams is a harder problem than just raw bandwith. Your point about the scan lines is interesting. I wonder if the drivers for your typical webcam can deliver partial frames, or if they need to capture a full set of scanlines in order to not drop the fra…
I just looked at a driver I wrote several years ago. Each pixel is actually 2 bytes, luma and chroma. So it's 144 Mbps per camera. The scan line packets don't have any indication of which scan line they're from, so if you miss one you'll have the rest of the frame shifted up. I imagine reasonable drivers might drop the whole frame rather than show such an ugly artifact.
There is indeed a lot of overhead on USB. Each packet has to be requested by the host which polls each source round-robin.
Re: Mixing many USB web cams on the cheap for a robot drum machine
#8I recently tried researching how to mix/record not so cheap cameras on a PC/Laptop/RasPi analogue. Remarkably tricky, because of the data rates involved. So far I have not seen a single affordable, open source compatible solution for "just" taking hdmi signals in. At least not for 1080p. I have modest hopes that such controllers might show up in the next years, maybe using USB 3 technology. There is also a Raspberry…
Was this the module you were looking at?
http://www.auvidea.com/index.php/theme-styles/2013-06-22-21-...
I'd heard the GPU was getting better docs, and I wondered if it would help handle this.
Re: Mixing many USB web cams on the cheap for a robot drum machine
#9Earlier quoted context omitted.
2 x 72 Mbps leaves a theoretical 336 Mbps of bandwidth lost to overhead, which seems pretty bad, even for USB. But I realize that dealing with multiple simultaneous streams is a harder problem than just raw bandwith. Your point about the scan lines is interesting. I wonder if the drivers for your typical webcam can deliver partial frames, or if they need to capture a full set of scanlines in order to not drop the fra…
I just looked at a driver I wrote several years ago. Each pixel is actually 2 bytes, luma and chroma. So it's 144 Mbps per camera. The scan line packets don't have any indication of which scan line they're from, so if you miss one you'll have the rest of the frame shifted up. I imagine reasonable drivers might drop the whole frame rather than show such an ugly artifact. There is indeed a lot of overhead on USB. Each…
couldn’t USB use a GSM-like model instead? with specific timeslots?
Re: Mixing many USB web cams on the cheap for a robot drum machine
#10Earlier quoted context omitted.
I just looked at a driver I wrote several years ago. Each pixel is actually 2 bytes, luma and chroma. So it's 144 Mbps per camera. The scan line packets don't have any indication of which scan line they're from, so if you miss one you'll have the rest of the frame shifted up. I imagine reasonable drivers might drop the whole frame rather than show such an ugly artifact. There is indeed a lot of overhead on USB. Each…
couldn’t USB use a GSM-like model instead? with specific timeslots?
USB does have a reserved bandwidth mechanism, called isochronous pipes. However, it's complicated and implementations tend to be buggy so it's not popular except for audio devices.
In any case, it won't help trying to stream more bandwidth than the bus supports.