4 ms·

"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 (PC

by erik 12y ago

"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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      couldn’t USB use a GSM-like model instead? with specific timeslots?
      - tlb 12y ago
        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.

by erik 12y ago

tlb 12y ago

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 12y ago
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 12y ago
  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 12y ago
    couldn’t USB use a GSM-like model instead? with specific timeslots?
    - tlb 12y ago
      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.