0

[Actual question is in the last paragraph, I've posted my assumptions and thought process just in case it makes things cleared]

This all started when I wanted to see what happened when too many webcams were streaming on the same USB 2.0 bus. So I intentionally connected three USB 2.0 webcams through one USB 2.0 hub, ensuring a maximum throughput of 480 Mbps (as per the USB 2.0 standard).

And then I streamed all 3 webcams simultaneously; to my surprise, there was no lag, no stutter, no "bandwidth exceeded" scream coming from the USB 2.0 controller.

I was surprised because I knew each webcam's framerate, resolution and the number of color bits per pixel . According to the multiplication:

frames-per-second * height * width * bits-per-pixel

the 3 webcams should have saturated the USB 2.0 bus yet didn't.

I used the AForge framework to capture individual frames: every individual frame was given as a bitmap whose size and bits-per-pixel matched my calculations, the calculations predicting USB 2.0 constipation.

Finally, I observed the USB 2.0 bandwidth usage and while one webcam respected my expected bandwidth consumption, others were twice or more below it.

Actual question:

So, my conclusion (which I hope to have confirmed or corrected) is: webcams transmit over USB whatever they want. It could be a huge bitmap, it could be a JPEG, it could be a proprietary format or even an MPEG4 stream. So the webcam may or may not perform compression on frames before sending them down the USB connection. On the USB host side, the webcam's driver takes whatever the webcam sent over USB and simply reconstructions a bitmap (which is why I always got bitmaps, no matter the actual bandwidth used). How wrong did I get this? If I am correct, is there a convenient database somewhere of what data formats are sent over USB by different webcams?

Improve this question
3
  • The plug-n-play nature of modern PCs require that the "webcam" to be a "video capture & processing" subsystem, with its own 32-bit RISC processor typically running Linux. (Look for a GPL notice in the documentation.) This subsystem includes a more basic "camera", which is called an "image sensor" that typically uses the ISI, image sensor interface, connection. But even the image sensor may have a processing unit as described in this datasheet
    – sawdust
    Oct 28, 2013 at 8:31
  • So looking at the datasheet, and seeing how it mentions several outputs as possible, one of which is compressed, I gather my conclusion is sorta correct: the camera sends what it wants over USB and the driver on the PC side takes care of interpreting it.
    – Alex Teodor
    Oct 28, 2013 at 14:32
  • Instead of guessing and making "conclusions", why don't you read the manuals of the webcams for the output specifications? "camera sends what it wants" -- Not likely; the SoC in the web camera can probably be configured for various outputs. "driver on the PC side takes care of interpreting it" -- The camera device driver (assuming it's well written) only handles the camera interface. The data from the camera is handed off to the image processing subsystem
    – sawdust
    Oct 29, 2013 at 4:55

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .