Testing IP cameras, part 2

D-Link 3220gNow we’ve seen that the nice and simple DCS-900 is pretty handy when controlled from Linux with no ActiveX. Time to examine the much more complex DCS-3220g, which should give us MPEG-4 encoded video. It’s another rebadged Vivotek as far as we can tell.  This camera has a built-in WiFi radio as well as wired ethernet, has an interchangeable lens and should support a 2-way audio link. It comes with a Windows software package for managing multiple cameras.

The 3220g  defaults to getting it’s IP address from DHCP, so if you plug it into a DHCP enabled router you should be able to find it’s address by either looking through the router’s DHCP leases or by scanning the local network with (for e.g.) Angry IP scanner or nmap. Point your browser to the IP address of the camera, and you should get the main page on the camera’s web-server, but in your Linux browser you won’t be able to see the view through the camera’s lens – you need ActiveX for that. You will however be adjust the network settings of the camera, and set some of it’s video output properties from buttons on the right side of the page.DCS-3220g Video page You can also use your admin password (default is username = admin with a blank password) to access the camera’s file system via either telnet or ftp. Once you’ve set your video settings, you can go a look at a still picture from your camera by pointing your browser to the IP address of the camera with /cgi-bin/video.jpg … so if your camera’s IP address was 192.168.1.3, then you’d type http://192.168.1.3/cgi-bin/video.jpg  to see the picture. Here are some of the stills from the camera at full 704×576 resolution – an outdoor scene with trees, and an indoor close-up of a DVD case. These are slightly disappointing given the specification and cost of the camera, and despite much tinkering I couldn’t get a video stream out of the thing, not M-JPEG or MPEG-4, not with VLC or mplayer, not using RTSP or HTTP. Google didn’t throw up any lifelines and the reference guide to URL commands (warning: 290KB PDF) just underlined the futility of the exercise. Of course, knowing that this camera runs an embedded linux, and that there is no rational reason that I can’t get a stream from this camera leaves a sour taste. All I can think of is the Lazy Programmers haiku and endevour to  look into open-source camera technology.

2 thoughts on “Testing IP cameras, part 2

  1. Pingback: Portable VoWLAN: A portable voice over wireless local area network for mobile learning « VoWLAN

Comments are closed.