Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Running more than one USB webcam in Debian/Linux results in the the following error:

libv4l2: error turning on stream: No space left on device
VIDIOC_STREAMON: No space left on device

What initially seemed to be a programming issue in OpenCV turned into a quest for a mysterious hardware/software problem after the same errors were produced by running cheese and xawtv.

Apparently it's caused by webcams requesting all the available bandwidth on the USB host controller. With that in mind I decided to run wireshark and capinfos to see just how much bandwidth a single camera used.

4 megabits per second at 320x240
14 megabits per second at 640x480
32 megabits per second at 1280x720

Interesting! That might explain why two cameras at 320x240 work but any higher resolution fails. It's as if my USB controller is only operating at USB 1 speeds, yet lsusb shows both webcams belonging to a device which supposedly supports 480 megabits per second.

One solution proposed forcing the webcams to calculate their bandwidth usage instead of requesting their maximum by running the following commands:

sudo rmmod uvcvideo
sudo modprobe uvcvideo quirks=128

Unfortunately that made no difference, so I decided to try another solution. A post on StackOverflow suggested telling my webcams to use a lower FPS or compressed video format like MJPEG, but after running v4lctl list it doesn't appear either of my webcams support changing their video mode.

And that's where I'm stuck. Why would two webcams operating well below the maximum speed of USB 2 would produce this error?

ps: It's not a disk space issue, df displays no change when the webcams are started.

pps: If it makes a difference, here's the output of lsusb

share|improve this question
up vote 11 down vote accepted

Ding ding! Managed to figure this one out with some help from the nice people in #v4l on freenode.

Long story short: v4l2-ctl is the best tool for debugging USB camera issues. Read all the available commands and the man page, it'll be fun I promise. Using v4l2-ctl I discovered one of my cameras did not support any compressed video modes. You can check what modes your cameras support by running the following command:

v4l2-ctl -d /dev/video0 --list-formats

Which should output something like this.

 Index       : 0
 Type        : Video Capture
 Pixel Format: 'MJPG' (compressed)
 Name        : MJPEG

 Index       : 1
 Type        : Video Capture
 Pixel Format: 'YUYV'
 Name        : YUV 4:2:2 (YUYV)

If the only pixel format returned is "YUYV", "IUYV", "I420", or "GBRG" you'll only be able to run one camera per USB controller* since those formats are uncompressed. Using multiple webcams which support MJPEG or some other form of compression will work fine.

If you use OpenCV like me, don't worry if the default pixel format isn't compressed as it appears OpenCV defaults to using compression anyway.

*Unless you're happy with 320x240 resolution or lower.

share|improve this answer
Hi, if possible, can you tell me how I should set the pixel format of 2 cameras so that I can capture both at 640x480? I am using OpenCV and currently experiencing the same situation like you have where both cameras will only work at 320x240 or lower – lexma Dec 4 '12 at 21:30
Aha! v4l2-ctl is indeed an excellent tool for debugging. Found out a lot about my camera, and was able to fix the issue. Anyways, I was able to fix it by forcing my camera's resolution to 320x240 and using YUYV as the camera output mode. guvcview also helped a lot. – Sheharyar Mar 22 '14 at 20:48
When using resolutions of 320x240 or lower, I get mixed results. I bought 4 cheap USB webcams, all of the same make/model. When trying to run 2 at 160x120, some of them would work fine together and some gave the memory error. I see no rhyme or reason to it. Granted, these webcams cost $3/each, so I guess I got what I paid for. – Cerin Apr 17 '15 at 13:54

I looked at the uvcvideo driver and the quirks=128 module parameter is ignored if the stream is mjpeg compressed.

My webcams of choice have been the Logitech C500 and the Logitech C270, and I found that the image produced by the C500 at 1280x1024 is 100kbytes and the image produced by the C270 at 1280x960 is 200kbytes.

If I run the C270 at 10fps then the bitrate required is 10x200000x8 = 16Mbit/s. In Ubuntu 14.04 the uvcdriver module always allocates 196Mbits/s regardless of the frame rate. For the C500 it is a little better behaved, but is still a bandwidth hog.

I have modified the uvcvideo driver so that I can provide a "compression" factor to the driver through the V4L2 interface. It is a "little hacky" in that I used the priv attribute in the struct v4l2_pix_format to specify the value. In the driver it calculates the size of the uncompressed image and then divides by the compression factor to work out what USB bandwidth to use.

By default I use a compression factor of 10 which allows a large margin for if the camera encounters a particularly hard image to compress. The C270 running at 1280x960 and 10fps now uses 41Mbit/s and I can easily run 4 cameras on one bus.

If anyone is interested in this feature then I will attempt to get the uvcvideo maintainers to consider the "compression" factor concept.

share|improve this answer

The answer is to use the uvcvideo modifications written by SwDevRefugee, and described above. He and I have worked together to get the mod'ed code compiled for OpenWrt, with success. The version I am running it on is OpenWRT DESIGNATED DRIVER (Bleeding Edge, r48130), on a tplink wdr3600 router:

RESULT: I can have 3*c270 (logitech) running simulataneously at 1280x960 and 15fps in MJPG format, through a usb 2.0 hub. I do not have a fourth c270 to hook up, sorry.

I can also have 2*c270 and 1*GEMBIRD 640*480*15fps with YUV format, but adding a 2nd GEMBIRD leads to the dreaded "Unable to start capture: No space left on device" (space==bandwidth here, as you know well:)). Note that GEMBIRD (1908:2311) == .

CPU usage with 3*c270 is fairly reasonable on a wdr3600:

Mem: 50600K used, 75444K free, 320K shrd, 3436K buff, 8800K cached

CPU:  16% usr  27% sys   0% nic  45% idle   0% io   0% irq  10% sirq

Load average: 1.20 0.85 0.44 4/60 2546


 2240  1679 root     S    15348  12%  17% mjpg_streamer --input --

 2505  1679 root     S    15368  12%  11% mjpg_streamer --input --

 2239  1679 root     S    15532  12%  11% mjpg_streamer --input --

If the community gives some reputation and support, I think SwDevRefugee is willing to get the code into uvc-linux.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.