Motion - Aviosys
You are here: Foswiki>Motion Web>Aviosys (04 Oct 2009, JuanJosePablos)Edit Attach

Aviosys IP9100A 4-port video capture unit (Ethernet)

The only 4 port "net camera" I am aware of, but beware it does not give high fps. It is however quite cheap. There is an alternative unit, IP9100B which is the same electronics but with BNC connectors in a metal box.

The hardware is very limited and samples the frame slowly. Changing inputs is not fast.

Furthermore Motion's Round Robin does not support this unit for 2 reasons:

(i) currently the Motion netcam code does not support Round Robin - how many netcams have two or more lenses? (ii) the channel changing is done on the IP9100A by sending an URL and waiting for a status bit in another URL to change, which basically Motion does not support without extra coding.

So for use under Motion you can use 1 channel of the 4, which I have done for many months:

  • JPEG: netcam_url (substitute 0 for 1/2/3 for other channels)
  • MJPEG: netcam_url (only 1 channel supported in this mode)
In the web page interface of the IP9100A, you use what they call 'Fixed' mode with one of the 4 channels enabled. Sadly the multipart jpeg (not motion jpeg as commonly thought) doesn't support more than 1 image stream multiplexed into one. (Thinking about it, this is something that is never seen, so not surprising....)

The image size is configurable from 176x144 up to 704x576 (which I use). Most netcams do not have this resolution apart from recent megapixel ones (very expensive). Coupled with a good CCTV camera, you can obtain excellent quality images, and use outdoor cameras etc (outdoor netcams, also very expensive). The frame sampling rate is not fast, due to the slow hardware. I used 2fps in Motion with no problems.

Latest News:

There is a solution now for multi-channel access to the IP9100A thanks to a miracle worker called Yoics.

They have released an enhanced firmware which must be flashed into the IP9100A, this sets up 4 jpeg files accessible via the network interface, which represent the 4 input channels to the unit. They are constantly refreshed from the input channels.

JPEG access:
  • netcam_url
  • netcam_url
  • ...etc.... up to yoics3.jpg
No MJPEG access is possible to more than 1 channel for the reasons mentioned above.

You need to enable all channels that you want to use, in the web page interface to the unit. Otherwise the usr/yoics..jpg files are not updated.

Again, the update rate of the channels is slow, but 2 channels enabled seems to run at about 2fps (by eye). I think as more channels are enabled, the refresh rate per channel drops, as the sampling effort is spread out. 4 channels might give 1 fps on each channel. Of course this is update rate, you can pull off images faster than this I believe.

I have used this successfully for 2 channels and motion detection works fine. I have a limited CPU power Motion server (it is slow and cannot hit the unit at more than 2fps) so I do suffer from slow sample rate on the 2 IP9100A channels. Other people are using higher sample rates using faster PC hardware (see Yoics support forums for details).

I have spoken to Yoics about increasing speed, and it seems the way to go is to use HTTP Keep-Alive connections from Motion to the video unit. This avoids the overhead of setting up & tearing down a TCP connection for every JPEG image. Motion currently uses 'close' connections. Changing this would help Motion in general by reducing CPU utilisation on all systems (if the netcam used supports HTTP Keep-Alive, I would expect most do). It would also help me, with my limited server hardware, get 2fps on 2 or more channels on this device.

I have added a Motion feature request for HTTP Keep-Alive connections to netcams, and finished a patch. The topic is FeatureRequest2007x01x22x231542 . I still need to prove that it provides a performance advantage.

--Main.SimonW - 22 Jan 2007
Topic revision: r1 - 04 Oct 2009, JuanJosePablos
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.