hardwired

No, I made the assumption that the VCR was a composite input, what you have planned is fine.

You should be able to run three RG59 cables with BNC connectors at each end, and use two of them with adapters like in this photo to change from the two cables to the S-video connector, and then use the third one for the composite input on the VCR. (Google Datavideo CB-2 for an example). If you use bulk cable and put the BNC connectors on yourself, the whole thing shouldn't cost more than $40 or so.

Yes, if you can find a decent S-video cable, that should be fine. Are you planning on recording this, or just live viewing? If you think you might run a DVR later, you might want to run a standard coax cable for the composite video while you are running the S-video cable.

Hmm,I don't see any I/O on back of your DVR Yes, that's why I mentioned that it was dependent on the DVR's features- looks like he's out of luck with that DVR.

One thing to note with Milestone is that the smart client defaults to full resolution display, placing a very high load on the processor. I usually change the display resolution in the split screen view down to "High" or "Super High", rather than "Full". This also helps quite a bit when viewing remotely, as the bandwidth required is much lower.

The possibility of doing that is going to be based on what kind of DVR you are using, and whether it has inputs and outputs to allow that (most do) Usually, it's pretty straightforward, wiring the dry contact outputs from the motion sensors to inputs on the DVR, and wiring the output from the DVR to some kind of alerting device (higher power devices will usually require a relay to be added to handle the load). Then, it's a matter of programing the DVR accordingly.

Well, the S-video output is just two standard 1.0V P-P level video outputs, one carrying the Luma signal, and another carrying the Chroma, so it should work fine. (assuming you can find a decent way to break out of the S-video connector to connect to the coax). Do make sure that you use pure copper core coaxial cable with copper braid shielding, (ideally 95% braid coverage), and keep both cables as close to the same length as possible. The most commonly found RG6 or RG59 is usually for cable TV or satellite use, and has a copper covered steel core, with foil shielding. This type of cable is unsuitable for carrying low frequency (baseband) video.

There are a number of different S-video over CAT5 adapters available, here's one- http://www.muxlab.com/assets/files/datasheets/VE_S-Video_Balun.pdf The idea of a balun of this type is to allow correct impedance matching for the signal over twisted pair cable, and the balanced signal path over twisted pair cable makes shielding (usually) unnecessary.

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).

Keep in mind that if you want to use NVR software in a normal fashion, that usually means transferring data via TCP or UDP packets, not FTP. That means that if you want to transfer more than one camera over your WAN link, you will either need to be able to discriminate between two (or more) different cameras originating from the same IP, which means that the NVR software will need to be able to be set to use the same IP, for the cameras, just different ports (not sure if Acti S/W can do this, I think Milestone can). You will also most likely need either static IP addresses at both ends, or DDNS resolved hostnames on a dynamic IP connection. You could also link sites with a VPN tunnel, but packet fragmentation because of tunnel overhead+payload size going above MTU limits (plus the overhead of the tunnel encapsulation itself) will reduce throughput substantially. Your best bet if you really want to try this is to establish your internet connection at both ends, and set up computers at both ends with bandwidth testing software (JPERF, or something comparable), and test what speeds and reliability that your connection can provide (using similar packet sizes and types that your cameras will output-probably pretty large UDP packets) before you proceed further. You may find that your sustained throughput capability is not anywhere as large as you might think from casual short tests, and occasional interruptions of data flow can often cause long dropouts of recording (I know Exacq can take 5-10 minutes or longer to reconnect to a camera after an interruption).

If you have to get through any amount of foliage, stay in the 2.4GHz band, unless there's a huge amount of obstructions, in which case you might need 900 MHz gear. I would try Ubiquiti NanoStation M2's, I've had pretty good luck going using those through a reasonable amount of foliage at those distances.

What resolution and frame rate are you planning to get, and what is the rated upload and download speed at each end (and have you tested it?). And, what is your ISP's monthly data limit?

The short answer is that trying to transfer that much data, at a high enough speed, is going to be impractical with any standard internet connection method (depending on the frame rate and resolution of the cameras you are planning on using, your upload speed would need to be 2Mbps or higher, and at that rate you will massively exceed most ISP's monthly data transfer limits). With dedicated internet connections this could be possible, but even for a T1 data rate connection (1.544 Mbps), you are probably looking at at least $400 per month, for each end! A far better plan is to figure out low to locate a low power NVR at the camera site, or use cameras such as VideoIQ's or others that have onboard storage, and can transmit only during alarm events.

Full frame decoding, especially H.264, tends to put a pretty heavy load on the video processing. As Soundy mentioned, NVR software that uses camera side motion detection can be very light on processor resources, but displaying that video is another story. I would suggest trying a better video card in the client, and in a non-VM environment, GPU virtualization is still a little sketchy.

On the open ocean, it's only going to be satellite service, a rough estimate for Inmarsat data service is about $15,000 USD for the equipment, and about $7.00 USD per MB of data, or about $17.00 USD per minute of streaming data at 256Kbps.... Pretty darn expensive, you have to decide if what you are trying to accomplish is worth that cost. Also, a lot of equipment will not play nicely with satcom, due to the high latency, and "tricks" that satcom data services utilize to increase capability (I.E. packetizing large data chunks and spoofing syn/ack packets to allow better streaming and less retransmissions).

Does the estate own the phone line cable on the premises? If so, you could look into VDSL2+ converters on the existing phone cabling, you might need to repeat at one or two midpoints, though (or possibly using existing cable TV wiring, with a DOCSIS modem network). NLOS 900 MHz gear is pretty limited in bandwidth, you might take a look at Motorola (now Cambium) Canopy equipment, but you may not be able to get enough bandwidth to make it work. You may want to look into how you can find some midpoints between cameras and the headend to make 2.4 or 5.8 LOS wireless gear work with short towers (I've found that Ubiquiti 2.4GHz equipment is able to penetrate a reasonable amount of foliage at short distances, but it's by no means guaranteed). Alternatively, you may want to look at cameras with edge recording capability (or small NVR's), to allow you to transmit a low quality, low bandwidth live signal, but able to retrieve high quality video when necessary.

Milestone Essential supports up to 26 cameras, at $49 USD per channel MSRP, and works pretty well, overall. You may want to factor in maintenance costs, though, they aren't required for the software to continue operating, but if you want future upgrades, you need a current maintenance contract. Avigilon provides upgrades for free, and is really nice, but also has a higher initial cost.

And what will happen if neighbor walk again ? You'll have a confused garage door? LOL! I've got the answer for both of you! A N/C alarm contact on the door connected to ground and the trigger input on my layout, so once the door is closed, it holds the input low and will not let any more triggers from the camera operate the door again.

Yes, you would connect the ground from the camera to the ground of the relay module. You will not use the 3.3 volt output from the camera. The output on pin 4 acts as a switch that connects to ground (pin 1) when triggered. So, what happens is, with the input tied to the +12 volt supply through the 2000 ohm resistor, and the output (switch) of the camera is not triggered, the input of the relay is raised to +12 volts through the resistor. When the switch closes, the current through the switch (the resistor limits the current to a very small amount, about 6 Milliamps, well within the tolerance of the camera) pulls the input down to ground on the relay. That's why I mentioned setting DIP switch #4 on, so "Timing starts after removal of trigger input", so the operation of the relay triggers when the voltage on it's input goes low (to ground).

That looks nice. But it says in the link below that the trigger voltage range is 7-12 volts, and I'm working with 3.3 volts http://www.altronix.com/products/installation_instructions/6062.pdf The link you posted earlier to the other relay says it will trigger down to 3volts. Wonder if they have an ultra sensitive one like that with the features of the second relay you posted? Now I had to go read the manual for your camera! Page 20 has the pertinent information, which is that it is an open-collector type output (actually an open drain N-channel MOSFET, but I digress). In your application, you would not use the 3.3 volt supplied by the camera. You would tie pin 1(ground) from the camera to ground on the timer module, and tie pin 4 (Digital Output) to the trigger input on the input of the relay module, and follow line 5 of the install manual for the timer, where you would use a 2000 Ohm resistor between the trigger input and the +12 volt supply, to keep the input pulled up to a high level when the camera's output is not triggered. Then turn DIP switch #4 on, so "Timing starts after removal of trigger input".

If you can't get a short trigger from Exacq, use this Altronix timer relay instead, in "one shot" mode. http://www.altronix.com/products/product.php?name=6062

You can use this Altronix relay to change the low level digital outputs from the camera to a dry relay contact suitable to connect to the garage door control. http://www.altronix.com/products/product.php?name=RBSNTTL

You might want to check with Exacq support, they show that encoder on their supported list, with PTZ control. Another choice would be Acti's free NVR software, I tried their newest version and it doesn't suck anywhere near as badly as their older versions.

There aren't any controls on the web interface of the encoder itself, it just passes through control data generated by your NVR application. I have a setup using the ACD-2100, same lack of interface on the web page, but it passes PTZ data from Milestone just fine, once you configure the protocol and baud rate settings in Milestone. The same setup also uses a ACD-3100 decoder to provide an analog viewing station, and has a Pelco KBD300A keyboard connected to the decoder that controls the same PTZ through the encoder.

Multicast IP's are not routable on typical WAN connections (ie. users connecting through their ISP). If users are all able to connect via a local network, multicasting can indeed reduce bandwidth, but you do also need a VMS that supports it. Milestone Corporate, and presumably it's ONSSI equivalent do, and I think Genetec may, but I do not think that Exacq does.