Genetec Criticizes Milestone

Genetec and Milestone are fierce rivals in the VMS market, continuously competing for similar large scale surveillance projects. In that space, advanced technical features are key differentiators. To this end, Genetec recently published a list of functionalities that it believes VMS systems should have [link no longer available]. Interestingly, quite a number of these are obvious criticisms of Milestone specific implementation issues.

In this note, we review the 5 main points, providing an assessment of how significant each one is for practical use.

Here are the 5 core criticisms Genetec implicitly makes of Milestone's VMS:

• Must license by MAC address of camera/encoder
• Requires restarting server services to make configuration changes
• No ability to upgrade camera firmware from VMS client
• No ability to configure the key frame rate of each camera
• No support for multicasting from camera

Licensing Differences

Claim 1: Video Management Software(VMS) must be licensable per total number of camera connections, not by MAC

Milestone requires users to submit MAC addresses for each camera to be licensed on a system, activating the licenses only for these MAC addresses. Comparatively, Genetec licenses Omnicast and Security Center by total number of camera connections, regardless of MAC address. Cameras may be removed and replaced without any change in licensing. 

When a camera goes down and must be replaced, the Milestone method of licensing will slow service. The technician must remove the old camera, install a new on in its place, and then wait to receive an updated license before it can be activated. If the replacement camera is a "loaner" unit, this must be done twice. Genetec users do not have this issue.

Counterpoint: Unless the installation has a large number of cameras, the time penalty for licensing by MAC address is not significantly more than licensing by connection. While connection licensing may simplify maintenance for larger deployments, this will not be a major factor for most surveillance systems.

Configuration Changes without Services Restart

Claim 2: Any configuration changes do not require the server services to be restarted

Milestone requires that services be restarted after making configuration changes, while Genetec does not. This means that after many settings are altered, recording will stop momentarily, while the services restart. For some users, especially in critical infrastructure and municipal markets, this interruption will simply be unacceptable. For other customers, it may not be as serious. However, restarting services introduces the possibility that one or more may not properly restart, which may lead to increased troubleshooting.

Counterpoint: Previous Milestone versions required an admin to remember to restart services which was a problem. However, now, when exiting the management application, all Milestone versions explicitly prompt admins to restart any time configuration changes have been made. This makes it unlikely that an admin will forget or make an error. For most users, a brief restart is not a practical problem.

Ability to update firmware of IP camera or encoder

Genetec Omnicast and Security Center offer the capability to update a unit's firmware directly from their config tools, while Milestone users must go directly to the camera's web interface or use manufacturer-specific configuration tools. While this is not necessarily a large timesink, it simplifies firmware updates, since users only need to work in the Genetec interface, instead of looking up and entering each camera's address. For users with multiple camera manufacturers, this may have more impact, as it eliminates the need to learn multiple manufacturer's web interfaces.

Counterpoint: Mass firmware updates can often be accomplished by using camera manufacturer's free management applications (e.g., Axis Camera Management).

To minimise network traffic, the VMS must have ability to configure the key frame interval (I-frame) per second

Milestone does not allow users to adjust key frame interval, while Genetec does. This was discussed in an earlier Genetec Blog entry [link no longer available], also ostensibly a knock against Milestone. In this article, they claim that Omnicast and Security Center's ability to configure I-frames reduces bandwidth and storage needs 2-3x versus "Product X", which uses a set key frame interval of one second.

Counterpoint: Our testing shows changing I-frame rates may not really save much storage. For instance, longer I-frame intervals are often offset in an increased P-Frames size. Specifying longer I-frame intervals may negatively impact video quality and increase indexing (search/retrieving) difficulties. The I-frame interval is best left at defaults unless the user has tested and validated the use of specific I frame internals with the selected camera in the camera's actual location.

Video Management Software(VMS) must have the ability to manage multicast directly from the camera

Lastly, one of Genetec's key marketing claims is their multicast support. Multicast is supported in Omnicast and Security Center directly from the camera, or from the server, while Milestone only supports multicast from the server, and only in their XProtect Corporate version. When multicast is supported only from the server, each resolution that must be streamed to clients may increase server load.

In many cases, this is a non-issue, as it is rare that numerous viewers require multiple resolutions. However, in some large applications, this may be a key feature. For example, in a municipal setting, multiple resolutions and framerates are desirable, such as one stream for clients in the operations center, one for clients elsewhere on the network, one for recording, and one for remote clients on mobile devices or in-car mobile data terminals. Creating all these stream types on the VMS server will most likely increase load, so it is therefore preferable to configure these distinct streams on the camera, to avoid this reduction in performance.

Counterpoint: As stated above, the ability to multicast directly from cameras, rather than servers, offers little to no benefit for the vast majority of surveillance deployments. Additionally, multicast in general is not applicable as multicasting requires appropriate hardware and network design to accomodate this.