Now Pages
If It's Not Live - Then It's Not NOW!
Sign Up!
Welcome to Now Pages
Saturday, September 23 2017 @ 02:25 AM CDT

IP Camera Control and Setup

Previous: Camera Types - Next: Camera Specifics

All industrial IP cameras require some way of controlling how they work. There are a myriad of different settings, even if the camera itself is not one that pans or zooms.

In addition to just setting them up, those that offer either physical pan/tilt/zoom or electronic PTZ also have to have some method for the operator to aim them. The problem with many is that there is no single standard for the interface. If the actual interface isn't published, then use of the camera outside of it's own unique software environment will be problematic.

If you are lucky, the software needed on your end is only a web browser and any one will do. Most cameras these days will at least allow you to do basic network setup this way but many don’t work well with anything but Microsoft’s Internet Explorer – usually not the latest one unless you run it in “compatibility” mode. Some will require you download a Microsoft Windows-centric setup tool to find and set the initial address of the camera. Many of these programs actually work the same way and can be used for any camera, but some are locked to the range of MAC addresses the camera manufacturer has assigned to it. (The MAC address is unique to any given IP product and ranges of them are assigned by a central authority to manufacturers for their specific use)

The major problem comes when the camera is bundled with control software that is proprietary in nature and locked to some version of your PC operating system, and even locked sometimes to a particular (usually small number) set of licenses for that software. We’ve seen this in the case of MPEG4 decoding for example where only one license is available so once it is installed you can’t install it again.

There is also the case where the control software will only run on some small subset of the available web browsers, typically a version of Microsoft’s IE. We’re particularly allergic to such lock-ins as we tend to run Linux on a lot of our remote and local servers and even when we do run Microsoft’s operating systems we tend to run Firefox or more recently, Google’s Chrome as our browser of choice.
The other lock-in is the use of either a specific (operating system dependent) version of Java for interacting with things like the joystick controls, or use of the again Microsoft-OS dependent Active-X control software.

The good thing is that there are people who have, at least somewhat, reverse engineered the control software for some of the available cameras and brands and there may be help available if you have particular requirements like we sometimes have – where we want people on the other side of the world to run the camera completely remotely.

In this book though, we’ll stick to your use of the software that the camera comes with or works best with because you’re likely to be the one running it locally on your network, or be the only one to remotely log on to the camera for control.

Another area of control software is the monitoring software used to control and archive the video from a number of cameras. This software too can be both a blessing and a problem as it too tends to be written and licensed in such a way as to lock the user into the manufacturer’s product line. We know of one installation where such software is used and, to be sure, does an excellent job of what it was purchased for, that of archiving video when something happens and the system detects motion. The problem is that the video is stored in a proprietary format and the only “export” format available is far less than ideal for getting the best video out of the cameras.
If you are looking for such control software you might take a look at the open source project called Zoneminder

( Its list of supported cameras will also give you a shopping list of the IP cameras that work best at any given time.

Encoder Characteristics

Despite the fact that any given camera says it supports a specific codec (H.264 for example) there are again a myriad of different settings for that codec that can and sometimes do make it incompatible with the goal of getting it distributed on the internet via the current crop of Flash video distributors.

I’ll note here that many of the articles and postings on the net tend to be about how to set up a particular codec for post-process/editing and rendering of video for a given distribution medium. These settings are entirely different from those used at the camera for recording live video – and are especially different for encoding really low bit rates on live wildlife cameras. In most cases we tend toward a bias of detail over frame rate, whereas in post processing the idea is to get the best detail at a fixed frame rate, using things like scheduling key frames at scene changes. Live, long-term video really doesn’t have scene changes, so this is not applicable.


Today’s typical use of FLASH video for distribution pretty much dictates the use of H.264 as the video codec from an IP camera. The most basic compatibility setting, if you have access to it, is selecting the “profile” which should be set to “Baseline version 3.0” unless you know that version 3.1 works for your application/distributor. This setting may be called something else and if all else you may simply have to “flip every switch and test” to find a set of settings that works. Keep notes!

Once you have something working, the major setting is the actual data rate. We currently set this rate to something between 200Kbps and 400Kbps for most applications.

Now you need to make a value judgment based on your critter and its surroundings. If there is likely to be little overall movement (no water in the background or waving leaves for example) then you may be able to set the frame rate as high as 30 fps. Otherwise you may need to go lower, down to as low as 10 fps if necessary to get within the limited bandwidth you have set and still get acceptable detail in the picture. Loss of detail shows up as blocks that are all the same color, larger than the individual pixels (called “pixelation”).

You may be able to set an overall preference for frame rate vs resolution and again you’ll have to try it to see which is best for your application. If you have too much motion you may end up with really slow frame rates (less than 10 fps) that interfere with the live action too much if your setting is to prefer resolution over frame rate.

Key Frame rate or I Frame distance – kind of the inverse of each other. I frames are Key frames. They contain all the information for a specific frame, and other (P and B) frames reference them to build a series of frames between successive I frames in what is called a Group of Pictures (GOP). So I Frame distance is the size of a GOP unit regardless of frame rate. Key Frame rate says how often a Key/I frame is generated compared to the actual frame rate.

The more motion you have in your field of view, the more often Key/I frames should be generated to maintain a level of continuity in the video. A critter sitting relatively motionless on a motionless background might work well with I frame distance of 60 (Key frame every 2 seconds at 30 fps, or Key frame every 6 seconds at 10 fps) and you may be able to get along with even higher distances out to as much as every 120 or 180 frames before the interjection of a Key frame causes an obvious change that brings the series back to true fidelity with the original. I’ve seen some commercial movies on TV where the Key frame rate was as much as once per 15 seconds at 30 fps but sporting events tend to be several times/second.

You likely won’t have any control over use of P and B frames. The technical difference between these is that the P frames only look at past frame information when looking at differences, where the B frames use both past and “future” frames too, which is what causes delay in the encoding process since the system has to wait until these future frames actually exist before they can be used. If your system generates B frames (and most do) then the GOP size will also determine how much “latency” there is in the encoder – the difference between when something happens and when you see it – which could be a second or two or even longer in cases of really low bandwidth compression.

Deblocking filter on/off. This setting can increase apparent resolution in a moving-background picture but at the addition of what can only be described as “block movement” of some of the scene components against the background of others. Again, test this for your specific subject.

Video quality. Some cameras will allow you, as noted above, to select either frame rate or quality as the dominant factor. Others might give you a sliding scale or field to fill with a number from 0 to 100. In the case of one such camera, the higher the number, the better the frames looked but the slower the frame rate, even though it was set to 15 fps. In this case there was also an “auto” setting which kept the frame rate at the set rate until there was a lot of motion, then it dropped the frame rate. The problem was that by that time the image was very low quality. In most cases we like lowered frame rates rather than lowered quality.
Motion JPEG

If you are able to run two streams from your camera, you may want to locally record a higher definition stream as well. Most such cameras we’ve seen will also allow you to stream a Motion-JPEG stream of some sort. In the case of the Axis IP cameras, this is the type of stream that is pulled from the camera for their virtual video driver when used to re-encode the stream for Windows Media (or Flash video)

The settings you use here will typically be determined by what connection you have to the actual camera. If you have a wired connection then you should be able to pull as high resolution as the camera will put out. If you have a wireless connection you may have to experiment to see how high you can go without hurting the low resolution stream you’re sending to the public. See the section on overcoming distances for more information.

In general, Motion JPEG is simply a series of JPEG encoded frames sent one after the other. The underlying encoder typically has only a quality setting, where the higher the number, the higher the quality. Settings over 75 usually mean “loss-less” encoding which means you get exactly what the camera sees.

You may also have the ability to pull full-frame (rather than the smaller frame that you might be sending to the internet) so your image size might be larger than the low-definition stream. As a side note, when we do this we find that most of our TV-resolution cameras require about 6 Terabytes of storage for a typical eagle nest season. Higher if we use loss-less setting and lower if we re-encode this stream’s output files to something like MPEG2 or VOB, which again lose detail a bit, but are more than good enough for what we do with our archives. The new “Hi-res” cameras we’re starting to deploy will require a lot more than this for full-resolution storage. It’s a good thing that hard drives in the 3 Terabyte range are now available.

Tag: h.264 i-frame key frame p-frame b-frame frame rate ptz encoder ip camera

Story Options


Trackback URL for this entry:

No trackback comments for this entry.


Read the Digital Rag

There was a problem reading this feed (see error.log for details).

Auto Translations

  • Arabic
  • Bulgarian
  • Catalan
  • Chinese Simplified
  • Chinese Traditional
  • Croatian
  • Czech
  • Danish
  • Dutch
  • Filipino
  • Finnish
  • French
  • German
  • Greek
  • Hebrew
  • Hindi
  • Indonesian
  • Italian
  • Japanese
  • Korean
  • Latvian
  • Lithuanian
  • Norwegian
  • Polish
  • Portugese
  • Romanian
  • Russian
  • Serbian
  • Slovak
  • Slovenian
  • Spanish
  • Swedish
  • Ukrainian
  • Vietnamese