GrouchoBoucho

some dvrs have an option to connect out to the manufacturer's website, then instead of logging directly into the dvr from remote, you connect to the central website, and get routed to your dvr... kind of like logmein or teamviewer. could that be what it's doing?

this. you're looking at a major installation if you want to cover this site properly, and because it's for your business, you should allot the money to do it right the first time; a half-assed diy job will only end up costing more in the long run. now, that said, there's some good but conflicting advice above. not necessarily. there are still instances where analog cameras shine. but *do* wire everything with utp (cat5e or cat6), analog or not, so cameras can be upgraded to ip later. *only* if you'll have someone monitoring them on a regular basis. a ptz on a tour is of little use, as it continually sweeps past whatever item or event of interest there may be. ptzs are rarely worth the cost unless there's a human at the other end to drive them. this is strong advice. fibre may be overkill, but you do want to break the installation into 'zones' if some runs are going to be over 300'. it's not a problem for analog, but will be for network. having the electricians pull in extra runs at the same time gives you extra capacity for other things, as ilk mentions, and doesn't cost a lot more to do at the time. 300' has nothing to do with poe. *ethernet* runs on UTP are limited to 100m (330') by spec. depending on a camera's power requirements, poe will actually carry much farther than that. breaking the site into 'zones' as ilk suggests allows you to keep runs within this limitation. i'd recommend terminating in patchbays at the 'midpoints' between zones, so it's easy to switch between analog, ip, or whatever else you want to use a run for. cat5e is designed for up to gigabit speeds. 10GbE requires cat6, but i suspect the network here will be a long way off from needing that. go with cat6 if you can get a good price on it (and on its terminations), but don't think cat5e is obsolete just yet. this above all. if you have a good licensed electrician doing the cabling, he should know what to use. he'll want to make sure he has any appropriate permits as well (some jurisdictions lump it in with other low-voltage like phone and security, others require a specific cctv permit).

set your dvr's ip as a 'dmz' in the router - some dvrs require more than one port forwarded; this will help rule that out.

true, but the 'roll lines' in one of op's pictures indicates actual tape in this case.

only relevant when it comes to remote viewing, and these systems can all use a 'substream' for the remote feed, which is lower quality at lower bandwidth. the nvr still records its local cameras at full quality, it just (optionally) uses the substream for the remote viewing. main thing is to make sure you're getting actual baluns, not just 'twisted pair to bnc adapters', which seems to be happening to a lot of people lately. Edit: only *certain* cnb cams - the "mona lisa" series in particular, are great for low light. but these are analog cams; if you with an nvr system like suggested above, these won't work - you'd need either an analog system, or a hybrid to use them in conjunction with the ip cams.

you were probably looking at the 'system info' page, which shows wireless clients and dhcp clients, but not all connected devices. the 'lan' page should show everything.

neither of these are even in the same area code as "highest quality"... however, of the two, the specs on the swann are better than the q-see. that doesn't necessarily make it better overall...

it's a little over budget, but it's possible to get into a dahua-made 4-camera high-def setup (four 1080p ip cameras and 16-channel nvr) for around $1500, all in (cables, switch, etc). that's where you ask yourself if it's worth spending a little more to get the higher resolution and (plenty of) future expandability. i know dahua has a four-channel nvr with built-in poe switch coming out soon, that will simplify installation even further. no idea what the price point will be yet. the nice thing with the dahua setup (and others, but this is what i'm familiar with), since you have multiple locations, is the ability to configure them all in the one remote client interface so you can easily view, search, and playback all cameras from all sites in one place. the one thing missing is that we don't know where you are... so we can't suggest any local suppliers, or even online suppliers. if you're in the uk, there's no point suggesting any australian vendors, for example.

*sigh*

vhs spec, if memory serves, is 220-240 lines at 'sp' speed (2 hours on a t-120 tape). on a time-lapse machine (24 or more hours per tape - i've seen machines that will do up to 192 hours on a t-160 tape) it's substantially less. you're lucky if each camera's effective resolution is qcif (160x120).

true. as op notes, it's not always a matter of the evidence being 100% perfect, but about the *relative* reliability and veracity of the evidence. i had to provide a statement once on a fraud case, where stolen credit cards were used to for a large lottery purchase at a store. the timestamp was off, so i went in with the lottery rep, he did some test prints on the lotto terminal, and we compared those timestamps to the dvr to determine the delta. he then had me write a statement laying out the procedure and concluding with my 'professional opinion' on the actual time offset and the reason(s) for it. i assume that if it ever got to prosecution, my written statement was sufficient, since i was never called on to testify.

you're preaching to the proverbial choir, but as you also realize, all these things can get quite expensive. as professionals, we can offer all these solutions to our customers, but at the end of the day, it's up to them what gets implemented. your 'innocent man' scenario is probably not enough to convince them, though - 99% of the time, the only thing on the line is their own money, and even that is rarely enough to get them to spend an extra $50 for more storage, or $100 for a gps time-base receiver to make sure everything stays sync'd. heck, i have customers that are a major chain of retail outlets that could have time sync by simply plugging their dvrs into their existing network, and they refuse to allow it. btw, 'open source file formats' are generally incompatible with 'unimpeachable evidence' since, afaik, there are no open source video codecs designed specifically with surveillance in mind, with things like embedded timecode and authenticity verification.

^rip-off alert!!! that $270 "hi-res lcd mobile video display"... is this haier 10" lcd: http://www.amazon.com/Haier-HLT10-10-2-Inch-Handheld-Black/dp/B001OXKPDO/ref=cm_cr_pr_product_top it's discontinued now, but it used to sell for under $100. just found two of them on kijiji for $60 each. that, folks, is some ballsy marketing.

this, by the way, is entirely possible - i've seen both analog (vcr) and high-end dvr/nvr systems that have had the time drift off, or even never had it set properly at installation. i had muxes, back in the day, that i'd set the time, and they'd be off by an hour within a month. vcr/mux systems would be much more rare in 2009, but certainly not unheard-of.

this is *highly* consistent with a time-lapse vcr playing back through a multiplexer, where video frames are written sequentially to the tape - save a frame from the first channel, then the next, then the next, and so on, then cycle back and save another frame from the first, and so on. and so, playback reverses this process. if you play a time-lapse tape back in a standard vcr, you just get a video that's constantly flipping from camera to camera; the multiplexer generates this sequence and sends it to the vcr to record, and then on playback, "de-sequences" them back to their individual channels. this is somewhat over-simplified, but you get the idea. actually, this is also common with vcrs - a slight wrinkle or crease in the tape, a little dirt on a video head, anything that can interrupt playback of that segment of the video stripe. as noted: everything in this posts fairly screams time-lapse vcr. so at one time, it certainly was common. vcrs were still widely used in 2006, as this is well before digital surveillance recording was economically feasible for most. this, coupled with the fact the original file the police had was in a readily-playable format, supports the idea that someone hooked the output of the multiplexer into a capture device on their computer (i was using an ati all-in-wonder display/tuner card in my pc well before 2006, to record tv shows and "rip" video tapes), and recorded it to a standard multimedia file.

pretty much what I figured. a clip of the video itself might help determine the cause of the 'stuttering' issue - time-lapse tape playback has a pretty unique look. two possibilities: the mux or quad didn't provide that option, or (more likely) the operator didn't really know what he was doing.

^it's none of the above. the attached image is a still frame from the dvd - it's a quad-view screen showing only one camera. all the op has is the dvd.

most of them appear to be in hiding... i love a good detective story! that's extremely uncommon, in my experience - frankly, i can't recall ever seeing a system that exported video that way. it's possible it may have been recorded during playback by a screen recorder program, or by feeding the dvr's monitor output to another capture device (come to think of it, this seems more likely). either way, i suspect it's not a direct export from the dvr. that sounds quite plausible as well. a client app with a poor network connection could certainly account for it - the timestamp might be generated by the client along with the quad view, while it's receiving a 'stuttering' stream from the dvr. it's also possible that if the monitor output of the dvr was being recorded by another capture device, and that device was on too slow a system, that that system wasn't able to record it smoothly... although that would likely show as 'skips' in the timestamp at some point or another. again, it doesn't sound like this is an original export from the dvr itself. unfortunately it also leaves no way to authenticate either the time of the event, or the veracity of the footage itself... meaning it's highly unlikely this clip would stand up as evidence in court. don't know whether that helps or hurts you (sounds like probably the latter), but there it is. i wouldn't even begin to hazard a guess. it looks like a generic multiplexed display - it could be from almost any dvr's monitor output, it could conceivably even be from a vcr playing back through a quad or multiplexer - there's frankly nothing there to prove otherwise. anything computer-based. iirc usb export would have been rare on standalone units then, as usb storage was still pretty expensive. cd-r export would have been more common, not even dvd-r (still pretty expensive). if the original scene was recorded on a standalone (or even vcr) it could have been captured via the monitor output, into a pc capture device (tv tuner card, perhaps?) - that would definitely be more likely to produce a 'generic' computer-playable file format. internet, yes, usually with remote client software... smartphone, no, considering 2008 was when the iphone 3g was first released and this was still pretty new stuff (and data plans were a lot more expensive). put it all together, i'd bet dollars to donuts what you've got is a basic recording device (standalone dvr or even vcr), feeding the quad output through the monitor jack, into a pc capture device (most likely tv tuner card) on an under-powered pc, and that recording finally exported to usb for the police.

this is a diagram for a tv antenna balun (converting between coax and the old 300 ohm twin-lead antenna wire)... but other than maybe a couple ceramic caps for filters, video baluns are pretty much the same internally:

reading that description hurt my brain...

they look like this?

are you *sure*? you'd be surprised what can be going on behind the scenes on your network. does your router have traffic graphs or even logging? how many devices are on your network in total?

remember that that upload speed is being used by everything else on your network. if you have torrents running, they're probably using a good portion of that. if you run something like a slingbox, that will use most of your upstream while it's being viewed.

Thanks for the reply. They are all powered from seperate supplies, 12 volt 1amp switch modes "wall warts" I have a stack of 12 volt alarm batteries, I will try running the cameras on them and see if it makes any difference. i'll bet it won't. using separate supplies breaks the most common ground loop problem (although there my be other types of ground loops that aren't power-related). this is important to note: only use one pair for video; otherwise you lose the noise-rejection properties of the twisted pair. that's fine as long as you have decent (ideally dual-voltage) cameras, but can create ground-loop problems with cheap cameras.

no, there are no inherent problems with doing this. of course, regular cat5e is only four pairs, thus a max of four cameras - you'll need two runs to do all five. Thanks in anticipation. Andrew that's quite possible. utp is usually very good at rejecting noise, and the balanced line makes it even better, but at some point the laws of physics always come into play. noise like that could come into the system anywhere - through a single camera, directly into the dvr, etc. i would suspect a ground loop but if each camera has an individual power adapter, that shouldn't be a problem.