Cut Milestone Licensing Costs 80% By Using Hikvision and Dahua NVRs (Tested)

By Sean Patton, Published Aug 13, 2018, 01:33pm EDT

Enterprise VMS licensing can be quite expensive, with $200 or more per channel common, meaning a 100 camera system can cost $20,000 in VMS licensing (plus annual support costs). What if you could cut that down to just $2,000 in VMS licensing by using a few thousand dollars worth of NVRs?

In this test, we evaluate the performance and licensing cost tradeoffs of using Dahua and Hikvision NVRs as encoders connected to Milestone XProtect. 

Key ********

*** *** ******** ** noted ****** *** ****:

  • ******** *** **** ** connect **, *********, *** record **** ***** *** Hikvision **** *** *** "ONVIF ********** ****** (*-** channel)" ******.
  • ****** **** ** ******** was ************, ** *** to ****** *** ****** ONVIF ****** **/*** ******** times ****** ** ***** add.
  • ** ********** ******* *** introduced ** **** ***** monitoring **** ********** ******* to ******** *** ** NVR.
  • ***: ******* ***** ** an *** ***** *** NVR ** ***** ** XProtect **** ******* ****** to *** ****** ***** on ********, ********** ** whether *** *** ** deleted / ******* *** re-added ** ********.


*** ***** *** **** to **** ***** ** ********* and *** ******** ******** such ** ******** ********** in ******* ***** *** bug ** ****** *** cameras ** *** ***, and *********** ** ***** point ** ******* ** the ***, **** **** be **********. 

**** **** ** **** your ******* *********** ** NVRs *** ********* ******** before ******* ** ********* this.

Significant ******** ***** *******

*** *** ** **** used ** * ****** between *** ******* *** the ******, ** ** serves ** ***** ********* functions ** *** ********* of *** ******, *** introduces *** *********** ** outlined.

*******, ********** ** *** with ** ******* ** XProtect **** ******** * single ****** ********** ******* and * ***-**** ***, compared ** ** ******** for ** ********** ** cameras, ***** *** **% savings *****. **** ** not **** ****** **** using ***** *** ********* cameras *** ** ****** a *** **** ***** or ********* *** ** an ******** ******, *** can *** *** ***** ONVIF ******* (*******, ****, Hanwha, ***) ******* ********* each ********** ******.

Setup ********

**** ***** ***** *** process *** ****** ********* issue **** ****** ** NVR, *** ******* **** and ******** *****.


Adding **** ** ********

**** *********, ******** *** able ** ****** *** configure ***** **** ******* additional ************* ** *** NVR. ***** *** ***** points ** ** ***** of:

  • ******** *** *******:********* "**** *** ********" will ***** ****** ** the ****** ******* ***** driver ***** ********. *******, users ****** ******** *** the *** *** ****** "ONVIF ********** ****** (*-** Channels)" ** *** ******.
  • ******* **** ** ** connected ****** ****** ** Milestone: **** ********** ** add *** *** ******* any ******* *********, ******** found *** **** *** failed ** *** ** to *** ********* ******
  • ****** ****** ********* ****:***** **** ********** ** add * ********* ***, ONVIF ******* *** ** be ******** *** **-******* for ******** ** ************ enroll *** ***. ********* support *** *** **** to ******** **** *** causing **** *****.

Adding ******* ** *** *** *******

**** ** *** ** added ** * ********* Server, *** ********** ******* that *** ***** ** the *** ** *** show ** ** ********. Deleting *** *** *** re-adding ** *** *** enroll *** *** *******. New ******* ***** **** to ** ***** ****** to ********, ** ** additional *** ***** ** added ** ****** ******** new *******.

**** ** * ***** limitation ****** ****** ******* directly ** ******** *** in ******* ***** ***** deployments (***** ****** *****, gas ********, ***** ****** buildings, ***) **** ***** be **** ** ** issue. *** ***** **** are ******** ** ****** or ****** ***** *********** could **** **** ************.

Limited / ** **** ********* *******

**** ********* ** ********* not ********* ******* ***** on ***** ****, *******,*********'* ********* ****** ***** state** ** ** **** Hikvision ****. ******* *** specified *******, ** **** not ********** ** ******* it ** **** ****** testing.

Latency ******

***** *** ** *********** latency ***** **** ********** a ****** ****** ** XProtect ****** ******* ** NVR. ** **** *****, the ********* **** ***** through *** *** *** displaying ** ****** ***** to *** ******** ********* camera ******. **** ** a ********** ** ****** time **-****** ******* ** the **** ******:

Firmware/Software ********

***** *** *** *** firmware ******** **** ** this ****:

  • ***** ***-*******-***-**** *.***.****.*
  • ********* **-******-**: *.*.** ***** 171204

********* *******:

  • ******** ********* **** ** (12.2a, ****** **** *.**)

Comments (35)

Is this something Milestone is okay with?  Seems a little odd to be featuring an article about how to get around licensing costs.

We spoke to Milestone about the report, and they are completely okay with it. They noted that they believe it is a very small percentage of their systems deployed in this manner, and that within that small percentage, without this license model, they would have little to no presence in the markets where it is used.

I'd guess that if they start seeing a large percentage of their sales shift to this then they'll raise the price. 

Once an NVR is added to a Recording Server, and additional cameras that are added to the NVR do not show up in XProtect. Deleting the NVR and re-adding it did not enroll the new cameras. 

I would wager that Milestone is keeping a reference to the device by MAC address in a database. If you could delete it from the database (I have never tried to poke around at Milestone's databases) you might be able to truly re-enroll it.

Another solution, given how cheap these NVR's are would be to just swap it out with a new one whenever you needed to add more cameras. Or maybe keep a couple of spare cameras that you enroll to the NVR when you set it up so that all channels are full, then take the spare cameras down until such time as the customer wants to expand their system, then you add a new camera to the NVR.

My guess is this whole issue revolves around Milestone expecting a multi-stream device to always have a fixed number of stream and does not offer a provision to change the number of available streams/channels after initial discovery.

We reached out to Milestone support for an answer on why this is happening, and will update the report when we get a response.

I agree with your wager about the reference by MAC in the database as being a likely source of the limitation, but I was not able to verify that.

Good work, Sean!

I’ve suspected this was the case for sometime now.



Interesting possibility but this is a solution a real integrator would never allow to go out of their building. This has short term gain and long-term nightmare written all over it. Granted, there may be a few (very few) applications where it could be beneficial to the end user in the short term. In the long term everyone will lose because it will break and the integrator will be on the hook to make it work again. 

Why would any end user with 100+/- cameras that wants a strong software solution from milestone risk a solution that is guaranteed to be insecure, unstable, unscalable and unmanageable?

This is the kind of stuff, "only price matters" people do that give our industry a bad name. 

I disagree, though no need to downvote your comment. I think this approach is aimed at the "only price matters" market segment, and gives higher-level integrators a shot at competing with those highly price sensitive customers.

You most likely would not do this for a 100+ or even 50+ camera system. It's for a 4-16 camera system where the user would have ordinarily been "stuck" with the relatively crappy clunky DVR interface. Instead, for the price of a dedicated PC and a license they can get the benefit of a more robust overall interface and architecture by using Milestone as the recorder and UX/UI.

Positioned properly this could make a "real integrator" competitive on these jobs (if they want them), as the lower-end guy may not even be aware of Milestone, or be comfortable selling and supporting it. I would think that if you let the customer use the NVR interface and then use the Milestone interface (possibly with a little coaching at first) they would see how much better the latter approach would be, for a relatively modest price increase.

I agree with you. One of the reasons for my comment was that one of the premises of the article in the first couple sentences was the massive savings on a 100 camera system. 

If one wants to sell, install, commission, service, warranty and provide some level of competent migration plan into emerging technologies for a 100 +/- camera system, this is not how you do it.

While I agree that a company should do their due dilligence before selling a solution like this, the premise is massive savings on Milestone licensing. There are integrators with customers/opportunities that this could work well for.

Why would any end user with 100+/- cameras that wants a strong software solution from milestone risk a solution that is guaranteed to be insecure, unstable, unscalable and unmanageable

How can you guarantee this? Other than the small points that Sean Patton pointed out in the article, what else are you referring to? I get your point that the "camera direct to Milestone approach would be better" but in this case you would have a hard time arguing against the "only price matters" people because we are talking about an $18000 price spread. Is it $18000 better.

Ok, guarantee may be too strong a word for the scenario. How about, "highly probable?"

I can't tell you how many times in 30 years I've heard, "we are never going to add cameras to this system. This is all we'll ever need."

3 months later, "this is working really well. We reduced shrink, we reduced worker comp claims, verified the truck bashed into the skid, etc. Can you add a couple more cameras?"

Ahhh, sorry man, no more cameras can be added without another nvr. But the nvrs are cheap. 

That's not a discussion a professional security company or representative ever wants or needs to have with their end user. 

I'm not trying to dog your investigation and work. You guys do a great service to the industry through tested and verified methods. 

I just have a lot of firsthand experience that patchwork approaches to save money endup with a lot of holes many many times.

For argument's sake if there was a 1 click script to resolve the problem of not being able to add more cameras what other realistic and probable faults can occur? I see this solution adding value as you cut out the poe switch/hd encoder and for a few more dollars you can get a secondary storage point outside of the milestone solution (hopefully they add proper edge support).

Worst case scenario being you have to replace the NVR ($200-$300 which is probably cheaper than a gigabit poe switch). Though I do agree with you on the insecurity aspect considering it has only been tested on Dahua and Hikvision. Although if you get a Milestone server with 2 LAN ports you can wire the NVR and Server on a private LAN that has no gateway. That would effectively eliminate most over the air vulernabilities. Any clients we see with existing analog systems (swann, flir, whatever they got their hands on) usually lasts years and years- same caliber as Hikvision and Dahua. Sure the hard drive may die but the box usually lives around 5+ years. We don't sell those types of systems but they do seem to last for the value when we see them in the field.

If you really had to add more cameras to an installation and did not want to mess with resetting the NVR, you should be able to just add the additional camera licences needed for the extra cameras or another NVR. Still a pretty good deal. 

While more likely to hear that 10 years ago, today I rarely ever hear "we won't need any more cameras".   With the people we interact with they are more knowledgeable about not being unreasonably boxed in to constrictive limits.  That is one of the big, perhaps under represented benefits to IP based systems IMO.

I completely agree that a patchwork approach to save money usually leads to too many compromises.   

This seems like a step for Milestone to move beyond just VMS and create a path to a PISM type functionality...something I'd think they'd be more than happy with.  If this capability expands to other brands and products, then I see it becoming somewhat popular, though larger organizations won't risk it.

If it really doesn't move beyond Dahua or Hik, then it'll be a non-issue.  Funny how we're seeing two different responses from the two top Enterprise VMS players -- Genetec kicks Hik out and Milestone brings them (as well as Dahua) into their own environment.

If you can't beat 'em...join 'em?

This can’t be a PSIM strategy, it doesn’t cost enough. 



This also works on at least one Hanwha encoder - their SRD-1684

You can get that for $360 16 channels 1080p up to 32Mb/s. They will even throw in a 2TB HDD. Not bad for a 16 camera Milestone setup.

While this is true, the SRD-1684 is an HD Analog DVR which Milestone just treats as a video encoder, and does not support IP camera connections.

We have been doing this for years (at a client request not because we wanted to)  and would recommend against it... the overall efficiency of the Universal driver is poor and you will use more bandwidth, more storage and may see more dropouts than with direct driver. 

It works but its really not as good as this report makes out. Yes it saves money but you will probably lose that money in additional support time, extra configuration time and its a single point of failure. We pretty much refuse to do it now as we think it costs us more in the long-run than it saves up-front. 

How responsive is video retrieval in comparison to using Milestone for storage?

Well, technically it using Milestone as storage.

So it is not using the storage on the DVR or NVR? You are still using the Milestone recording server?

With the above hypothetical setup the video footage will be saved to Milestone AS WELL as the NVR being utilized. You will have a primary storage location on the Milestone server and a secondary storage location on the NVR in the event for whatever reason the NVR disconnects from Milestone you still have the recordings on the NVR.

What happens if you do this to attempt to get around the need to add another NVR once you need to add a camera:

Take a 16 channel NVR, manually add 16 IP addresses to it with usernames and passwords. But dont really put IP cameras on the network yet. The NVR will think it has IP cameras added to it, but that they just are offline. 

Then add the NVR to milestone.

Then come back and add ip cameras to the NVR with the same preassigned IP Addresses, Usernames and Passwords.

Bodda Bing Bodda Boom??

I also wager that this can be done with a script that plays with the Milestone DB. Regardless, this issue can be bypassed in my opinion.

It's great you can do this but this just adds to the overall state of this industry. Some people keep selling the cheapest junk they can find and convincing customers this is in their best interest. I get the fact that a customer may not need a high end Cadillac when a nice Honda will but do but selling them a Moped because it is available is just plain silly. Sure it will get them there but not really safe with all the other vehicles on the highways. No different with security. I have found myself doing this once in a while. Man I could save $2 if I use this instead of what I know works perfectly. Yes IP licensing is starting to get out of control on some systems but this seems to be sure fire way to not have a customer in the end if you have to spend a lot of time making it work.

Did you also try the latency on Hdcvi or tvi PTZ cams?

This was a test of NVRs / IP cameras, not DVRs / HD analog.

Not my smartest question :-)

what about ip ptz through the nvr?

Generally PTZ controls do NOT pass through

Generally PTZ controls do NOT pass through

Is that because Milestone doesn’t send them or the NVR ignores them?

Milestone will pass PTZ commands to an analog encoder, though that’s not exactly the same...

It is supported, we tested with a few different PTZs. Control latency was incosistent when moving the cameras live. PTZ Preset recall also worked. Milestone did not detect that the cameras were PTZs automatically, so they needed to be manually enabled in Milestone Management Client.

Again, we strongly advise testing the specific PTZ model with a specific NVR and Milestone.

Read this IPVM report for free.

This article is part of IPVM's 6,800 reports, 913 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now
Loading Related Reports