Multiple USB Cams, one per printer

I have three Microsoft USB Cameras. The first one was plugged in, and easily setup on the first printer. I plugged in the second one, but it's not automatically showing up at port 8081. I've rebooted and tried again, but can't get the second camera to show. It does show up as /dev/video1. Do I need to manually go edit a file to get another copy of mjpg_streamer running?

Comments

  • Update: I'm now seeing another copy of mjpeg_streamer start up for the second camera, but I'm not seeing the pictures remotely at port 8081. Nor at 8082 for the third camera.

    I've verified the cameras work with Cheese.

    This is on a Debian box, running a licensed version of 0.90.7.
  • It depends on how you solved the mjpg_streamer integration. Our pi image solution e.g. uses the cam id to assign it to ports. With identical devices the id might be the same. Then you need to change webcam.conf

    # WEBCAM_DIR is used for naming video devices
    # /dev/v4l/by-id/*     Is to use the device names. It is not important where you plug it in
    # /dev/v4l/by-path/*   Is to use th eusb port plugged in to identify webcams. Use this if you have identical names
    WEBCAM_DIR=/dev/v4l/by-id/*

    to use the path insetad. Using /dev/video0 ..2 is not a good idea since the names are given by order of detection so might change after boot.

    I guess somewhere there lies your problem.

    Use
    ps aux | grep mjpg
    to see running instances including ports where they offer the webcam.
  • I'm only seeing one camera enumerated in by-id:

    root@print:~# ll /dev/v4l/by-id
    total 0
    drwxr-xr-x 2 root root 60 Jan  7 21:42 .
    drwxr-xr-x 4 root root 80 Jan  7 21:42 ..
    lrwxrwxrwx 1 root root 12 Jan  7 21:42 usb-Microsoft_Microsoft®_LifeCam_HD-3000-video-index0 -> ../../video2

    root@print:~# ll /dev/v4l/by-path/
    total 0
    drwxr-xr-x 2 root root 100 Jan  7 21:42 .
    drwxr-xr-x 4 root root  80 Jan  7 21:42 ..
    lrwxrwxrwx 1 root root  12 Jan  7 21:42 pci-0000:00:14.0-usb-0:1.2:1.0-video-index0 -> ../../video1
    lrwxrwxrwx 1 root root  12 Jan  7 21:42 pci-0000:00:14.0-usb-0:2.2:1.0-video-index0 -> ../../video0
    lrwxrwxrwx 1 root root  12 Jan  7 21:42 pci-0000:00:14.0-usb-0:2.4:1.0-video-index0 -> ../../video2
    root@print:~#

    root@print:~# ps aux | grep mjpg
    root      1000  0.0  0.0  43124  9920 ?        Sl   Jan07   0:25 /usr/local/bin/mjpg_streamer -i /usr/local/lib/mjpg-streamer/input_uvc.so -d /dev/video0 --fps 15 -q 85 -r 1280x720  -o /usr/local/lib/mjpg-streamer/output_http.so -p 8080 -w /usr/local/share/mjpg-streamer/www -b
    root      1029  0.0  0.0 3119388 10956 ?       Sl   Jan07   0:00 /usr/local/bin/mjpg_streamer -i /usr/local/lib/mjpg-streamer/input_uvc.so -d /dev/video2 --fps 15 -q 85 -r 1280x720  -o /usr/local/lib/mjpg-streamer/output_http.so -p 8082 -w /usr/local/share/mjpg-streamer/www -b
    root      4908  0.0  0.0   4728   892 pts/0    S+   08:43   0:00 grep mjpg

    Two have mgpg_streamer running for them, one does not. I've made no changes to how mjpg_streamer runs yet.


    WEBCAM_DIR is not yet specified in the webcam.conf file. I'll add it, and restart when my prints are done.

    Thank you-
  • I see that there may be issues running multiple USB cameras at high resolution on the same USB bus. All three of mine are on the same bus.

    Can RS use MJPG or only full-bandwidth YUYV capture?

    root@print:~# v4l2-ctl -d /dev/video2 --list-formats
    ioctl: VIDIOC_ENUM_FMT
        Index       : 0
        Type        : Video Capture
        Pixel Format: 'YUYV'
        Name        : YUYV 4:2:2

        Index       : 1
        Type        : Video Capture
        Pixel Format: 'MJPG' (compressed)
        Name        : Motion-JPEG


  • webcam.conf specifies 1024x768 as a factory default, but mgpg_streamer is using 1280x720.

    WEBCAM_WIDTH=1024
    WEBCAM_HEIGHT=768

    /usr/local/lib/mjpg-streamer/input_uvc.so -d /dev/video0 --fps 15 -q 85 -r 1280x720

    Is there another place I need to change the default image size to reduce bandwidth?


  • Server only uses MJPG/JPG but that is not relevant here. mjpg_streamer does convert yuyv to mjpg if the webcam does not support it. Your webcam supports both so mjpg_streamer will use mjpg directly from webcam. That way the usb bus also does not get as much stress.

    You can check /var/log/syslog when you start mjpg streamer on the missing /dev/videox and see why it does not start or directly send
    /usr/local/bin/mjpg_streamer -i "/usr/local/lib/mjpg-streamer/input_uvc.so -d /dev/video1 --fps 15 -q 85 -r 1280x720"  -o "/usr/local/lib/mjpg-streamer/output_http.so -p 8082 -w /usr/local/share/mjpg-streamer/www"
    without -b for background and see messages on screen.

    Looks like your solution uses only the /dev/videox devices.
  • It appears that webcam.conf file is not being used on Debian. Changes made to it have no effect. Is it only used on the PI version?

    /usr/local/Repetier-Setup/bin/mjpgStart determines BEST_WIDTH (etc) and uses that.

    Changing that file to force the parameters does take effect:
    echo "Forcing resolution and framerate:"
    BEST_WIDTH=1024
    BEST_HEIGHT=768
    BEST_FRAMERATE=3
    echo "Best resolution: $BEST_WIDTH x $BEST_HEIGHT at $BEST_FRAMERATE"

    Feature request: Allow the user to specify the width, height and framerate from the GUI, to reduce bandwidth needs.



  • Changing the bandwidth to 320x240 x 1fps got all three cameras working on the same bus. I was able to get two running at 1024x768.  So it is clear that it's a USB bandwidth issue.

    I'll see if I can move them to different buses.
  • I think one solution may be to use USB 3.0 cameras. I have 2.0 cameras on a 3.0 port/hub, but they enumerate as 2.0 and use all available bandwidth on that bus.

    I'm hoping that USB 3.0 cameras would co-exist better, as I only have two 2.0 USB buses on this mini computer (and one 3.0).

    As I add more printers, I'd like to eventually run 4-8 cameras as I'm only running 5% CPU with three printers on a Core i5.
  • webcam.conf is in deed our custom solution to handling webcams on our pi image. There you can also select resolution and framerate in the server gui. This is done through some bash scripts the server detects and uses for interaction making it easier here. 

    In our docs section on the homepage we also use that solution I think.
  • OK- Would be nice to have that on the Debian version, but I can edit the file easily.

    Thanks for the help-
  • I have updated 
    https://www.repetier-server.com/setting-webcam-repetier-server-linux/
    to contain the latest version of your webcam solution for linux.
  • Thank you-
  • Here some info that might help someone- 
    usbtop is a great way to see how much bandwidth is really in use. I can see it go up when the cameras are active, and drop back when they are not.

    # Show usb devices:
    lsusb -t

    # Monitor USB bandwidth:
    sudo apt install git cmake g++ libboost-dev libpcap-dev libboost-thread-dev libboost-system-dev
    git clone https://github.com/aguinet/usbtop.git
    cd usbtop/
    cmake .
    make
    sudo modprobe usbmon
    sudo src/usbtop


    I'd like to see mention in your docs that multiple HD USB cameras may not coexist on a USB 2.0 bus, as they may run out of bandwidth. Some tips from people that have 3+ cameras working on one system would be valuable.

    I'm going to have to purchase some USB 3.0 cameras and see if that solves my issues, as I can't put in a USB card in to this micro PC.

  • What happens if you if you go down to 640x480? If webcam supports mjpg it should be around 25kb/frame. Of course HD with 30 FPS will get a problem.
  • I had to drop to 320x240 to get all three to work. It's not the actual bandwidth in use that is being limited, it's the request from the camera to the firmware. So it may depend greatly on which cameras are being used, as well as the OS. I'm just not finding a way to make Debian attempt to ignore the requested bandwidth number, without having to recompile.

    I'm looking for cheap Ethernet cameras now, and will try that path.

Sign In or Register to comment.