Hi!
I am looking into setting up 4 cameras at 2 different locations with one server. Would I have to do something special for bandwidth purposes? How much bandwidth would 4 cameras running at 320x240 with 5fps consume over the ADSL? Would I be able to use another applications over the ADSL line?
How powerful should the server be for these 8 cameras? How much memory do you recommend?
With best regards,
Casall
ZM over ADSL
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
5 fps * 4 is 20 fps, at an image size of say 20K thats 400K a second, so if you have 4 megs upstream then yes it will work as long as your on a 1:1 contention link, real world no it wont mate, 5 fps total will be a miricle over a 256-512 kb/s link upstream
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
-
- Posts: 20
- Joined: Fri Jun 15, 2007 9:46 pm
Need more details to help...
I think that more detail we have on what you are trying to accomplish, the more as a group we can help.
If the two locations are diverse, then maybe 3 smallish servers could work: two baby servers (just enough to capture 2 cameras x 5fps at each site) and an "aggregation" server centrally located. Each remote server would capture and FTP to the central point when something interesting happened (assuming you only want to know when events happen.) I am looking into this scenario for a small business I may be establishing soon.
Here, the bandwidth availability could be lowered... each server would capture locally, and then FTP upwards *offline* (that is, not in real time.) As long as real-time was not mandatory, and near-real time would solve the problem, it may be a viable solution.
There are a lot of mini-pc solutions out there... the processing power for 2 cameras at each of two locations would not be that huge at all... and memory is getting rather cheap these days!
Hope that this helps... more requirements expressed = better chance for on-target design!
If the two locations are diverse, then maybe 3 smallish servers could work: two baby servers (just enough to capture 2 cameras x 5fps at each site) and an "aggregation" server centrally located. Each remote server would capture and FTP to the central point when something interesting happened (assuming you only want to know when events happen.) I am looking into this scenario for a small business I may be establishing soon.
Here, the bandwidth availability could be lowered... each server would capture locally, and then FTP upwards *offline* (that is, not in real time.) As long as real-time was not mandatory, and near-real time would solve the problem, it may be a viable solution.
There are a lot of mini-pc solutions out there... the processing power for 2 cameras at each of two locations would not be that huge at all... and memory is getting rather cheap these days!
Hope that this helps... more requirements expressed = better chance for on-target design!
If QOS is deployed at the remote sites, would continous stream still recommended assuming I only adequate fps? I have a similiar scenario where I need to monitor and record multiple remote sites.
From the looks of it, it maybe safer to do mini servers at remote site.
a side note, I would like to have the remote mni servers backup to the main server over internet during the night. Does ZM have such feature?
From the looks of it, it maybe safer to do mini servers at remote site.
a side note, I would like to have the remote mni servers backup to the main server over internet during the night. Does ZM have such feature?
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
In a nutshell no
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Yeah that was my concern. I still have to deal with the data traffic which cannot be interrupted by the video streaming. With that said, this is an reason to have mpeg-4 support. In situations like this, I rather have the lower quality and not have to sacrifice on the bandwidth.
Can you have mulitple DVR's talk to each other. e.g. the main DVR looks at the recordings from the remote dvr when it needs to rather than have an IP camera directly upload the stream to the main DVR?
Can you have mulitple DVR's talk to each other. e.g. the main DVR looks at the recordings from the remote dvr when it needs to rather than have an IP camera directly upload the stream to the main DVR?
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
no you cant upload like that
You would need to create the db entries for the sync. Maybe a way would be to use vpn and use the sql of the master server and rsync the images but id suggest it would be far from reliable.
The other way would be to use the salve machine to record its own footage and then have monitors on the master running at low framereate feeding from your slave box, then if anything happens having to login seperatly to the slave. ie set your qualitty very low on the link.
Other than that zm4ms can link together multiple servers but would still get the images from the slave
You would need to create the db entries for the sync. Maybe a way would be to use vpn and use the sql of the master server and rsync the images but id suggest it would be far from reliable.
The other way would be to use the salve machine to record its own footage and then have monitors on the master running at low framereate feeding from your slave box, then if anything happens having to login seperatly to the slave. ie set your qualitty very low on the link.
Other than that zm4ms can link together multiple servers but would still get the images from the slave
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk