Computer spec required to remote view 16 cameras from one PC

Hi Guys,

I joined this site to seek advise as i can't seem to find specific information from google.

What i would like to know is what kind of computer spec am i looking for that is suitable to view 16x cameras from 4 different sites remotely (VPN)? We have the bandwith to stream the data but the computer harware is letting the side down, it appears so anyway. viewin 6 cams in full screen mode boosts CPU resources right upto 100%

The viewing software recommended is Remote Agent64u but this causes some problems whilst viewing only 6 cameras (2 different sites)

The software runs fine and we can see 6 cams but when we put this onto full screen mode the program terminates unexpectedly under WInXP and WIN7.

I have test tried this on a server computer with a powerfull computer and it didnt drop off but it would be interesting to know a system spec without folking out loads of money. I can appreciate that a descent graphic card is essential.

The computer with the problem is only a Celeron CPU 2 Gig Ram and onboard graphics. The cameras are monitored remotely over VPN.

Thanks for any advice /help

Regards

Wayne

I can't dead on say because I'm typically using pricey servers but if I were looking to build a standard pc for this application, I would go with a quad core 64 bit system with at least 4 gigs of ram.

Thanks for your reply, appreciated.

I have recently been using a M2M VPN solution that works very well for NVR deployment across multiple private networks. This solution runs well on performance limited clients and delivers live / playback video from geographically separate NVR - DVR networks to a single client screen. No need to run multiple clients on the same computer or switch server connections within the client to access video from different private nets.

This solution is contingent on the following "must have" requirements and does not presently (practically) support devices with ARM processors.

VMS Requirements:

Your Video Management Software must provide an NVR proxy server of some type, usually called a Central Management Server (CMS) or in my case an Enterprise Controller.

Your NVR server to client communications needs strong adaptive rate characteristics.

Your VMS client software should allow graphics hardware acceleration and be configured to use it.

You must have sufficient rights or the ability to install software to the OS of every VMS system component except cameras and embedded encoders. This means all NVR servers, NVR Proxy and Clients whether local or remote. While technically feasible for some embedded NVR/DVR brands this is likely more trouble than its worth.

Network Requirements:

Public Server. An Internet hosted virtual machine to act as an rendezvous style initialization point for M2M nodes. I pay $5.00 per month per account (customer) on Digital Ocean. (Note that no SOAP(ONVIF) or RTSP traffic crosses this server.) DDNS is also a possibility but does not seem practical for managing multiple accounts.

Machine to Machine or Peer to Peer purposed VPN software. I use Tinc VPN. (Other / traditional VPN setups like IPSEC / Cisco and OpenVPN are not a good fit for X-network VMS communications) This may also be the source of some of your performance woes.

10 + Mb/s download speed at the client(s). (Will work with less but is not as fluid.)

VMS traffic from a private network should accommodate a local VMS client connection + 4% overhead. I use IPerf and IFTop for testing.

I am not aware of anyone else using this method for video surveillance monitoring and because it works for me is no guarantee that it will work with your particular circumstances. I also acknowledge that there are other cloud managed solutions using techniques like UPD hole punching and UDT.

Unfortunately these solutions require tight integration with the VMS source code. VMS cloud providers are not especially forthcoming about the techniques they employ in the cloud for obvious reasons. What happens when a customer wants or needs to switch VMS brands ?

I chose to explore this M2M VPN method because of the inaccessible and proprietary nature of most VMS cloud service offerings. The idea of having a VMS cloud platform provider taking monthly revenue from my accounts and locking me into their platform is not appealing.

Hopefully some of this is helpful.