Mixing many USB web cams on the cheap for a robot drum machine | Hacker News Reader

Mixing many USB web cams on the cheap for a robot drum machine

github.com

27 pointssimongeist15 comments

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

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.

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.

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.

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

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.

From the writup on this page it seems Pee camera module works in RAW mode. This is weird and uncommon.

define cheap?

Those guys are working on hdmi-to-parallel CSI input converter for Olimex A10/A20 Linux SBCs

https://videobrick.wordpress.com/

Then there is this guy cooking hdmi-to-mipi CSI for the Pee

http://theiopage.blogspot.com/

then you have chinese HDMI over Ethernet extenders (~$75 free shipping), they compress 1080 to mjpeg, you can throw away receiver and just slurp that data into your computer

https://hdmiextender.codeplex.com/

1080i hdmi pcie capture cards start at $40, $50 for 1080p with borders (not 1:1), $65 Trident chipset proper 1080p grabbers

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

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

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.

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.

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.

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

Reply on news.ycombinator.com