Genetec and Milestone 500 Camera Recorders Announced

Author: Ethan Ace, Published on Apr 05, 2016

The megaserver era has arrived?

VMS manufacturers Genetec and Milestone have both announced new hardware claiming support for 500 cameras or more, huge increases over past claims.

But the question is: can servers really handle real world throughput for these high camera counts? And is there really any market demand for it?

In this note we take a look at the announcement from both manufacturers, the logistics of bandwidth vs. camera count and other issues, and how these recorders may impact the surveillance market.

*** ********** *** *** *******?

*** ************************************ **** ********* *** ******** ******** ******* *** *** ******* or ****, **** ********* **** **** ******.

*** *** ******** **: *** ******* ****** ****** **** ***** throughput *** ***** **** ****** ******? *** ** ***** ****** any ****** ****** *** **?

** **** **** ** **** * **** ** *** ************ from **** *************, *** ********* ** ********* **. ****** ***** and ***** ******, *** *** ***** ********* *** ****** *** surveillance ******.

[***************]

Genetec ********

** * ****** **** ****, ******* ******:

**** ******** ******, *** **** ****** ****** ** ****** ** able ** ******* * ***** ********** ** *** ****, *** is ******* ** ********** ** ** *** ******* ***/** ******* in ********** *********, ***** ********* ** ********** *** **** ********* for ***** ***********.

* ****** ***** (**** * ***** ******* *********) ****** **** **** throughput, *** ** ** *** *******.

Milestone ********

********* (***)********** *** ***** ** ********** *** ****, *** *****. *********'* *********** ****** ** *** ***** *** ******** beyond *******'* *****:

*** ***** ******** ****** *** *** **** ***********-****** ** ******* 512 ** ******* **** * ********** ********* *********** ** *****/*.

*********, *** ***** *** ********, *********'* ******** **** *** *****, also ****** *** **/* ********** ********, ****** ** ******* ** 120 ****** ********.

Milestone Detailed ********

********* ******* ******* ****** ** ******** ** *** *****, ****** ** their ********** ** *** *** ******/*** **/* ******:

*** ********* ** *** *********** **** ***** ***** ******* ** to ******* *** ******** *** ***** ********* **** *** **** reliable ****** ***** *** **** ** *** ******** *** ********* the ******** *** ********* **** ************ ** ********* ********.  ** do ****, ** *** ******** ********* ************* ***** ******* ******** and ***** ********* **** *** **** ********* ** * ********* as ********. *** *******, ** ******* *** ******* ********** *** document *** ******* ***** ******* **** **** *****.

********* ** *********, *** *** ****** *** *** **/* ******* are *** **** ****, *** *********** **********:

***** *** *********** ** ******** *********** ** *** ****** ** cameras.

** **** ***** **** ********* ** ****** *** ***** **** the **** ****** *****, *** ***** *** ***** (****** ** standard **) ********* **** **** ****** ******.

***, **** *** ******* ** (** *** ****) ** *** limitation ** *** *****, *** **** **, *** ** *** handled more ********** (**** *,*** **/*) ** ***** *****.

***** ** * ******* ******* ** *** *****, ******* ** is *** **** ** *** **** **, ** ** **** to *** ******* **. ** *** ****** *** **** *********, we **** **** *** ****** *** ******* **** ***’* ** give ** *** *,***-*,*** **/* ********* ** *** ******* *** configuration ** *** ******* *********. *** ********* *** ************** ** ********* ********* ** *****/*. (******** *****)

*** **** ** **** ** *** **** ** *** **** that *** **** ** *********** ** ******** ***** **% ***** this ****

******, ** **** *********, **** ** *** **********, ******* ***** *** not ** ********* ** ********* **** **** *** **/* ** the *****. ****, ***** **** **** ** *** ***** ********** the *** ** ******** ******* *******. ****** *** *** ******* of *** ***** ** ** ** ***, **** ******* ** 24 ** ****** **** ***** ******. ******** *** **/*, **** amounts ** **** * **** ** *******.

Camera ***** ** ********** ********

*** ******* **** **** *** *** **** ********* *** ********* maximum ******* *********, *** ***** ******: ***** ******* *** **********.

****** ***** *** **** ** ****** ******* ** *** ********* consumed *** *** *******. ********* *********** *** **** *************, **** under ***/* ** ***/* ** ****, ********* ** ***** ****, compression ********, ***** **********,***** ******, *** ****. ******* ****** *** *** ********* ***** *** ***** ************ *** **** ******* ** ***** *********.

Generally *** ***** ** ***

** *** ** *** *******, ***** *** ********* ********** ******* Genetec *** ********* ****, *** ******* *** ***** ** **** to **** ****** *** ********.

*** *******, ********* ********* ** **:

*** **** ***** ** *********** ******* ** *** ************* ** the *** **** ***** **** ** ** ********* *** - 720P ** ******* ******* ** *****, ***/* *** ****** ** disks.

** *** *****, * **/* ******** ** **** ***** ****** are ****. *** *******, ** *** ********* / ******* ******** (******* **** ****** ****), **** ******* ******* ******* ******* ****** all ******** **** * **/*. ** *** *****, **** ****** averaged ~*-* **/*. ********, ***** ******** *** **** ******, **** **** motion *** *** ***** ****** ****** ***** *-* **/* ** more. **** ***** *** *** ******** **** ******, *** **** fading, ***** ******* *** **** ********* ********.

**** ***** ***** ******?

**** **** ***** ****** **** ** **** *********, ********* *.***+, or ******* *********** ** ****** ******* ********. *******, **** *** ***** ********* in **** ****** ******, ******* **** **** ******* **** *** limited ********, *** ********** ************ **** ***** ** **** *** worst **** ********* ** *******, **** **** ********** ******** **** ** these *** ******, *** ****** **********.

Large ****** ***** ** *******

***** **** ********** ******** ******* *** ********* ********* ** **** allow *** ****** *********** *** *********, **** ***** ****** ****** (200-300 *** ****** ** ****) *** ********* ******** ** *****, as *** ****** ******* * **** ***** ****** ***** ** failure. **** ** ********* ** ******* ******* **** ** ****** server ** *** ***** ** *******, *** **** **** ********** *** configuration ****, ** **** ** ********* ********* ***** *** ********** hardware ************.

**** ****** ***** ******** ********* ***** ****** ******** *** **** likely ** **** ********* ******* *** ***** *********, *** **** is *** **** ** *** *****.

Ethernet ***********

*** ***** ******** ****** ** ****** ********** ** *** ******* interface. ** **** ********, ******* ******** ** *** ******* ********* available, *** ** ******* ** ~*** **/* ****** ********** ** less. ****** ********** ******** ***** ******** ******* **********, ****** **** potentially ****** ** ******* *** ******* ** *** ******* *******, or ********* ****** *** ********* ******** ** ** ***, **** more ********* **** ******* ******* ******.

Other *********** *******?

******* ** ***** *************' *** **********/****** ******** *****, *** ****** make ****** ***** ****** ** **** ** ******* *** *********.

  • ********'* ******* ********* ******* *** *** **/* ** * *** ****, *** only "** ** ***" *******, ********* *** ** ~* **/* per ******, **** ****** ** ********* ********.
  • *****'* * ****** *********** ** ** *,*** **/* ********* ********** (******* ** *****), but **** *** ******* *** ********, **** * **/* ****. 
  • *******, *** ******* **** **** **************************** "****" *** *******, *** *** *** *** **/* **********, respectively.
  • ******: ************'*********** *** ****** *** ******/ *,*****/* **********.

************?

******** ******* ******* ** *** **-** ****** ***** *** *** **** ******** ** ******** ** ****, ***** ******** servers **** ** ***** **** ******* ****** ** *** ******. Very *****, **** ****** ***** *********** *** **** ***** ********* bandwidth ******** **********, *** ***** ******* *** ***** ****-*******, *** running **** ******* ** ******* *** ****** *** ** ***********.

****, ***** ***** ***** ****** ***** ****** *** ***, ******* of ***** ******* ****** **** ********* ** 

Signaling ******

******* ***** ********* *** *********** ******, *** ****** ***** *** ****** are ****** ********** *** ***** ********* ********, ****** **** ** why ** ******* ********* ********* **** *** **** **** *** 512 ****** ****** *** **** (****, ** ********, ** **** Genetec *******, **** ****** ** ** * **** **** **** a ******* *****).

Take *** ****

**** ** *** ***** ** ***** ***+ ******* *********? **** and **** ** *** ** *** ********.

Comments (36)

But why

One or two customers needed it, so they built it. Now they're offering it to the world to appear innovative...That's my guess at least.

I've done 500 cameras in a single VMS instance. That was to take advantage of some of the existing infrastructure the organization had. They already ample processing power in terms of servers to run the VM in, and the network infrastructure allowed for 10 gb/s in. It also let the IT department have both redundant failover at the software level, along with back up VMs that could be spun up pretty quickly.

What they didn't have a lot of was free rackspace. So there was a trade off in terms of complexity of set up for a savings in real estate. It's not something that everyone would run into, and the degree of complexity isn't that much for an IT department with the skill set for it. But they also gained redundancy for software failures, and the failover VM was on separate hardware.

It's not something I'd ever do with a pre-built recorder because you're sacrificing a lot of the advantages gained by using VMs. And you'd be pretty storage limited. But I'm guessing this is less about the hardware announcement and more about the camera count for enterprise customers.

I am curious if the statistics were done with 500 cameras actually connected and streaming, or was the data extrapolated based on a much smaller number of cameras and then the usage multiplied? I am skeptical if this scenario would be linear enough to do that.

Just added a poll on this: how appealing is a 500+ camera recorder to you? Take a minute and answer above.

"In most networks, gigabit Ethernet is the fastest interface available, and is limited to ~800 Mb/s actual throughput or less"

Yes, my experience is that is burst, with sustained throughput being actually quite less, maybe 60% of the wired connection's rated speed.

Can Miletone and Genetec clarify if that is sustained throughput or burst?

Their numbers are sustained. The ~800 Mb/s is our note, not theirs. I've been seeing 70-80% of rated in any testing we've done, but we haven't done full formal testing of it, either.

Below is the correct info for Avigilon's HD NVR Premium servers. We have a hand full of these in the field with one pushing 230 cameras and ~500Mbps. For large enterprise customers these large capacity servers are very useful IMHO.

I'd be curious to know how well server side VMD works if enabled for every camera on a 500+ camera NVR?

Anyone got any experience with that?

Good question, we've asked Milestone to comment on this and I'll report back when they do.

[Update: Milestone confirms their calculation assumes camera side VMD. Server side VMD of 500 cameras would likely add a very high processing load. Related: VMS Server Load Fundamentals Tested]

I'd be curious to know how well server side VMD works if enabled for every camera on a 500+ camera NVR?

I think the CPU would vaporize in a matter of seconds.;)

Why would you even consider server side VMD and tax the server when the camera can do that for you? I highly doubt that they the manufacturers are planning on that even being tried with their 500 camera appliance.

Yes, one would think so, but to play devils advocate... I have meet some installers that always use server side motion detection - I am not sure why. It could be out of ignorance, or perhaps they find it more reliable, or easier to setup. Perhaps they are using 500 ultra cheap cameras that do not transmit their motion events to the VMS (there are some cameras like this). Maybe it isn't 500 cameras at all, but 500 streams, in which case you might have 250 cameras each with a second low resolution, low FPS stream, and with sufficient number of cores (don't they have 18 core Xeons these days?) then maybe these appliances can handle it. That is why I thought the question was interesting.

In case of Genetec, the timeline is only showing motion with different color if you set VMD on the server. If the camera is doing the VMD you have a continous grey line. Most operators like to see a visible sign of where was motion on the recordings. Motion only recording is not allowed for security reasons.

Displaying edge based motion on the timeline sounds like a basic feature that any VMS would support.

I have not seen the Genetec software, but could it be that you are using cameras that do not send motion events? or perhaps they send them on a different port, and that port is blocked.

What cameras were you using?

We asked Genetec to clarify the server vs. camera motion display, and this is their feedback:

Most vendors provide a simple VMD event while a few provide VMD metadata. Axis cameras, for example, provide us with some additional information such as the exact level of motion. So we receive the motion detection level in % and the size of the green bars displayed in Security desk varies based on the level of motion received from the camera.

Other camera manufacturers provide us with only a basic event motion on/off or true/false information. In this case, we display a full green bar when the motion is on and we display nothing when no motion event is sent.

Limitations of hardware motion detection
When motion detection is performed by a video unit, the following limitations apply:
• Not all units support multiple motion detection zones. If you switch motion detection from being
detected by the Archiver to the unit, the existing zone configurations not supported by the unit are
lost.
• The unit might not interpret the Sensitivity parameter the same way as the Archiver. Therefore,
when testing your motion zones, the results might not be accurately reflected in Config Tool.
• The Motion search task in Security Desk is not supported.
• Motion indicators (green bars) are not shown in the timeline during playback.
NOTE: This limitation does not apply to Axis cameras.

We use server side motion for many reason.

1) Uniformity of detection

2) Unified interface, not logging into each camera individually

3) Smart Search ability in DW Spectrum (NX Witness)

4) We account for the hardware up front

5) We limit each server to 64 cameras, which is modest for the servers we build/spec

6) Camera side VMD isn't always available in the cameras we use (Hik/Dahua), due to the VMS

single point of failure eeek!

prefer my VMS split between multiple Virtual machines and Multiple physical servers

Exacq does not not have a fixed limit, you can license until it craps out. With SATA drives performing at 3 Gbs and up network is the weakest link. Assuming you bond your interfaces plus configure the switch for it and by establishing a secondary viewing & management Lan.

I could be wrong here, but if a client has 500+ cameras, they likely have 10GbE LAN too, right? Why would 10GbE be too costly? Wouldn't a server of this scale be a premium over a cluster of smaller servers anyways? What's another >$1k for a 10GbE NIC?

I really dislike the use of number of cameras per NVR. VMS/NVRs should be rated in throughput with a camera max listed as secondary information. I like how Avigilon and the manufacturer I am evaluating specifications indicate max throughput then max number of cameras. Many still list # of cameras only and you have to dig deep to find throughput information.

Evaluating the throughput rating of NVR's has been a big question of mine for some time and I currently have a design that I have been working on that has over 700 physical cameras with over 1000 camera streams (some are multi-imager cameras). Total throughput is around 12Gbps and storage is approximately 3 to 4 PB for 30 days (24x7x30).

The manufacturer of the VMS we are evaluating claims a throughput of 400 Mbps using their NVR (customized Dell server) and 300 Mbps for 3rd party server. These numbers are recording throughput and that the same rate can be achieved for video retrieval.

The client requested that the project follows their current data center guidelines and that we add to the existing VSphere environment using Cisco UCS servers and a Dell storage area network.

For this project, we evaluated the option of using Cisco UCS B Series Blade Servers (Dual CPU Xeon E5-2660 B420 M4 Blades) with one NVR instance per CPU. The Cisco UCS chassis supports VIC (virtual interface computing) network interface cards that allow for high speed fabric connection directly from the virtual machine to the core network using multiple 10Gb interfaces. The servers would be connected to a Cisco Fabric Interconnect switch that is connected to a Nexus 7004 core via multiple 10Gbe interfaces.

For the storage solution we are looking at Dell Compellent FS8600 storage controllers connected to the Cisco 7004 via multiple 10Gbe interfaces. This solution drops off the fabric at the Cisco 7004 utilizing 10Gb iSCSI to the Dell SAN. For the storage backend we are using Dell S5000 switches and SCv2080 storage arrays.

I would think the server configuration above would provide the 400 Mbps throughput rating equal to the manufactures provided server or even higher. Without having a way of testing or confirming the actual bottlenecks in the NVR platform it's hard to make any assumptions.

The other issue is the cost of the virtualized server and storage area network in this solution is a more expensive option than using the manufacturers NVRs and the management without a qualified IT department would be a nightmare. The manufacturer offers 90TB single NVRs which would provide all storage in the NVR without need of any external or attached storage. From a keep it simple standpoint the standalone NVR would be the best option.

12000 Mbps total throughput / 300 Mbps (400 minus some breathing room) = 40 physical NVRs for this project with 3600 TB of storage. Using 300 Mbps (they recommended 200 Mbps for virtualized) we would need ~60 virtual machines.

Other issues that come up would be server side video analysis and transcoding. What is the impact of storage only on the CPU and at what point of utilizing the CPU beyond this causes any impact to the storage throughput. The manufacturer being evaluated does have a tech paper showing different camera/server configurations and results that help make some assumptions but it is based on their NVR solution.

It would be nice if IPVM could start a section on NVR throughput testing and bottleneck evaluation. I would love to hear from other users here on their experience with NVR throughput, especially in a virtualized environment.

EDIT: One point I forgot to make and was a reason for my comments above. We are using high resolution high bandwidth cameras for all designs now. As such we have a need for high throughput and not high camera count NVRs. The solution I indicated above would only be 15 to 25 cameras per NVR.

NOTICE: This comment has been moved to its own discussion: 700 Camera Server Sizing Question

Andrew

It is not as much the "VMS" that has the limitations rather the architecture. I think all mature VMS at this point should be similar in throughput from the "software" side. As a manufacturer, we constantly evaluate our VMS software throughput versus raw data bypassing our software. The differences are insignificant. When we have compared to our competitors it is very much similar. It comes back to hardware.

There are other factors involved - such as processing but we have found that the problem first arises on the RAID and drive side of things. This is straight math. Processing comes into play when you start to tax the VMS with analytics or other resource intensive items. When people ask how many analytics can i run on a server - the question is similar to how high is up. There are infinite variables. Some times we like to say a camera per processor core but that is a very crude metric since if there is little activity and infrequent analysis that number can grow. But that is similar again to saying how many cameras can i put on a server.

We have conducted an analysis of data throughputs on a variety of hardware environments and will share the results. You also have to look at some other factors. We often tell a customer while your car can drive at 125MPH would you drive it at top speed 24 hours a day. If you have a one ton pickup and load it to capacity how long do you think it will last. Everyone seems to want to push the envelope rather than best practices in design systems. Maxing out systems or even close to maximum is an issue because everyone forgets the what if scenarios. What happens when you have a malfunction or degradation of some sort - how will the system respond.

So you're saying that distributed architecture is the way to go and giant recording appliances are a dumb idea? Got it.

It really depends on many variables. Ultimately, what are the customer objectives. We worked on an airport project overseas where there were 10,000+ channels of video and some "lofty expectations." The design aspect was a major undertaking but the question we asked the customer was who was going to maintain it. Everything was to be virtualized with redundant command and datacenters. Included were all aspects of security not just video. Access, intrusion, analytics, etc.

For simplicity and easy management we have found that RAID10 systems which can easily accommodate 500Mbps throughput are the ticket. Size the number of cameras accordingly. Try not to use 100% of throughput in case of drive rebuilds, etc. 75% capacity would be recommended. If someone wants to be adventurous well...

Today, we offer storage arrays with 60-80 drives in a 4U box. With 8TB drives out there that is alot of storage in a small platform.

Also to take into consideration is fault tolerance and redundancy and how that is handled. Virtualization has some benefits there but to a point.

With respect to giant recording appliances the concern is always what happens in the event of a catastrophic failure. Believe it or not many people still do not understand that having 2 CPU in a single server is not redundancy and if you lose a CPU you lose your system the same way you would with a memory failure.

What is the threshold for acceptable video loss on failover. We have several government clients who record for more than 1 year and will not allow even a single frame loss over the period. So an architecture was designed whereby "long term" storage is written to a single large appliance and a redundant "short term" storage is located on "opposite" servers for a short period of time (days). So in the event of a catastrophic failure there is a buffer period being written elsewhere until the failed device can be re-engaged.

There are easy methods to make giant recording appliances work and no requirement for a PhD to manage and maintain. But just has to be well thought out. As you know as well, the appliance is one thing and the network and power is another story.

How does one manage redundant self healing networks. Site redundancy, power redundancy, etc. It can get complicated. The question we often ask does come back to not just the budget for the system but for the maintenance and upkeep as well, which is a "job."

"But just has to be well thought out. "

Couldn't agree more.

Milestone confirms their calculation assumes camera side VMD. Server side VMD of 500 cameras would likely add a very high processing load. Related: VMS Server Load Fundamentals Tested

Server side VMD of 500 cameras would likely add a very high processing load.

I think the decoding you would need to do before even looking for motion (assuming h.26x) would add at least as much processing as the actual analytic.

I have personally found Milestones recommendations as to what a specific set of hardware can and cannot do to be useless

Michael, what specific issues or problems did you find with Milestone's hardware / sizing recommendations?

"on that hardware you should have no issues with 60+ camera's"

when we find services starting to fall over and other issues when we get close to 40 cam's on the hardware we listed to them, this is without anyone actually accessing the specific server.

I've always found their estimates way off.

Theoretically anything is possible and comes back to the "bottleneck." It is not what they do tell you in the press releases but what they don't tell you.

First concern is the read/write speed of the hard drives which is where you can first back up. So the answer to increasing the throughput is higher speed drives which are disproportionately more expensive and then financially illogical.

Next you have to look at the RAID array configurations. RAID 10 is going to double the Mbps throughput of a RAID 5 scenario. Of course RAID 5 you would lose approximately 25%+ with storage and RAID 10 50% in storage. Unrelated to this is what no one ever seems to consider is what happens when the RAID becomes degraded - testing shows that in a RAID5 you can lose more than 80% of your throughput during a rebuild while a RAID10 is nominal.

Next is the process of virtualization. Using a blade server and virtualizing the distribution and storage arrays.

Once you have figured out the actual throughput then of course we know it is a matter of math. The age old question then of how to make the math work of lower frame rates and resolution which subsequently lower overall bitrates. The question i often ask is if you are going to lower the resolution and bitrates on a high megapixel camera then why did you spend the money in the first place on a camera which has the capabilities to provide higher quality images. Bitrate = Quality.

So yes probably even 1,000 cameras is possible as well if you work the math and the hardware!

You mean I can put up one box and record all my eggs in a single basket! Wow! Think of the savings!

I smell BCDVideo in here somewhere, not that that is a bad thing - but 500 camera server is just asking for trouble if it goes down.

I remember more than a decade ago when we were marketing 32 channel DVRs and we were told that's ridiculous no one is going to buy it - who in their right mind would put more than 16 cameras on a single server and take the risk.

Update: I just saw an old relevant discussion to this. 2 years ago, IndigoVision released an NVR spec'd for 700 cameras / 2,000Mb/s throughput.

Login to read this IPVM report.
Why do I need to log in?
IPVM conducts unique testing and research funded by member's payments enabling us to offer the most independent, accurate and in-depth information.

Related Reports

Last Chance - Save $50 - July 2018 IP Networking Course on Jun 20, 2018
Today, Thursday the 21st is the last chance to save $50 on registration. Register now and save. This is the only networking course designed...
Axis Guardian - Cloud VMS And Alarm Monitoring - Released on Jun 19, 2018
Axis has struggled to deliver a cloud-based managed service video platform. Video service providers have utilized AVHS for over a decade, and have...
Four Major Outdoor Camera Install Problems on Jun 14, 2018
Over 140 integrators told us the top four camera installation mistakes that lead to unexpected problems and failures. Their comments often...
China Public Video Surveillance Guide: From Skynet to Sharp Eyes on Jun 14, 2018
China is expanding its video surveillance network to achieve “100%” nationwide coverage by 2020, including facial recognition capabilities and a...
Access Control - Time & Attendance, Mustering and Mantraps Guide on Jun 13, 2018
Electronic access offers features that traditional mechanical locks cannot. While these features may not be as fundamental as keeping doors secure,...
Powerline Networking For Video Surveillance Advocated By Comtrend on Jun 08, 2018
Powerline networking, using existing electrical wiring, has been around for many years. Indeed, over the years, some video surveillance providers...
H.265 / HEVC Codec Tutorial on Jun 07, 2018
H.265 support has improved significantly in 2018, with H.265 camera/VMS compatibility increased compared to only a year ago, and more manufacturers...
Dahua Products Are Not GDPR Compliant, No Products Can Be on May 29, 2018
Dahua products are neither GDPR-compliant nor certified, contrary to their marketing. The reason is that no products can be, as the EU does not...
VMS Server Sizing on May 25, 2018
Specifying the right sized PC/server for VMS software is one of the most important yet difficult decisions in IP video surveillance. In the past...
Software Only VMS vs NVR Appliances on May 23, 2018
Should you buy your own PC/server and load VMS software on it or get a turnkey appliance (both hardware and software, e.g., NVR, Hybrid DVR) from a...

Most Recent Industry Reports

IFSEC Show Report Day 2 Report on Jun 20, 2018
IPVM is live from London reporting on the IFSEC show. The Chinese have taken over the UK, centered on Hikvision, flanked by Dahua, Huawei and a...
Mobotix Releases 'Move' Into 21st Century on Jun 20, 2018
For years, Mobotix stood resolutely against, well, every other manufacturer, selling it as a virtue: MOBOTIX equipment is designed with no...
Cybersecurity Startup VDOO Disclosing 10 Manufacturer Vulnerabilities Starting With Axis And Foscam on Jun 20, 2018
Cybersecurity startup VDOO has uncovered significant vulnerabilities in Axis cameras along with many others not yet disclosed. In this report, we...
July 2018 IP Networking Course on Jun 19, 2018
The last chance to save $50 on registration is this Thursday, June 21st. Register now and save. This is the only networking course designed...
Axis Guardian - Cloud VMS And Alarm Monitoring - Released on Jun 19, 2018
Axis has struggled to deliver a cloud-based managed service video platform. Video service providers have utilized AVHS for over a decade, and have...
IPVM Vulnerability Scanner Released on Jun 18, 2018
IPVM is proud to announce video surveillance's first and only cybersecurity vulnerability scanner. This tool allows quickly and simply...
Hikvision Corrects False Cybersecurity Announcement on Jun 18, 2018
Hikvision has corrected a false cybersecurity announcement that claimed a British government-sponsored program endorsed the cybersecurity of...
The Dumb Ones: PSA's Bozeman On Cybersecurity on Jun 15, 2018
The smart ones are the hundred people who flew to Denver and spent $500+ on a 1.5-day conference featuring Dahua as a 'cyber responsible partner',...
Amazon Ring Launches $10 Monthly Professional Alarm Monitoring on Jun 15, 2018
Amazon's Ring has announced an alarm system with 24/7 professional alarm monitoring for $10 per month, a fraction of the $30+ per month traditional...
Axis Releases First New Access Controller In 5 Years (A1601) on Jun 15, 2018
It has been 5 years since Axis 2013 entry in the physical access control market, with the A1001 (IPVM test). Now, Axis has released its second...

The world's leading video surveillance information source, IPVM provides the best reporting, testing and training for 10,000+ members globally. Dedicated to independent and objective information, we uniquely refuse any and all advertisements, sponsorship and consulting from manufacturers.

About | FAQ | Contact