Difficulties streaming multiple webcams on BBB


Hi all,

Has anybody successfully gotten two webcams streaming simultaneously through mjpg_streamer on the BBB?

I have a small USB hub and am trying to simultaneously stream two Genius F100’s (standard OpenROV webcam), and while my webcams properly enumerate & stream independently, I cannot stream two simultaneously. I’ve even tried bumping down resolution and framerate to a dismal 320x240 & 3 fps on each.

My first instance fires off nicely with:

mjpg_streamer -i "/usr/local/lib/input_uvc.so -d /dev/video0 -r 320x240 -f 3 " -o "/usr/local/lib/output_http.so -p 8090" &

but the second (/dev/video1 and port 8091) fails:

(omitting stderr junk above here)
 o: www-folder-path...: disabled
 o: HTTP TCP port.....: 8090
 o: username:password.: disabled
 o: commands..........: enabled
Unable to start capture: No space left on device
 i: Error grabbing frames

This problem isn’t new, and some seem to attribute it to lack of USB bandwidth:
[1] http://superuser.com/questions/431759/using-multiple-usb-webcams-in-linux
[2] https://forum.openwrt.org/viewtopic.php?id=40389
(and more if you google “multiple mjpg_stream”…)

The kicker however, is that others seem to be able to achieve multiple camera streams without problems:
[3] http://www.pragti.ch/kippycam/2013/01/02/Mjpg-streamer-multiple/
[4] http://www.friendlyarm.net/forum/topic/953#4753

I tried without success specifying the second stream as YUV (as stated in [4]), but it makes no difference.

I’ve also tried two different USB hubs (one powered, one non-powered).

At this point I’m considering looking into gstreamer to broadcast the second stream (which assumes the problem is rooted in mjpg_streamer - an untested assumption).

Does anybody else have experience/thoughts in this realm?

Programming two camera

I believe that this is a problem with the v4l2 driver (I think) for the Beaglebone Black itself, so I don’t think you’re going to find an easy fix by switching to a different streaming program. Basically, the camera device ends up requesting and claiming all of the USB phy’s bandwidth and so nothing else can use the line. I think we figured out a fix for this at some point in the past, where we rebuilt the driver with some modifications, but that seems to be lost knowledge now. There is a hardware and software hack that you can do to turn the BBB’s USB OTG into a second dedicated USB Host, but I hesitate to even post the details because it is tricky, can destroy laptops if you forget not to plug it in via USB, and is all around just a terrible idea (though it works).


Thanks for the input Charles. Sounds like you’re spot on, as some in the OpenWRT community have modified the uvc driver to so a single stream doesn’t request all the bandwidth. I’ll see if I can poke around in the uvc driver and see where @SwDevRefuge talks about limiting bandwidth in his/her post.

I agree I’d rather not go into re-purposing the OTG. (Potentially) hacking a native linux video driver is enough of distraction/mission creep as is.

I’ll follow up should I arrive at any meaningful solution.


This is a repo from a while back where I patched the driver to limit requested camera bandwidth:


Super, thanks Brian.


I’m very interested in how did you manage to edit the quirk relative to the camera bandwidth limit.
I would like to know if you attempted to use it in a ubuntu-based distro, because I would like to implement this patch on my ZoneMinder setup (I’m using 720p jpg/mjpg compressed cameras) but as far as I can see on github seems it was just available for pupil_uvc_cam.
Mind to share some other infos?