Experts, please help out with an IP setup.

[ak357 0]

Hmm ,

so if it's not continously streaming

how do you get Pix on screen ?

 

When the NVR server is running, it's a service on Windows, it's no displaying anything. When you run the client, clearly it has to stream at that point but you can chose to have it use a lower res stream for this purpose, but record the hi-res stream (assuming you have a camera with the dual streaming feature).

 

Common buellwinkle

even when it's service on win it still "collecting" IP streams from cameras for recording

u should know this

now are we talking about remote client or local client

or both

[buellwinkle 0]

Client can run on any machine as their program or via the browser. Seriously, its not reading the stream unless it's recording. CPU is like 5% busy, when I run the client it goes to 50% busy.

[thewireguys 3]

Buel..... Exacq is does camera side motion detection so does that mean it only streams when there is motion?

[ak357 0]

Client can run on any machine as their program or via the browser. Seriously, its not reading the stream unless it's recording. CPU is like 5% busy, when I run the client it goes to 50% busy.

 

Lets do Team viewer session and show to me plz

how your server not reading stream

[ssmith10pn 0]

Install DU meter. That will tell the tale.

[buellwinkle 0]

But you have to be a little logical. If you had six cameras, 1.2-2.0 megpixel streaming to anywhere it would take up CPU cycles, no? So as an experiment, I started 6 browser tabs on IE, CPU at 8% on a 4 core cpu. I log into each camera just using the browser and my CPU jumps and stabilizes at about 84% cpu. So in my book, 6 streams can eat up about 3/4 of my desktop. The PC running the NVR software has the very same 6 cameras, recording 24/7, yet it's CPU utilization is about 10% and it's half the processing power of my desktop with a dual core i3-540 CPU.

 

So yes, currently it is streaming all 6 cameras for recording because it's recording 24/7, but the previous version did not. So I'm using about 74Mb/sec of network bandwidth on Resource Monitor.

Edited August 24, 2012 by Guest

[ak357 0]

Install DU meter. That will tell the tale.

 

I was waiting for him to mention bandwidth meter of some type

but....

[ak357 0]

But you have to be a little logical. If you had six cameras, 1.2-2.0 megpixel streaming to anywhere it would take up CPU cycles, no? So as an experiment, I started 6 browser tabs on IE, CPU at 8% on a 4 core cpu. I log into each camera just using the browser and my CPU jumps and stabilizes at about 84% cpu. So in my book, 6 streams can eat up about 3/4 of my desktop. The PC running the NVR software has the very same 6 cameras, recording 24/7, yet it's CPU utilization is about 10% and it's half the processing power of my desktop with a dual core i3-540 CPU.

 

So yes, currently it is streaming all 6 cameras for recording because it's recording 24/7, but the previous version did not. So I'm using about 74Mb/sec of network bandwidth on Resource Monitor.

 

would you like me to show and explain this to you using TeamV ?

[thewireguys 3]

This simple turn off the client software and run a bandwidth meter. CPU usage tells us nothing.

[buellwinkle 0]

I did, see above, it showed 74Mb/s using Windows Resource Monitor but I also said the new release is recording 24/7 and can't figure out how to turn that off and just have it record events. Ate through a 1TB drive in about 5-6 days, ouch. I have a ticket open with ACTi, see what they say. Probably just operator error.

[thewireguys 3]

And I bet your going to see the same bandwidth with motion only recording.

 

You didn't anwser my question. Since Exacq does motion on the cameras does the server see bandwidth when the client is not open and there is no motion?

[ak357 0]

And I bet your going to see the same bandwidth with motion only recording.

 

You didn't answer my question. Since Exacq does motion on the cameras does the server see bandwidth when the client is not open and there is no motion?

 

Mike stop it

give him some time to digest

"Critic" need some time

[T-boner 0]

Sounds to me like you should follow buelle's advice, buy equipment on that level--but still keep the NAS on-site (it is the best way to ensure you get the footage you want, reliably), and then set up a secondary process that runs intermittently just pulling away whatever that local system has to your computer situated 50 miles away.

 

Unfortunately, that is not possible. NVR has to be away from camera location for reasons related to security (theft actually). However, tell me more about this secondary process. Is it some type of script that is executed at a certain interval and moves all data on the NVR to another location? What would be on the secondary receiving end? Another NVR?

[thewireguys 3]

Sounds to me like you should follow buelle's advice, buy equipment on that level--but still keep the NAS on-site (it is the best way to ensure you get the footage you want, reliably), and then set up a secondary process that runs intermittently just pulling away whatever that local system has to your computer situated 50 miles away.

 

Unfortunately, that is not possible. NVR has to be away from camera location for reasons related to security (theft actually). However, tell me more about this secondary process. Is it some type of script that is executed at a certain interval and moves all data on the NVR to another location? What would be on the secondary receiving end? Another NVR?

 

What about something like this? https://exacq.com/products/exacqvision_edge.html

[buellwinkle 0]

You could setup a small simple PC like a Nettop running Linux with an FTP server running. The camera FTP's to the Linux PC and you write a shell script to take the files as they come in and FTP them out to a NAS at a remote location. That way the Linux server is acting as a buffer so the camera can push the event video as quickly as possible and the Linux server can take it's time queuing up files to FTP. Wouldn't even need that much of a hard drive or memory, cheap little thing. You could also hide this somewhere, up in a drop ceiling, in the wall behind a picture, lots of possibilities.

[buellwinkle 0]

?

 

Mike stop it

give him some time to digest

"Critic" need some time

 

Actually never looked at in detail and assumed if it wasn't recording, it wasn't streaming video from the camera but I was wrong. ACTi helped me find the option to record only events (by default it records 24/7) and while it's still high, it is lower. It went from about 74Mb/s average to about 55Mb/s average, certainly not a good idea to try and push that through a 1Mb/s DSL line While live viewing from another PC, the network bandwidth went backup to the 74Mb/s number. Watching live video from the remote PC and the server PC, it went to about 106Mb/s, so about 25Mb/s per client session.

 

On the other hand, CPU dropped down to 0-2% but most of that is probably running Task Manager. That's with 4 1.3MP@10fps (1 h.264, 3 mjpeg), a 1.2MP@15fps (h.264) and a 2MP@15fps (h.264) cameras. CPU did not change at all when remote viewing the cameras on another PC. CPU on server went to about 55% when viewing live on the server PC.

[Digiscan 0]

Sounds to me like you should follow buelle's advice, buy equipment on that level--but still keep the NAS on-site (it is the best way to ensure you get the footage you want, reliably), and then set up a secondary process that runs intermittently just pulling away whatever that local system has to your computer situated 50 miles away.

 

Unfortunately, that is not possible. NVR has to be away from camera location for reasons related to security (theft actually). However, tell me more about this secondary process. Is it some type of script that is executed at a certain interval and moves all data on the NVR to another location? What would be on the secondary receiving end? Another NVR?

My thought was this: You've already exposed yourself to some level of theft with the cameras in place. My presumption is that you know they could get stolen and any other equipment onsite (e.g. router), but just don't want the case of your images of the person being stolen. That's where my idea comes in.

 

You have a NAS drive on-site. The cameras are configured to record to its internal FTP server on movement. So, all images/video you want are being recorded locally--no bandwidth or reliability issues related to internet.

 

You then have a process that is running at your house (50 miles away from the cameras) occasionally (and it could be as frequent as every minute if you wanted) polling this remote location for new files and any new files it finds it copies from the NAS at that location to your house. I'm not aware of any off the shelf software that would do this simply because I've not looked, the methodology behind it is quite simple. Alternatively if you had some NVR software installed on a cheap PC at that location, it could do something similar.

 

The main gist of all this is that the reliability of a LAN is high, so you won't lose data related to events because of a temporary outage. The software responsible for then copying the 50 miles would have better error handling built in and able to re-try if failures occur.

 

Buellwinkle describes it with far less words than I just did, but same general idea--

acting as a buffer so the camera can push the event video as quickly as possible and the Linux server can take it's time queuing up files to FTP

[ak357 0]

 

Actually never looked at in detail and assumed if it wasn't recording, it wasn't streaming video from the camera but I was wrong.

 

 

At least u admitted being wrong

I respect that

[buellwinkle 0]

Actually helped me out because I was lazy on figuring out how to turn off the 24/7 recording. To me, processor power was the #1 priority because I had this running on an Atom processor PC and worked great. Then I moved it to an i3-540 system I got cheap because an NVR company went out of business.

[thewireguys 3]

Keep in mind with the whole FTP thing your going to be looking though hundreds or thousands of folders to look at video files.

 

Also it's go that you have buffering video locally but you are still transmitting the SAME amount of data over your WAN connection so you are going to have the same issues. Just because you are storing the video locally doesn't mean that you are magically going to have less data to send of your WAN connection.

 

I think the Exacq on camera storage or something like it would be your best option

[Digiscan 0]

Also it's go that you have buffering video locally but you are still transmitting the SAME amount of data over your WAN connection so you are going to have the same issues. Just because you are storing the video locally doesn't mean that you are magically going to have less data to send of your WAN connection.

Certainly you'd need to ensure the total bandwidth can handle the average of the recorded media. If your bandwidth is only 1 mbps, though, and during an even you're recording 10 mbps, but you only do that 3 minutes out of every hour you have twice the bandwidth you need

[MaxIcon 0]

If theft resulting in loss of data (rather than hardware) is the main concern, there are a couple of ways around that, using the belt and suspenders approach.

 

I'm currently running 2 completely separate NVR systems, and also have several cams recording on their internal SD cards. This would give you 3 layers of redundancy - the internal recordings, an NVR in relatively plain sight, and an NVR well hidden. You could also copy your data files from one or both NVRs to an external drive, using something like Second Copy or by setting up a Windows script to execute at regular intervals.

 

Add in things like a UPS for the PCs and POE switch, even stacked switches, and your redundant level of redundancy is only limited by your budget and ingenuity.

 

A clever thief could figure all this out, given time and inclination, but I seriously doubt most would bother, unless you're up against the NSA or someone similar.

 

Ultimate, as thewireguys pointed out, there's no way around your bandwidth limitations except for ponying up bucks for a high bandwidth connection (assuming such is even available at your remote location). Getting all the data from your remote location to an offsite location will be an issue.

[hardwired 0]

I don't think the OP ever said if he HAD to have continuous recording to the offsite location, or if alarm triggered events would be good enough. If he wants continuous recording, bandwidth is going to be a serious issue.

 

If he can live with event/alarm recording only, something with enough buffer space to allow events to spool out to the remote location would be okay (Mobotix comes to mind in regards to buffering from onboard SD to a remote NAS-not that I'm a big fan of the Mobotix VMS, but it could be a decent choice here, easier than looking through hundreds or thousands of FTP folders).

[T-boner 0]

I don't think the OP ever said if he HAD to have continuous recording to the offsite location, or if alarm triggered events would be good enough. If he wants continuous recording, bandwidth is going to be a serious issue.

 

If he can live with event/alarm recording only, something with enough buffer space to allow events to spool out to the remote location would be okay (Mobotix comes to mind in regards to buffering from onboard SD to a remote NAS-not that I'm a big fan of the Mobotix VMS, but it could be a decent choice here, easier than looking through hundreds or thousands of FTP folders).

 

Continuous recording would have been nice but posts in this thread have made me realize that bandwidth will be an issue. Therefore i am good with motion sensing recordings only.

[thewireguys 3]

What are this cameras going to cover? Are they inside with no motion or outside covering parking lots and other areas?

 

Also another option would be VideoIQs Railto 4 channel encoder with analog cameras. With the built in storage and analytics there cameras are perfect fit for low bandwidth locations. I have installed many of their HD cameras for projects like your talking about.

Edited August 25, 2012 by Guest