

Mixing many USB web cams on the cheap for a robot drum machine - simongeist
https://github.com/Sonicrobots/madcam/

======
rasz_pl
some things that made me sad when reading this github:

> One USB Host can theoretically take up to 127 client, but we found out only
> 1-2 Cameras per host controller work without glitches and missing frames.

and you didnt realize what is the real reason (not the limit of 7 bits address
field in USB protocol)? No one bothered to do a simple calculation
640x480x2x30 per camera? :( btw USB 2.0 in reality is able to sustain ~40MB/s,
hence 2 cameras at 30Hz max per controller = ~37MB/s.

>PCI can process less data then PCIExpress, so it is best to build your system
on PCIe cards

PCI is ~130MB/s, plenty for 6 cameras, again no numbers

Of course you could simply find cheap cameras with building mjpeg compression
and avoid adding external usb controller cards - Great source for cheap camera
modules is laptop service parts. For the last 10 years USB webcams have been
standard in laptops. Example ebay auction

[http://www.ebay.com/itm/Macbook-iSight-Camera-replacement-
fo...](http://www.ebay.com/itm/Macbook-iSight-Camera-replacement-
for-A1342-/381214713303)

ISight supports:

MJPEG 640×480 @ up to 60fps

MJPEG 720×480 @ up to 60fps

MJPEG 800×600 @ up to 30fps

MJPEG 1024×576 @ up to 30fps

etc ...

and all of a sudden we have <3MB/s per $3 camera.

------
bayesianhorse
I 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.

~~~
pronoiac
Was this the module you were looking at?

[http://www.auvidea.com/index.php/theme-
styles/2013-06-22-21-...](http://www.auvidea.com/index.php/theme-
styles/2013-06-22-21-23-34/raspberry-pi-hdmi-in)

I'd heard the GPU was getting better docs, and I wondered if it would help
handle this.

~~~
bayesianhorse
According to the site the board is already in production, but there is no
further indication on when or where to buy. I don't think GPU docs will help
enough. And then there's the issue of a completely new RPi2 SoC to consider...

~~~
rasz_pl
Gpu docs wont, but videocore docs would, sadly Broadcom is hostile and will
most likely never release low level stuff, same goes for mipi dsi LCD
interface.

Pee2 uses same videocore, only difference is CPU IP.

------
kyberias
This 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...](https://msdn.microsoft.com/en-
us/library/windows/desktop/bb970394%28v=vs.85%29.aspx)

------
erik
"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.

~~~
tlb
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.

~~~
erik
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.

~~~
tlb
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.

~~~
kuschku
couldn’t USB use a GSM-like model instead? with specific timeslots?

~~~
tlb
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.

------
p1mrx
It's nice to see some real-world IPv6 web hosting beyond the usual Google and
CloudFlare:

[http://bgp.he.net/dns/sonicrobots.com#_ipinfo](http://bgp.he.net/dns/sonicrobots.com#_ipinfo)

