Some usbcam heresy - the criticism is wanted

[xyz]

These are my personal observations and conclusions (and possibly mistakes). Any criticism is welcome.

It seems like everybody serious is only using IP cameras with ZM. USB webcams are used mostly for testing or under some other hidden limitations (e.g. all USB cameras are UVC only or, of a certain model only).

Using multiple different USB cameras (moreover, mixed with the capture cards) reveal some serious limitations of USB subsystem. To overcome these issues, the installation must be rather cleanly planned and administered.


1. The computer should have plenty of USB cards/ports.
A NEC chipset based USB card seems to be able
to serve 2 UVC cameras 640x480 and one UVC
camera 352x288. One VIA chipset card seems to
serve one 640x480 cam or two 352x288 cams only.
(anbody knows how to exclude audio bandwith?)

2. Mixing USB card vendors (e.g. NEC and VIA) could cause
configuration problems later.

3. Seems like the gspca module is not yet mature enough
to serve more than 1 camera. The issue could
be related to the fact that brightness/contrast
controls are not working for particular cameras
or creating overload on an USB bus.

4. Be clean while defining Zonemaster monitors. Better
erase all defined monitors and then start from
scratch. If not - the previous values for
brightness/control settings start messing up.
The dark side is that ZM monitor could only be
removed together with all related events.
There is a need for "restore defaults" option.

5. The boot order: Zoneminder requires you maintain the
exact order of "/dev/video*" devices. Pityfully,
there exist no clean tools to specify the
loading order of USB cameras. It's much easier to
determine the actual loading order afterwards
(/var/log/messages, /proc/bus/pci/input).
Make cold boot tests to ensure that order will
remain the same at each boot.

To be more precise, there are three depending and interconnected layers:

I The lower one forms itself via kernel modules and results in /dev/video* devices.
II The middle layer assumes at least mjpg_streamer scripts be launched with proper arguments. The more heterogeneous are the video sources, the more complex will be this step.
III The upper layer is the ZM monitor definition layer which prescribes which video devices should be addressed directly and which are accessed via mjpg_streamer.

The complexity of relationship between these
3 layers is essential and it will actually
preclude the automatic launch of ZM via rc.d scripts.

To give one example only, launching mjpg_streamer
in YUV (not MJPG) mode for a wrong /dev/video*
device which has Logitech E3500 camera connected,
means that the camera will be limited to 176x144 size
until the next plug-in. Then, the plug-out with
the followed plug-in means that the starting
order of cameras (and corresponding /dev/video*
devices) will be different. This way, the restart of
the ZM server machine is needed to correct the
situation.

6. What is wrong with USB cameras? Kernel is considering
USB devices like very important ones (HID, etc)
and will try to load these first. However, for
a Zoneminder server, video capture cards (Bt8x8)
are firmly bolted into the computer case while USB
cameras are plugged in/out more frequently.
Thus, such modules booting order - USB cameras first,
video capture card later, is faulty for the
ZM purpose.

Actually there are two ways - blacklisting the
models and then loading them manually, or,
experimenting with the natural booting order
and trying not to change it later.

7. Init sequence. S20/K20 is a very strange choice for an
rc.d script (should be S20/S80 within Debian paradigm).
The situation is even more complex because other S20
scripts are running in parallel, causing processor
load and possibly interfering the loading order of
the modules. In my case, probing scsi boot disk
halves the uvcvideo recognition process.

8. The predictability of the loading sequence needs improving.
As an example, mjpg_streamer is to be launched only
after /dev/video* device has been formed and the
permissions verified on it, and not directly after
modprobing.

There are two possible ways - using return codes
or delays. There exist no delay feature while
automagically loading modules (we would like to
use "sleep 3" like in scripts). It is not much easier
to interface to automatical modprobes to get the
success codes from there...

This way, the loading model of USB modules is very
complex and dependant from side issues.



Having spent several days with the issue, I have to conclude
that there are two possible scenarious:

A) using modules blacklisting together with manual init
and not using the ehci_hcd module (the reason is
in how this module work with /proc). this way is
more suitable for uvcvideo/gspca mixed environment,
CIF capture size and Full (12M) speed USB.

B) carefully preparing the loading order of cameras. This
will need a lot of testing. More suitable with
ehci_hcd driver and for capture sizes like VGA or up
(480M, High Speed).

[xyz]

I am still very disappointed with the USB subsystem.

I tested and tested and tested and reached some stable booting order for USB cameras. Now, a month later, I had a random crashdown (probably due to electricity or new year eve load).

And after the restart - the booting order of USB cameras is not the same again. Cold boot, restart, nothing helps. I had to tune the sequence again because two cameras of the same type were swapped. It is an impression like the booting order is the function of motherboard temperature or the clock seconds

Honestly saying, the booting order of two capture cards was also swapped. Probably some timing was different during the aftercrash reboot. However, during next boots the order of capture cards changed back to normal, thus only USB subsystem remains problematic.

(I have 6 /dev/video* devices running. 2 TV cards and 4 UVC cameras. Motherboard is from a very stable Intel rack server)

[bokusouchi]

There is a clean solution :

the solution i use is having udev create some symlinks for all my video
devices :

here are my video devices :

Code: Select all

[root@venus software]# uvcdynctrl -l
Listing available devices:
  video5   SN9C1xx PC Camera
  video4   USB camera
  video3   USB camera
  video2   Terratec Cinergy HT PCI
  video1   UVC Camera (046d:0994)
  video0   BT848 video (MIRO PCTV

[root@venus software]# lsusb
Bus 005 Device 007: ID 0409:005a NEC Corp. 
Bus 005 Device 004: ID 046d:0994 Logitech, Inc. 
Bus 005 Device 001: ID 1d6b:0002  
Bus 003 Device 002: ID 0c45:602c Microdia Clas Ohlson TWC-30XOP WebCam
Bus 003 Device 001: ID 1d6b:0001  
Bus 004 Device 002: ID 0c45:6005 Microdia Sweex Mini WebCam
Bus 004 Device 001: ID 1d6b:0001  
Bus 001 Device 004: ID 04d9:1203 Holtek Semiconductor, Inc. 
Bus 001 Device 005: ID 0c45:6005 Microdia Sweex Mini WebCam
Bus 001 Device 001: ID 1d6b:0001  
Bus 002 Device 001: ID 1d6b:0001  

[root@venus rules.d]# more /etc/udev/rules.d/10-local.rules
SUBSYSTEM=="video4linux", DRIVERS=="uvcvideo" , SYMLINK+="quickcam_sphere"
SUBSYSTEM=="video4linux", DRIVERS=="bttv" , SYMLINK+="bttv"
SUBSYSTEM=="video4linux", DRIVERS=="saa7134" , SYMLINK+="terratec"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="602c" ,ATTRS{busnum}=="1" , SYMLINK+="sonix_cam_1"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="602c" ,ATTRS{busnum}=="2" , SYMLINK+="sonix_cam_2"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="602c" ,ATTRS{busnum}=="3" , SYMLINK+="sonix_cam_3"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="602c" ,ATTRS{busnum}=="4" , SYMLINK+="sonix_cam_4"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="602c" ,ATTRS{busnum}=="5" , SYMLINK+="sonix_cam_5"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="6005" ,ATTRS{busnum}=="1" , SYMLINK+="Ohlson_cam_1"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="6005" ,ATTRS{busnum}=="2" , SYMLINK+="Ohlson_cam_2"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="6005" ,ATTRS{busnum}=="3" , SYMLINK+="Ohlson_cam_3"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="6005" ,ATTRS{busnum}=="4" , SYMLINK+="Ohlson_cam_4"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="0c45" ATTRS{idProduct}=="6005" ,ATTRS{busnum}=="5" , SYMLINK+="Ohlson_cam_5"

[root@venus rules.d]# ls /dev/*cam*
/dev/Ohlson_cam_1@  /dev/Ohlson_cam_4@  /dev/quickcam_sphere@  /dev/sonix_cam_3@
[root@venus rules.d]# ls /dev/*spher*
/dev/quickcam_sphere@
[root@venus rules.d]# ls /dev/*btt*
/dev/bttv@
[root@venus rules.d]# ls /dev/*tera*
ls: /dev/*tera*: No such file or directory
[root@venus rules.d]# ls /dev/*terra*
/dev/terratec@

basically ,with this udev conf , one gets a different symlink depending on the camera model and the usb port , then one uses those symlink in creating monitors in ZM .
that is all there is to it , the symlinks get created dynamically at boot
and during plug/unplug events ..
This way the same device plugged at the same port gets always the same name (symlink) no matter the order it was plugged in .

have a look at the udev documentation .

nice is'nt it ?