Soundy

Erm, that was a little hard to follow, but...

First, you only need DDNS if the customer is on a dynamic IP. If their connection has a static IP, you can simply access it by using that address in the remote client. As often as possible, I insist my customers get a static IP from their ISP (most have it as a cost-added option), because it simply eliminates the problem rather than attempting to work around it.

If that's NOT an option, you have a few others. If your DVR supports a proprietary DDNS service (webdvr, etc.), just use that; the router should have no effect on its operation. It sounds like this what you're trying to do.

A DDNS (Dynamic Domain Name System) service is nothing more than a directory service, and your DDNS client, whether on the DVR or the router, just updates the listing when the IP changes. You could in theory have the same address listed with two or three different services (mydvr.webdvr.com, mydvr.dyndns.com, etc. etc.).

And IF it comes to needing a new router... I've bought Belkin routers on sale for $15, and basic D-Links go for about $30 regular retail around here. If they're too cheap for that, just buy it yourself, and add the cost into your service call (tack on an extra hour or something).

The router doesn't have to support DynDNS internally; if it's a PC-based DVR, you can just run their client on the machine, or another client like DynSite, or any of a number of Javascript or PERL scripts that can update the DNS.

Personally, I have our company domain registered with EasyDNS.com, and use DynSite on customer DVRs to create hostnames under our A-record... for example, customer1.lps-cctv.com, customer2.lps-cctv.com, etc.

The best plan, however, is to tell the customer that they MUST have a static IP. Almost all ISPs provide this option, usually at an extra cost, but it eliminates the problem rather than working around it, and you won't have to worry about those panicked support calls when the IP changes unexpectedly and the DNS hasn't updated within milliseconds.

I've never seen a ROUTER block port 80 specifically (some will block ALL ports except those you open; none will automatically forward any ports you don't specify).

I HAVE had an ISP block port 80, specifically a DSL ISP on residential connections - there are more than a few of my DVRs out there running their webservers on port 8008 because of this.

As for the original poster, the question is a little vague: he doesn't say WHY he's trying to forward any ports, whether he's trying to a remote client, or access via the web, or if he even DOES want remote access (if not, no port forwarding is required).

Most routers will allow you to forward more than one port per client, so there should be no reason not to forward all three and just be done with it.

You don't mention if megapixel resolutions are required... D-Link has several WiFi-enabled cameras that provide up to 10X optical zoom, 30fps framerates, and 4CIF resolution...

http://www.dlink.ca/products/category.asp?cid=60&sec=0

Is there no display AT ALL, or just no display of the cameras, or..?? I believe the IDR 6016 is a Capture CCTV system (www.capturecctv.com), so their support may be able to help you.

One thing, you'll probably need to be sure you have the proper display driver installed for your video card or video chipset, and make sure your DirectX is updated to the latest version. In fact, make sure you have all the included motherboard drivers installed - I've had Vigil rebuilds on some new motherboards not work right until the chipset support was updated to the latest version.

It kinda depends - depends on your connection, depends on whether you have a router or firewall, depends on whether that router or firewall lets you configure port forwarding.

First thing you need to determine is how much you want to spend. Basic "commercial-grade" analog cameras are going to run you about each $250-$350 with lens; you can go cheaper, and you can go WAY more expensive, depending on your budget and your needs.

There are a number of DVR card-and-software bundles that you can use to build a system out of a PC - most decent ones will start in the $600-$1000 (minus the PC itself) range depending one how many channels you need, what sort of framerates you need, and of course, the overall quality of both hardware and software. We use Video Insight's packages, they work quite well - check them out at http://www.video-insight.com

You can go a lot cheaper by getting a standalone system - basically a unit that looks like a VCR/DVD unit and records to an internal hard drive - but PC-based systems tend to be more versatile, expandable, and easier to use.

Hope that helps to get you started. It's hard to suggest much else without knowing at least what sort of budget range you're interested in - I mean, you could put together a used PC and a couple webcams for a couple hundred dollars, or get an all-inclusive DVR-and-camera package like Costco sells for around $600... but as with everything else, you get what you pay for.

Software problem? Difficult to say. Once again, I'm just guessing based on experience with different software. A corrupted database table is just one possible reason, IF your software works this way, and IF it is still in fact recording video. IF that is the case, it would be a matter of running a repair script on the database, or possibly a utility that rebuilds the database from the video data (this is what the Vigil does).

But these are all VERY BIG "IFs". I'm just trying to give you an idea of somewhere to look as a starting point - IF you discover that there is no recorded video files for those cameras, then everything I've suggested so far goes out the window.

Without the ability to sit down in front of your system, troubleshooting this way becomes a very precise process that has to be done one step at a time.

So yeah, you've paraphrased it pretty closely. To be more precise, someone is bringing you new golf clubs and stashing them in various places around your house, but not telling you where they are

Now as I said off the top, I know nothing about the Netsafe system or whether it works this way; however, problem sounds similar to database-related problems I've had on other systems, so I'm taking a wild yet educated guess that it might be something similar.

So why only two cameras? Well, let's assume for a moment that it is a problem like this - it could be because of the way the software uses the database. For example, if it's using a separate table for each camera, and the tables for those two cameras are corrupted, it could affect ONLY those two.

The first thing I'd suggest checking (I think I mentioned it already, not sure) is the data drive, where the system places its video files, and see if there's actually recorded footage for the "missing" cameras.

On the VideoInsight system, for example, you define a folder for the video storage (d:\video, perhaps), and the software creates a folder for each camera inside that (d:\video\cam1, etc.). In each camera folder, it creates a folder named for the date (d:\video\cam1\19aug08 or something along those lines). Then it starts a new video file, named for the time it was created (d:\video\cam1\19aug08\102352p.avi), and keep recording to that file until it hits the maximum size you designate (I usually tell it to max out files at 50MB), at which time it will start a new file.

The Vigil system creates a Data folder on the drive or drives you configure (d:\Data), then creates a folder for the date (d:\Data\20080819), and inside there creates a folder as each hour of the day progresses (d:\Data\20080819\00 for the hour between midnight and 1am, \01 for 1am to 2am, and so on up to \23). Inside each hour folder it creates its files, a new one every minute, named xxyyzz.mjp, where xx is the camera number, yy is the minute, and zz is the second. So to see what camera 3 recorded between 11:05am and 11:06am on the 15th of July, you'd look at d:\Data\20080715\11\030500.mjp (most of them, the seconds are 00, but some vary - I have no idea what the criteria is).

Anyway, this long-winded diatribe gives you an example or two of what to look for: find the folder where your system stores its data (should be in the settings/options somewhere), and look for folders and/or files with names indicating dates, times, and/or camera names/numbers, to see if those cameras are in fact recording video. This will, of course, depend on the Netsafe storing video in discrete files in a manner like this - not all systems use this method, so again, this is just a suggestion.

Just a correction (I musta been half-asleep when I wrote that), Vigil's AZTECH codec is based on Motion-JPEG, not H.264. The files created are all .MJP extensions.

Well to oversimplify somewhat, with the aforementioned systems, two processes are happening during recording: one, the video itself is being written to the hard drive in files; two, a database is updated with searchable information on the video - when motion was triggered, what timeframe is covered in what files, etc.

When you want to look at recorded video, the system looks at the database for the time(s) you want, and then calls up the appropriate file(s). Now in some instances, the video is being written to its files, but the database isn't being updated to tell the software which files are which, so that when you go into Search, the software finds no entries in the database, and so doesn't know that there's video to match.

In the case of this particular Vigil, a corruption in the database (caused by a failing hard drive) meant that it wasn't being updated, but since the video was recorded to a separate drive, the video files were still being written... the Search function just didn't know they were there.

You make some good points here... I'll add a couple of comments.

Almost all cards that capture analog video (your standard composite camera) will do so at either CIF, 2CIF or 4CIF which relates to the image size in pixels. 4CIF is the highest resolution typically offered which is 704 pixels wide and 576 pixels tall. This is a pretty good size picture but if you relate it to your computers resolution it's probably a little smaller if you run at say 1024 X 768 which these days is considered lower resolution for a computer monitor.

 

If you relate 4CIF in terms of megapixel, that equates to 704 X 576 = 405k pixels which is less than half a megapixel.

 

But if your looking for high-res with an analog camera, then you are looking for 4CIF.

Another limitation of analog is the analog video signal itself. Since NTSC video has a maximum of 525 TV lines, and PAL a maximum of 625 lines, that pretty much limits the maximum possible resolution regardless of the capture card. Cheaper cameras with smaller CCDs output even fewer lines - 480, 420 and 380 TVL is common. Some higher-end cameras do 520; some of the really cheap board cameras come in <300. Regardless of what resolution you sample at, your vertical image resolution will still be limited by the capabilities of the camera itself.

H.264 and MPEG4 are both designed for 30 fps, but most security is recorded at lower frame-rates. What happens is that if you lower the frame rate to say 1fps, you have now completely eliminated these newer codecs ability to effectively reduce file size because they must capture a certain amount of keyframes regardless of the framerate.

There are a few others also in use that work well. The Vigil DVRs use an AZTECH codec, which I believe is based on H.264 but is optimized better for security recording (MPEG4 is also selectable as an option). The newer VideoInsight systems also allow (and include) Windows Media Video (WMV) 9, which in my experience works fairly well. A well-designed system will allow you to select the codec used on a per-camera basis to optimize for different viewing/recording conditions - Vigil and VideoInsight v3.x support this (VI 2.x and older don't).

Some may also allow you to use any installable codecs available - DivX, for example (which is MPEG4-based).

So, what was the point of all that? Simply that if you really want good pictures/video it really does not have much to do with the capture card. In the end the codec will kill your chances of great video, and even if you pick the best codec, it's really all in the implementation by the DVR software manufacturer because that is where the quality issue is really decided.

 

There is another flavor of analog camera compression which takes place on the capture card called hardware compression. It's really the same codec but it's done on the card instead of the processor. Companies like HikVision and others offer these for a reasonable price and they typically use H.264. And while the pictures look pretty good, it's still limited to that 4CIF resolution and marginally good codecs such as MPEG4 or H.264.

And the major drawback to hardware compression is, you're stuck with it. With software compression, the manufacturers could provide an updated codec with improved performance/quality... with hardware compression, unless the card is flashable (unlikely for cheap cards), you don't have that option.

Finally I want to talk about "REAL" quality video in the security industry and that is megapixel IP cameras.

 

Right out of the gate we are talking image resolutions of around 1.3 megapixels and heading up to 5 megapixels in routine use in the security industry. These are still compressed with MPEG4 or H.264 but you have so many pixels that the image still looks wonderful. And, it does not even require a capture card because the camera does the compressing.

 

But of course they are expensive.

It should be noted, just for completeness, that there are QIF/CIF/4CIF IP cameras available as well. Some of the same advantages apply, such as on-camera compression, no need for a capture card, and so on, but of course still with the lower resolution. They tend to be sold as webcams and consumer-grade surveillance cams; not something you'd generally want to use is a pro installation, but as I said, I'm just tossing it in there for completeness of information

So what do I recommend? Look for a hybrid solution that can handle megapixel IP cameras. For cameras where routine quality is ok, use the cheap analog cameras. For the few places where you really need that intense quality, use a megapixel IP camera.

That's what we've been doing for a while now. The Vigil systems support a mix of both analog and IP cams, so we're even retrofitting a few existing installations with IPs. VideoInsight has a separate "IP Server" module that can be installed stand-alone on a PC for an NVR system, or on one of their "Analog Video Server" systems to create a hybrid recorder. Others have their own variations on the theme; again, those are just the ones I'm familiar with.

Not being familiar with that particular system, I'll offer something based on a couple other systems I've used.

On both VideoInsight and Vigil systems that I'm familiar with, searches are done via a database maintained by the software. If the database isn't being updated or the updates aren't being read, search won't show any recorded footage, even though it IS being recorded.

I saw this several times with older versions of the VideoInsight software, where the database simply wasn't being read so the available clips weren't being displayed. Restarting the software forced it to re-read the database and the missing clips would then appear in the tree view.

On a Vigil I'm fixing right now, the database wasn't being written to with new video for about the past month, even though it was recording the whole time. Running the database rebuild utility re-scans all the video footage and recreates the database (it's underway as I type this).

So something to try is to look in the actual video folder(s) and see if the cameras in question have video clips there (and again, this is just a guess, as I have no first-hand knowledge of Netsafe systems - I know some others, like Capture, pre-generate "bank" files and then put the video within those).

I have a DVR here running 22 analog cameras on a 240fps/32-input capture card, plus five 1.3MP IP cameras. Cameras are all recording at between 3 and 7 fps.

Needless to say, this eats up a lot of space: I have 3TB internal and the thing is barely keeping three weeks of data. The client wants 90 days(!!!)

So I'm looking at a NAS RAID box of some sort... something rack-mount would be nice, but depth is limited, and all the rackmount units I've looked at so far only hold four drives... and we're looking at probably needing 8-9TB for the amount of storage they want. It would also require a new switch, as the one I have now only has two gigabit ports in addition to the 24 10/100s.

I've considered a couple of DROBO boxes as well, but I don't think the USB interface will handle the throughput I need on a sustained basis.

Anyone done something like this, and can you suggest anything for me? There's room in the bottom of the rack as well as on top of the rack for a larger box to sit, too...

How are you connecting to the PTZs? Onboard serial ports, USB-to-serial adapters, or other type of serial interface? Are you using RS-232, RS-422 or RS-485?

I've seen a problem when using RS-232, where you have to connect the camera using proper polarity with the power down, power the camera up, then reverse the polarity on the serial wires, after which it works fine. Sometimes it just works, but sometimes this trick is required.

If you're using an RS-232 to 422 converter, it shouldn't be a problem.

I've had no problems using an ATEN USB-to-Serial adapter cable. Works on both my laptops and with a variety of DVRs I've used them on. Should be available for $15-$20.

Typical CCTV lenses are set up thus:

Ring closest to the camera body is focal length (wide/tele); may also be marked with W and T.

Center "open/close" (or O and C) ring (if applicable) is manual iris.

Ring farthest from camera body, or sometimes the entire end of the ring barrel, is focus, often labeled Near and Far.

There are variations, of course... a lot of Panasonic auto-iris, fixed-length lenses I see, for example, don't have any adjustments on the lens itself. Since fixed-focal lenses don't have a zoom function, and the iris is controlled by the camera, the only thing left is focus, and these lenses rely on you using the camera's backfocus ring to adjust that (so instead of actually adjusting the lens, you're adjusting the position of the camera's sensor).

I have three different Capture PTZs - two older Fastrax models and a newer Minitrax - two of which are having issues accepting control from DVRs. They work fine with the Capture joystick, but for the life of me I can't get them work off any kind of PC/software control.

But that's a story for another time... at the moment what I'm really after are manuals for the things, particularly the Minitrax. And the thing that's really pissing me off is that Capture doesn't have them on their site. There's a "View All Manuals" link that does nothing, and when you go to any particular product, they have links for product images and brochures... but not for a manual (example, for the Minitrax: http://capturecctv.com/product.php?prod_id=216)

Capture's support is no help, they just tell me to go to AV Logics' site, where they have even less information and the support people I've tried there are even less helpful than Capture's...

So, after all this rambling, does anyone have any other online sources for these manuals?

yeah we use the Highwire product from Veracityusa

 

www.veracityusa.com

Thanks, looks like a pretty cool product line! Think I'll be contacting these guys...

Yes sir...IP CAMS are the future but they need to catch up when it gets dark. Most drop the RES to half and go B&W mode.

Most analog cameras that have "day/night" modes switch to B&W in low light as well...

I don't see any problems with a correct installations. The problems amount to the lack of networking knowledge of installers -they are plumbers and electricians all clambering for a fast buck

This affects the industry as a whole, in my experience. I went on one site - a gas station - where a new corporate-selected CCTV supplier had sent some electricians to install a new DVR (replacing existing MUX and VCR), three LCD monitors, and replace a bunch of cameras and the power supplies (it had been running mostly on a bunch of 24/40 wall-warts on a couple power bars). The electricians had the place ripped up for close to a month, botched the job of hanging the monitors, and attached the car-wash cameras to nothing more than the soft vinyl siding inside the car wash. Instead of using a single 16-channel power supply, they used one eight-channel unit and two four-channel units... and then doubled-up a number of channels, so only 11 of the total 16 available screw terminals were actually in use. And then they HARD-WIRED them all into the line power running BX into a gang box. And these are monstrous Pelco power supplies that are now eating up a ton of shelf space in the office.

IT "gurus" also are guilty putting 10+ cameras on a 100Mb work groups switch. then complaining !

Yuck!

Most IP cams are great -full of features but when it gets dark the sales people run and hide.....

 

Can anyone name an IP cam that works well in low light or with IR ?

so far I see the "extreme IP ex82" new one and the Arecont 3130.

 

z

I really don't have much experience outside the IQEye cameras, but I find they have pretty good low-light performance. Not "amazing", but perfectly acceptable in most situations. Take a look at http://www.iqeye.com/IQeye750-Day-Night.html

The biggest drawback I find, actually, to most IP cameras is their lack of auto-iris support - it makes fine-tuning them a little trickier in contrasty areas, and manual-iris lenses are getting harder to find.

I didn't really find any specific info on anyone doing this, so I guess I'll be the first to ask: is anyone retrofitting IP cameras and NVRs using ethernet-over-coax tranceivers?

I've found these products that will do the trick - http://www.omegacubed.net/ethernet_over_coax/ethernet_over_coax.html - but they're UK-based... I'm wondering if anyone on this side of the pond knows of any products like this (Canada-based, ideally). We have one local supplier (sort of) but their adapters are pretty pricy.

Wow, don't ya love people bumping ancient threads?

I've flipped through this debate (not reading EVERY message) and the one thing I haven't seen anyone mention is the RESOLUTION possible with IP cameras.

NTSC analog cameras max out at, what, 520 vertical lines? Your basic capture card gives you maybe 720x480 resolution digitization. Anything beyond that is going to get VERY expensive, and you're still limited by the maximum resolution of analog video.

The cheapest IP cameras we work with are 1.3MP - 1280x1024, almost twice the horizontal resolution and 2.5 times the vertical detail of analog capture. They're about twice the price of the most expensive analog fixed cameras, but I can use one 1.3MP camera to cover what would typically take me FOUR analog cameras.

Working a lot with gas-station installs, they want to have clear pictures of people's license plates at the pumps. One analog camera set wide enough to see both sides of a pump will just BARELY result in a legible plate under ideal conditions, otherwise two cameras are required, one for each side. If you have two pumps on an island, that's four cameras to get good, clear plates.

Alternately, I can put a single 1.3MP cam on the building or a pole off the end of the island and cover all four pumps easily... on one site I even have two cameras covering 6 pumps on three islands (12 fueling positions), both sides of an outer island and one overlapping side of the center island. Another station has three cameras in its store, and they get clearer views of faces and activities through the whole store than a similar station gets from 8 in-store cameras.

TCO may still be lower on a "per-camera" basis with analog, but that difference quickly fades when you consider what you're able to see and how many cameras are actually required.

And as HAS been noted, infrastructure CAN potentially be cheaper, because you don't need to use a star topology and home-run every cable. Yes, outfits like NVT make video baluns and multiplexing systems that will let you get away from the star topology, but that's going to drive the cost up again.

I have a customer with a Capture keyboard running three PTZ cameras, interfaced through a Capture HID2404CJL box. To facilitate upcoming upgrades, we need to move all their camera control to the DVR, but they're not happy about losing their existing keyboard/joystick control setup.

Now this 2404 box has a DB9 RS-232 port labeled "DVR"... so I'm wondering if anyone knows, is this to allow passthru of DVR control signals... or is it for output TO a DVR? If the former, it would make my job of switching them over a LOT simpler.

If you're talking about web access, you could always create a web page on one of the DVRs consisting only of links to each machine's web interface at the appropriate port... something along the lines of (substituting for html tags)

(url=http://dvr1:5550)click here for DVR 1(/url)

(url=http://dvr1:5551)click here for DVR 2(/url)

(url=http://dvr1:5552)click here for DVR 3(/url)

Beyond that, you could implement a scripted install of the Multiview client, with instructions that they need only to run this simple package and all will be installed and configured as necessary. How well the base installer itself can be scripted, I have no idea - it may require a utility like SysDiff.

Thanks, I'll give that a look.