NTP / Network Time Guide For Video Surveillance

By: IPVM Team, Published on Jan 10, 2019

Inaccurate time can lead to missing or inadmissible video, yet this topic is often overlooked, with cameras and servers left defaulted, synchronized to different sources or not at all. However, setting up a proper time server in a surveillance network often requires little time or money and can prevent or mitigate these potentially disastrous issues.

free

In this guide, we review network time for surveillance, covering these key topics:

  • Time protocols: NTP, SNTP, Windows Time
  • How cameras handle time sync - on arrival vs camera timestamp
  • How recorders / VMS synchronize time
  • Time server options
  • What you should sync
  • IP vs Non-IP Cameras

********** **** *** **** to ******* ** ************ video, *** **** ***** is ***** **********, **** cameras *** ******* **** defaulted, ************ ** ********* sources ** *** ** all. *******, ******* ** a ****** **** ****** in * ************ ******* often ******** ****** **** or ***** *** *** prevent ** ******** ***** potentially ********** ******.

free

** **** *****, ** review ******* **** *** surveillance, ******** ***** *** topics:

  • **** *********: ***, ****, Windows ****
  • *** ******* ****** **** sync - ** ******* vs ****** *********
  • *** ********* / *** synchronize ****
  • **** ****** *******
  • **** *** ****** ****
  • ** ** ***-** *******

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

Time *********: ****, ***, ***

***** *** ***** ****** time ********* ** *** in ******** *****:

  • ****:****** ******* **** ******** is *** ******** **** protocol ** ***, *** also **** ****** ** surveillance. **** **** ***** resources **** *** ** PTP, ***** ***** ** appropriate *** ***** ******* devices **** ** ** cameras *** ******** *********. However, ** ** **** accurate **** ***, **** to **** **** ** a ****** ******, *** does *** ******* ********* error ******** ** *** source, ***** *** **** to ********** **** (****** this ** *** ******).
  • ***:******* **** ******** ** more ******* **** **** and ******** **** *********, but ** ** **** to *********** ** ******** time *******, ******* ***** correction *** ******** ** sources *** **** ***** from ********. ** ** generally **** ** *******/***** servers ** ********* **** servers.
  • ***:********* **** ******** ** relatively *** ******** ** NTP/SNTP, *** *** ********** for *************** ** ****** sensitive ************. ***** *** and **** ******* *********** accuracy, *** ** ******** down ** ***********. ******* of ****, ** ******** hardware ******* *** ****** timing *** ******* ********* than ***** *********, *** is ********* *** **** in ************.

Device *******

* **** ****** ******* one ** ***** ********* provides **** ** ******* (cameras, ****** ***, *******, etc.) ***** ******* **. This *************** ** ***** performed ***** ****, ****** some *** ****** ** run ** **** *****, in ***** ***** **** accuracy ** ********. **** that ******* **** *************** on * ***** ****** of ******* ******** **** little *******, ** ******** sychronization ******** ** ****** to **** ****** ****** on *** *******.

************ ******* ***** *** not ***** ******* **** support *** ** ****. It ** ****** *** devices ** ****** ***** 'time ***************' ******* ** SNTP ** *** ************. Effectively, ******, ******* ******* both *********, ** *************** packets *** *********. ********** features ** *** *** supported ** * **** requesting ******* *** ****** disregarded.

Windows ****

**'* ***** ****** **** Windows ******** ***** ********** *** *** ***** has ************ **** **** in **** ********. *******, configuring * **** ****** using ******* **** ******** users ****** *** ******* ********, ***** **** ***** may *** ** *********** with. ************, ** ** notoriously **********, **** ******** seconds ** ***** ******, so ****** *** ** used ** ************.

How ******* ****** ****

*** **** ******** ** current ** *******, ********* low **** *** ******** models, ***** *** ********* synchronization ** *** ****** to * **** ******. Users ********* ****** ***** the ****** ** ******* or ********, ****, *** time ****, *** *** camera ********* ******* *** time *** ******* *** on-board *****. **** *************** is ********* ********* ******, though **** ******* ***** for * ********* ******** to ** ***.

**** ***** ***** ***** typical ********:

**** ***** *** ******** Savings

******* **** ******* ******* UTC, ***** ******* ** time **** ** ******** savings (***) ***********, ***** settings **** ** ********** in *** ******. **** camera **** ** *** to *** ***** **** zone. *** ***, **** devices ******* ************ ******* for *****/*** ***** *** time ****** (********* * hour). ****** **** ** automatically ******** **** *** begins *** ****.

***** ******** *** ***** in **** ****** *****:

camera dst settings

*******, ** **** *******, only ** "****** ***" checkbox ** ********, *** users **** ******** *** and ***** **** **** daylight ******* ****** *** ends. **** ****** ** taken ** ****** **** is ****, ** ********** time **** ** ******** if ** ** ***.

****** ****

** ******** ** ********* sync *******, **** ******* also ***** *** **** to ** ******** ***. This ** *** ***********, as ****** ********** *** easily ** ********* ** incorrectly ***, *** ********* time ** **** * handful ** ******* *** become ******* *** **** consuming. ******* **** ****** is ******* ********, ** is ********* ** *** the **** ** **** camera ** *** **** second, *** ***** ** a ****** ** **** off. ******** **** ***** over **** *** *** cause *** ******* ** be **** ******* ** more ***. ** **** case *** *** *** obscure **** *********** (*.*. 6 ******* ***, ** minutes ***, ***) ******* cameras *** ***** ******* on *** *******.

How ********* / *** *********** ****

***** *** *** **** VMSes ****** **********: ******** frames **** *******, ** using *** ******'* *********.

******** ** *******

******** ** ******* ** exactly **** ** ****** like, **** *** *** marking *** **** ** receives **** ***** ** video. **** ****** ****** caused ** ****** **** being **********, ** *** server ** *** **** source ** ****. ** very ***** *******, ** systems **** **** *******, it *** **** ****** for ****** **** *** camera ** ****** **** frames **** ******* ******, which **** ***** ***** to ** *** ** sync. *******, **** ** rarely * ********* *******, as **** *********** *** very ***** (and ***** ****** *** not ******.

***** ****** **********

***** ******* *** *** timestamp ***** ** ***** by *** ******. ** cameras *** ******** ************ to * **** ******, this ****** *** ** an *****. *******, ** one ** **** ******* are ***** ********** ****, issues *** ******, ******* from ******** ** ******.

** * ******'* ***** is **** ** *** hours, ***** ** *** VMS ****** **** ** marked ** *** ***** off. ********* *** ***** at *** ******** **** will ******* ***** **** another ****, ***** *** desired ***** *** ******** been ****** *** ***** in *** ******. **** makes ************ ******** ********. Worse, ** *** **** video ************ ** *****, as *** ********** ** not ******* *** ****** time * ***** **** place.

Time *******

***** *** ***** ***** ways ** ***** **** to * ************ *******:

Public *******

****** ******* **** ** time.gov *** ***.*** *** most ******** **** ** synchronize **** ** ***, though **** ******* **** use **** ** *******. However, ** ***** ** use ***** *******, *** devices **** **** ******** access, ***** ** ***** undesirable ** ************ ********. Also, ***** ***** ******* for ******** ******* ** considered **** ******** ** the ** ********, ** local ******* ******* ****** traffic *** ******** **** of ****** *******.

Private *******

** * ************ ***, one (** ****) ******* may ** ********** ** a **** ******. **** machine **** ********* **** from * ****** ****** such ** ***.*** ** is ******** ***, *** serves **** ** *** other ******* ** *** network. **** ** **** often ********** *** ***** party ******** **** ********** ************.

**** ********** ***** *** setup ** * ******* NetTime ******, ** **** case ******* **** ******** sources, **** * ** minute ***** *********:

nettime server settings

***** ****** *** ** may ** *** ** to *** ** * time ****** (********* *** VMS ******), ******* ****-********* load, ******* ******* ********** time **** ** ******** source ** *** **** common **** ******** ****** in ************.

Dedicated **** *******

*******, ** ******* ***** accurate **** ** ******** but *** ************ ****** is *** ********* ** the ********, ********* *** based **** ******* *** used. ***** ******* ******** time **** *** ********** via *******, ****** ******* to * ****** ** external, *** *** ** NTP/SNTP ******* *** *** rest ** *** *******.

********* *** **** ******* vary ** *****. ***** priced ****** ***** **** about$*** *** ****** (**** Machines *******)** *****$*** *** ******(******** *******). ******** ******* (**** as*********************) **** ********* ******* nanosecond ********, ********* ******** antennas, *** ***** ******** features **** *** ****** 2-3 ***** **** *****, or ****.

******* ** *** ***** installation *** ******** ****, GPS ******* *** ********* only **** ** ******* where *** ************ ******* is ******, ******* ****** to *** ********.

IP ** ***-** *******

***-** *******, **** ******, HD ******, **-***, ** not **** *** ******* or ************** ** '****'. The ******* ** ******** these ******* ******* ** stamps **** **** ***** is ********. ** ***** systems, **** **** * single ******* ** ********, this ********* ******* ** the **** ** *** cameras ***** ************. * time ******, *******, *** still ** ********** ** ensure *** **** ** accurate. ********, ** ***** are ******** ********* ********** to ***-** *******, *** same **** ****** **** those ********* ***** *** of **** **** ******** IP *******.

What ****** * ****?

** ***** *** ********* problems, ********** ** *** the *** ****** ******* timestamps, ** ********* **** all *******, *** *******, and ******* ** ************ to *** **** **** source. ****** ** *** not ** *********, ******** time ****** *********** ******** minimal **** ****** ******* setup *** ********** *** potential ****** ** ******.

Poll - ** *** **** *****?

**** **** *********

***** ****** **** * * question ****

Comments (38)

Meinberg NTP does an exccelent job as a ntp server. Very easy to install and config.

A lot of times when I'm diagnosing timing and synch issues I get the same mistake commited by the guys installing the cameras, vms, etc...

Sometimes they forget to synch the PC running the VMS to the NTP Server.

So, you have a pc/server running the Meinberg NTP software as the NTP Server. You have your cameras and nvrs synched to that NTP Server. And on the pc running the VMS, you would need to install meinberg and set it to synch with the main NTP Server. So them everything is synched and you get no errors "camera and vms are out of synch".

-----------------------------------

When you have more than one ntp server and sometimes to diagnose/force ntp

synchronization, you can change the STRATUM of the server.

I always recommend NTP sync. I usually will sync the cameras to in internal server (Such as an NVR), and then the NVR syncs to internet. I use the pool.ntp.org server usually. Mosst NVRs and VMS servers have an option to be an NTP server. If not, a simple Windows registry setting allows any PC to act as an NTP server - it won't be completely accurate, but at least all of your devices will be synced.

I have found that some cameras will not sync if the clock is too far off, so I often will do a manual time set first, then an NTP sync.

Some services in cameras use an accurate clock, and may fail if the clock is too far off, such as SNMPv3, SSL, SMTP w/SSL, etc.

Also, SD card recording will be useless if the clock is inaccurate.

I always recommend looking for a manufacturer that has software to 1)push the time/date/NTP info to cameras en mass, & 2) create a report to verify the time is correct in the cameras. I have been at sites where we forgot NTP, and to manually update 300 cameras is a pain, and asking for fumble fingers to make a mistake or miss a camera....

As mentioned above, DST is always confusing... Most people don't realize that NTP has nothing to do with DST. The camera or NVR must have the intelligence (calendar) and a time zone setting for DST. Different parts of the world use a different DST calendar and there are also parts of the world that are not in a full 1 hour interval from GMT...

I always set the clock correct before configuring an NVR to record so the video isn't cataloged with the wrong time stamp.

In our internal network, we run NetTime as a server on three machines and as a client on every Windows PC. The main server syncs to the North American NTP pool servers. The second and third servers sync to that one, with the pool as a backup in case it's down. Reason being that sometimes we move things around, so one or more of these might be unplugged, and we want other devices to be able to grab the time.

Literally every device in our network syncs time to that server. Every camera, every client PC or laptop, every VMS server or recorder, even the managed switches. I'm a little obsessive about it...

Excellent point about SD card recording. I'll add that as a point in the report, as it's becoming more of an issue, and we've had at least one user complaint about time and local recording.

I'm pretty impressed that 83% (as of right now) of people answering the poll sync their time. In past polls I think it was less than half of that.

More people time sync their cameras than change the default passwords of their cameras???

Members who already do not feel the need to setup time sync between VMS and cameras are less likely to read a NTP Guide, let alone to the very end, where the poll is.

Were the other polls in a similar format?

I was mainly kidding with that. I do think the NTP usage poll results are skewed high as there are clearly plenty of people who see the title and say the equivalent of "What's that, I don't care."

Sorry, didn't mean to give you an unhelpful. Accidentally hit button.

Dear Ethan , I had a samsung NVR which is not synchronizing the time.The NVR is connected to a switch. I had not checked whether the switch is managed or un-managed . Do u think the NVR will not sync the time to the server if it is a un-managed switch. Is the switch must be managed one to sync the time to the server ????

MD, the switch should have no impact on time synchronization. Time synchronization can easily be off but that is almost always an issue of configuration on the IP camera or recorder, not the switch.

MD, like John said, it's very unlikely to be the switch that is blocking your time sync. It is possible though if you do have a very tightly secured network and the switch is configured in a way that only allows very specific traffic. But, this would be very rare.

More likely is that your firewall is blocking the port for NTP traffic, if you are trying to reach an NTP server outside your network. Or, it could also be a local firewall on your NTP server if it's local.

If you don't have total control of the network, you should find out who does and ask them for assistance.

More likely is that your firewall is blocking the port for NTP traffic...

Or maybe there is no route at all to the Internet, if on an isolated network.

As a followup, here are some things that I have found that often rely on an accurate time, and if the clock is too far off they may fail:

Camera scheduling for various things like events, sd card recording
Sd card recording scheduling and time stamping (if an NVR injests this video, then it will be in the wrong place)
day/night switching on a schedule
video profile/settings switching on a schedule
802.1x
snmp v3
ONVIF from NVR to Camera

SMTP - email sending

FTP - time stamp

Of course, access control also needs accurate time & sync....

This has always been one of the highest concerns to me on VAN's (Video Area Network) and am very excited to see it addressed here as I think it is typically not given the importance it needs. I have found it is really a two step process that involved procuring of the correct time consistently and securely and then delivery of this time to all devices also securely. I have used Spectracom for years and it's support of MD5 hashing for pulse authentication is something I have greatly appreciated. As to delivery I have used many products with DomainTime II being the best I have ever used. It is not frugal software but has kept my networks below 10MS of time differential for years now. As to analogue camera systems this function was typically performed by the distribution equipment such as the distribution amps or Matrix and is a common source of pain in these environments as it looks sloppy when 32 monitors all show a different time stamp and when this overlay is recorded into the DVR or NVR video it also creates other problems speaking to video accuracy. Great write up E!

While I certainly do make sure every single device I install has NTP and DST setup properly, I think some of you here are going a bit overboard, at least for my projects sizes and scopes to date. Having three dedicated time servers seems a bit extreme, unless you have a very large network. And worrying about MD5 hashes? For time? Wow... Do you work for the NSA?

For us, having multiple (i.e., redundant) time servers is not something I would consider overboard. Our police department is extremely concerned that time stamps be accurate, particularly since recorded video is often used in criminal prosecutions. We do a lot of side-by-side (synchronized) playback, too. Out-of-sync cameras were a real problem in this respect until we moved to NTP.

I'm sure there are a number of other critical surveillance applications where accuracy is important. Off the top if my head I can think of instances in manufacturing process monitoring.

Jon, lol

Poor Zeb... and yes, he might be doing things for the NSA or other very high security environments....

So then what are you using for pulse authentication? ;)

Each camera must be set to its local time zone.

That one sentence in Ethan's article is important, but one we have seen our installers regularly overlook (and another reason I now do my own configurations). The wrong time zone setting at the camera level makes syncronous playback near impossible even if NTP servers are used.

For instance, take that time we had a camera installed that only had European time zones in its firmware . . . That was when we learned that the local camera setting overrode the server's. I won't tell you how long it took to figure out the camera had European firmware, but it wasn't quickly.

"IPVM recommends checking with your preferred VMS supplier on their approach"

So what would you recommend as the solution that is both preferred and the one that most VMS manufacturers would provide in a new system with about 1500 IP Cams?

Time sync in cameras in mission critical systems is a delicate matter. Let´s say you have all your servers and cams connected to a single NTP server. You VMS does the time stamping on received frames. Now what happens if a camera goes forward 10 seconds and during the next sync that gets corrected. The next video the VMS receives is stamped 10 seconds earlier. Some video gets overwritten, evidence can be lost, a crime scene omitted.

Thoughts ?

If a device were kept up to date, usually the clock will then be updated by miliseconds. The initial time sync may be large, but then from then on it should be very small incremental updates that really shouldn't affect much.

As someone else mentioned, the clock on the camera usually won't matter to the VMS recording. It is only an issue for SD card recording if it were then brought back later and inserted to a VMS.

Correction on my previous comment, as the time stamp is written by the VMS (in our client´s case), nothing happens but the camera´s stream is affected at the instant the sync takes place, dropping a few frames, we noticed that on Axis P1344 cams both in live view and the recorded video. The customer requested to only keep the VMS´s stay in sync with NTP, regardless of the actual time on the camera.

Not sure what would happen if the time stamp on the frames was written by the camera and then streamed or recorded on its own SD Card, food for thought..

Samsung NVRs and recording software have an "Overlap" function. So during recording, if there were to be duplicate time stamps due to DST change, NTP time change, etc., it never overwrites, until the drive is full. During playback, there is a drop down selection that you can choose which video stream to play in case of an overlap... Snapshot below.

Ethan, only thing missing from your article is how to get the clients to care. We spent years installing for a major gas station chain who insisted that their systems never be connected to any network, and had no interest in any other sort of time-sync system (GPS, etc.)... unfortunately it was the individual retailers who suffered with having to figure out how far the DVR was off their point-of-sale systems' time, while corporate was resposible for policy and not caring enough to do anything about it.

"Ethan, only thing missing from your article is how to get the clients to care."

That's funny. Let's say that aspect was beyond the scope of the post :)

It's certainly a good point, some users don't care and some may legitimately not have a problem with it.

In your example, I'd emphasize the additional investigation time and cost dealing with out of synch video and PoS data plus a decrease in ability to solve shrink / internal theft issues. If that cost / loss was higher than the cost to time synch their systems, make the case that it is worth implementing it.

...make the case that it is worth implementing it.

We tried that, many time. Corporate AND retailers would simply write off such "minor" incidences... the former because they were "minor", the latter because they'd long since learned their hands were tied in doing anything about it. They'd often be frustrated by it, but realized they were powerless to change it.

The only time I recall it becoming an issue was the time a (fairly) major lottery scam was discovered, and the lottery people ran an investigation... I spent about an hour with him, printing lotto slips, then comparing the timestamp on those to the timestamp on the video when he printed them, so he'd have an offset accurate to the second... then I had to write up a statement detailing how much the time was off by, what we'd done to determine this, and explaining WHY it was wrong by so much (just shy of an hour and a half, as I recall).

But since the lotto terminals are a separate entity, and the scam really didn't affect the station's bottom line at all, nobody there really cared about that either.

Hi Ethan, do you know if any NVRs offer a private time server feature? This could be useful if a VMS server is not being used.

Do you know of any private time servers for Mac OS X. While private time server applications are commonplace on Windows, I have not yet found one for Mac OS X. However given Macs already sync with external time servers by default, I wonder if there is some way to have a Mac act as a private time server?

Thank you for your help.

How does Avigilon Time Sync?

For our Avigilon implementation, our cameras are on a private VLAN. We point our NVRs to sync with our dedicated NTP server, which is in turn synced with an official external NTP source.

The individual Avigilon cameras can, for the most part, be set to get the device time from either of three sources: NVR (when connected to Avigilon ACC server), DHCP, static NTP setting. Some of the older Avigilon devices (e.g., JPEG2000 panoramic) do not appear to support this flexibility.

And as others have pointed out, but sure the time zone settings are correct. The camera time zone setting overrides.

Stamping on Arrival

Stamping on arrival is exactly what it sounds like, with the VMS marking the time it receives each frame of video. This avoids issues caused by camera time being inaccurate, as the server is the sole source of time. In very large systems, or systems with high latency, it may take longer for frames from one camera to arrive than frames from another camera, which will cause video to be out of sync. However, this is rarely a practical concern, as time differences are very small (<1 second) and these issues are not common.

Actually, if you just timestamp frame under arrival, taking into account that network jittering even in local networks can be hundreds of milliseconds it would create big inconvenience while playing back. 30 fps video timestamped this way would look not smooth.

For that reason, I believe VMSes use a bit more advanced technique(at least Nx does for sure):
1) first received frame VMS timestamps as "now" and memorizes the timestamp of the camera ( these frame stamps could be recieved in RTCP and/or RTP)

2) the following frames are stamped based on camera time stamps( again received with RTCP and/or RTP) making an adjustment on time difference between camera and server.

So to avoid any network jittering issues( which do happen a lot even on good local networks) VMS stamps frames using "camera time"( at the moment frame was sent, not received) adding the difference between camera time and server time.

3) lastly, time on camera time goes faster or slower than server time, so the difference is increasing or decreasing over time. So after a while( after a certain change in the "difference)" VMS resynch and does step 1 again.

Good article, I actually needed a solution for non 'Net connected networks and most stand alone GPS NTP network servers are pricey.

If anyone is interested, I built a network GPS NTP server for under $100 using off the shelf parts running on a RPI. It works great, can be powered from a USB port if needed and gets its time via GPS so it is always accurate.

Again, this was a particular need for a particular customer - but it's a cheap solution if you need it.

I am interested

how do I get hold of you?

Thanks

Hey John, can I share my e-mail address here? Not sure if that's allowed or not.

Yes, that's fine.

Btw, people can also use the letter icon next to your name to send a direct message via email to you.

There is also the Time Machines TM1000A, which is about half the price of the Veracity (~$300). It's a much more palatable price compared to DIY. $100 to DIY vs. $600 for Veracity might be worth it; $100 vs $300 for TM is likely in the range of possibility considering tech labor to install/config the Raspberry Pi.

Thanks!

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

History of Video Surveillance on Jul 19, 2019
The video surveillance market has changed significantly since 2000, going from VCRs to emerging into an AI cloud era.  The goal of this history...
New GDPR Guidelines for Video Surveillance Examined on Jul 18, 2019
The highest-level EU data protection authority has issued a new series of provisional video surveillance guidelines. While GDPR has been in...
HD Analog vs IP Guide on Jul 16, 2019
For years, HD resolution and single cable signal/power were IP camera advantages, with analog cameras limited to much lower resolution and...
ZeroEyes Gun Detection Startup on Jul 16, 2019
A gun detection video analytics startup, ZeroEyes, is being led by a group of 6 former Navy SEALs, aiming to "save lives" by using AI to assist...
Vivotek Trend Micro Cyber Security Camera App Tested on Jul 15, 2019
Vivotek and Trend Micro are claiming five million blocked attacks on IP cameras, with their jointly developed app for Vivotek cameras. This new...
Axis ARTPEC-7 P1375-E Camera Tested on Jul 12, 2019
Axis claims the new P1375-E box camera with ARTPEC-7 chip delivers "clear, sharp images in any lighting condition." But how well does it do? We...
Lens Focal Length Tutorial on Jul 10, 2019
3mm, 6mm, 2.8 - 9mm, 5 - 50mm, etc. Camera specifications often list lens lengths but what do they mean? These metrics are important in...
Poor OSDP Usage Statistics 2019 on Jul 09, 2019
OSDP certainly offers advantages over decades-old Wiegand (see our OSDP Access Control Guide) but new IPVM statistics show that usage of OSDP, even...
First Video Surveillance GDPR Fine In France on Jul 08, 2019
The French government has imposed a sizeable fine on a small business for violating the GDPR after it constantly filmed employees without informing...
Network Optix / Hanwha Cloud Access Tested on Jul 02, 2019
Remote cloud access is becoming a bigger differentiator, as cybersecurity issues underscore the problems of port forwarding and many integrators...

Most Recent Industry Reports

History of Video Surveillance on Jul 19, 2019
The video surveillance market has changed significantly since 2000, going from VCRs to emerging into an AI cloud era.  The goal of this history...
Mobile Access Usage Statistics 2019 on Jul 18, 2019
The ability to use mobile phones as access credentials is one of the biggest trends in a market that historically has been slow in adopting new...
New GDPR Guidelines for Video Surveillance Examined on Jul 18, 2019
The highest-level EU data protection authority has issued a new series of provisional video surveillance guidelines. While GDPR has been in...
Wyze AI Analytics Tested - Beats Axis and Hikvision on Jul 17, 2019
$20 camera disruptor Wyze has released free person detection deep learning analytics to all of their users, claiming users will "Only get notified...
Anyvision Aims For 2022 Revenue of $1 Billion on Jul 17, 2019
Only 3 video surveillance manufacturers do a billion dollars or more in annual revenue - Hikvision, Dahua, and Axis. Now, Anyvision plans to join...
HD Analog vs IP Guide on Jul 16, 2019
For years, HD resolution and single cable signal/power were IP camera advantages, with analog cameras limited to much lower resolution and...
How To Troubleshoot Wiegand Reader Problems - Inverted Wiring on Jul 16, 2019
Wiegand is the dominant method of connecting access readers, but problems can arise for installers. In fact, one of the most difficult reader...
ZeroEyes Gun Detection Startup on Jul 16, 2019
A gun detection video analytics startup, ZeroEyes, is being led by a group of 6 former Navy SEALs, aiming to "save lives" by using AI to assist...
Motorola Acquires Watchguard, Adds to Vigilant And Avigilon on Jul 15, 2019
2 years ago, Motorola had no position nor relevancy to video surveillance. Now, they own major video surveillance, LPR and body camera providers...
Hikvision Global News Reports Directory on Jul 15, 2019
Hikvision has received the most global news reporting of any video surveillance company, ever, ranging from the WSJ, the Financial Times, Reuters,...

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