VMS Camera Setup Guide

This guide, with a series of video screencasts, teaches integrators and users 10 key elements that need to be set up for optimal VMS deployment.

Here is an overview of the 10:

• Camera recording settings: fundamental ones include recording type, resolution, quality/compression, and frame rate.
• VMS/Cameras settings conflict: Some camera configurations are set by the VMS, others are taken from the camera. This varies across VMS / camera combinations and should be carefully checked.
• Camera Defaults: VMSes vary in what camera settings they default to such as whether to record automatically or what resolution to start.
• Compression Scales: It can be hard to match the compression level on a camera to a VMS, which may impact quality and bandwidth consumption. Knowing how these are mapped is critical.
• Multistreaming setup: Oftentimes users want to configure secondary streams to reduce storage or to improve remote viewing experience. Multistreaming can help with that.
• Server Side Motion Detection: many, but not all VMSes offer server side motion detection instead of camera side motion detection; choosing either one involves tradeoffs.
• Camera Grouping: creating camera grouping whether logical or alphabetical could increase efficiency and usability.
• Camera Batch Configuration:making a single modification and applying it to multiple cameras at once can provide consistency and save time- it is usually available in higher end VMSes though.
  
• Time Synchronization: determining when and how to sync times between the VMS and cameras can affect the evidentiary result.
• Motion Boosting: In the event of a motion VMSes can boost either the resolution or FPS of a given camera for higher quality recording.

Camera Record Setting

Admins need to determine the appropriate fundamental camera settings on VMS. This video overview them:

Here are details on each setting:

• Recording Types

Motion only: The most commonly used one is Motion Only and is usually set by most VMSes automatically. Motion only recording can save on storage and bandwidth usage by recording events only. Motion Only recording needs to be configured properly via zones, privacy masks, sensitivity, and object size to ensure the desired motion events are detected.

Record Always: This type requires lots of storage and bandwidth and is usually used when motion detection has failed by either recording many false positives (e.g. foliage movement) or not capturing events at all (motion triggers not sensitive enough). It is recommended to combine this recording type with Motion Boosting to record lower FPS and quality always, and when motion is detected record at higher FPS and quality for the event duration- saving bandwidth and storage.

Record Off: This option is sometimes a VMS default and is used for live monitoring only and requires no storage. For critical cameras it is important to change this setting to one of the previous two mentioned.

• Resolution: Using a camera's highest resolution involves bandwidth and storage tradeoffs. Users may decide to implement Multistreaming, discussed later.
• Quality/Compression: Quality and compression settings affect the image quality, storage and bandwidth. In addition, it is important to understand the compression scales covered later in this article.
• Frame rate: While most cameras support a maximum FPS of 30 (and some even higher), most deployments choose lower frame rates (see our survey results). It is important to appropriately set the desired frame rate in the VMS or else significant storage will be wasted.

Camera/VMS Conflicts

Cameras have dozens of settings that can be configured from their own client interface (typically via web browser) as well as via the VMS. In the latter approach, the VMS sends configuration changes to the camera. For some settings, the VMS simply reads / uses what has been set on the camera side. For others, the VMS will set and change the camera's feed.

This can create confusion if the settings are set in the camera, but are displayed differently in the VMS due to its own defaults. For example, a camera setting may be set to 30 FPS, but the VMS setting is 10 FPS only- this will result in maxed received FPS of 10 since that is all the VMS is requesting.

This video shows the type of problem that can occur:

Camera Settings Not Configurable Via VMS

Many camera settings can not be configured from the VMS interface as the VMS has not implemented controls for them. Typically, this happens with more advanced camera configuration. While almost all VMSes allow changing resolution, frame rate, quality/compression, most VMSes do not enable changing the shutter speed, gain control settings, or other less commonly used features resulting in unexpected video or image quality. An example of this advanced unimplemented field is when a camera includes an option for VBR or CBR. The camera quality or storage usage will differ depending on that field setting alone which may not be configurable from the VMS.

Camera Defaults

Each VMS has a built in set of defaults that apply to all cameras, and other VMSes simply pull in whatever the camera has and populate the VMS's UI leaving a few fundamental configurations such as Recording Type for the user to configure.

Some camera's FPS range from 1-60, and others are maxed at 30. However, the VMS may default to between 10-15 FPS unless it is changed by the user configuring the VMS. The same can be seen when looking at the camera's resolution- some VMSes will use the camera's setting while others are configured to use the mid resolution of the camera.

Compression Scale Differences

The VMS and Camera UI will most likely differ in both design and scaling of the compression scale. Here's what this looks like:

For example, a Compression field's values in the camera may be scaled from 1-100; 1 being lowest quality and compression. While the VMS's UI Compression may be labeled 'Quality' and range from 'Lowest- Highest' without an accessible mapping of the correlation between the two. It is important to check with the VMS manufacturer to ask for that mapping since the values may differ; there may be some difficulty in finding this information since it is usually not documented.

Server Side Motion Detection

Many, but not all VMSes, support detecting motion on incoming video feeds, enabling reduced storage by only recording motion as well as easier retrieval of specific events. This is an alternative to camera side motion detection. There are Pros and Cons to using each of the motion detection methods:

• Server Side Motion Detection: Allows for consistent management within the VMS itself rather than each individual camera where each camera's motion sensitivity may differ. One main con is the server's high CPU usage since motion detection for a large number of cameras can drain resources.
• Camera Side Motion Detection: This approach relieves the VMS server of added CPU usage where it can be used to manage recordings, clients and other VMS specific tasks. However, it relies on the camera's ability to detect motion accurately where a server sensitivity settings may be more sensitive or offer a different more consistent scaling than each individual camera.
• Some VMSes also allow the Camera side motion detection zones to be configured from the VMS itself and once saved are written to the camera. It is important to ensure the VMS only allows the max number of zones for each camera type and no more as that could cause conflicts as well.

This video shows motion detection options in action:

Multistreaming

Many VMSes support multiple streams per camera, typically to enable recording at different qualities than viewing or for remote low bandwidth clients. Some VMSes will do this automatically, without any configuration. However, many will require the admin to explicitly set this up when adding the camera, by selecting the proper compression, resolution, quality and when the lower stream should be used (e.g. remote users). When configuring multistreaming, keep in mind that:

• The camera must support multistreaming. While most do now, the VMS must support multistreaming of each particular camera, which can still be a problem. Make sure to verify before deploying if implementing.
• Multiple streams add load both to cameras and servers. Make sure the camera can handle this without reducing quality and that the server has enough capacity to handle the additional streams.

Camera Grouping

Using layouts or logical groupings allows security personnel to quickly access a given wing of a building or all cameras with a specific criteria logically grouped together for quicker access. In addition, maps can be used to group cameras by floor of a building.

Camera Batch Configuration

Enterprise level VMSes allow for use of templates; template availability varies between VMSes and functionality.

This video shows common options:

Templates can be used to apply:

Camera configuration

For large systems, often similar settings are applied to large numbers of cameras (e.g., all outdoor cameras are set to 10fps or to continuous recording). Instead of manually doing this for each camera, some VMSes offer batch configuration where a single modification can apply a common setting to every camera in a group. However, any VMSes limit such batches to cameras from the same manufacturer or same model, so be sure to check on what constraints exist.

Recording schedules

Creating a recording schedule is tedious and time consuming, especially when it has to be done for many cameras. Recording schedule templates allow the admin to configure a day, including specific hours or times for one camera and then apply it to multiple weekdays/weekends and many cameras at once thus saving time and avoiding inconsistencies.

Consistent Camera Naming Conventions

As batch configuration can be used to configure or modify existing cameras, it can also be used to add and name many cameras at once. It is possible to apply a set of concatenated variables and customized text to a list of newly found cameras (e.g. IP+Make+Model will result in 10.0.0.11344Axis). The admin can create a consistent naming convention for easier discovery and use of the cameras later thus reducing name duplication and inaccuracies.

Time Synchronization

Time stamp of recordings can be managed by either individual cameras or the VMS itself. This video overviews the options and placement of settings:

However, configuring and maintaining hundreds of cameras' times as well as a VMS can result in time inconsistencies and deem the video inadmissible in court. There are 3 different approaches to solving this issue:

• Turn Camera time off and use VMS to stamp video: VMS server time should be managed and configured via Windows to account for DST.
• Turn VMS Timestamp off and use cameras' time: This is the most inefficient way. It requires configuring each and every camera (even to point it to an NTP server) and requires zealous to ensure with each reboot, power outage, firmware upgrade, and networking issues someone reconfigures each camera accurately all while video is stamped with an incorrect time.
  
• Point all cameras and VMS servers to NTP server: Still requires a magnitude of cameras and VMS servers to be configured at least once and again- relies on a collection of NTP servers that use other (public) servers to set time and in some cases may result in a fee.

For more, see our Time Synchronization tutorial.

Motion Boosting

Motion Boosting, also known as Motion ramp up/speed up can be used, quite effectively, in reducing the FPS (and the added bandwidth and storage) when there isn't much motion. In most VMS the user can set the recording to capture 1 FPS and in cases of motion 'ramp up/boost' to 10-15 FPS to capture more detail in an event. However, this method does have a few cons: It can result in the Benny Hill affect or choppy video resulting in video where objects appear out of nowhere or seem like there are sped up. Moreover, it heavily relies on the motion detection accuracy of the camera itself or the server and which sensitivity was used to trigger motion in the first place.