Soundy

I love my DD-WRT

Yeah, lots... how much are you ready to spend?

I gotta say, the more I play with this camera, the more I like it, just from a behind-the-scenes perspective. The control and live view interface work perfectly in Chrome; the JPEG push in Chrome is actually faster and smoother than the H.264 live-view in Explorer (H.264 in Chrome uses Quicktime, which is BRUTALLY slow). It has a remote-operable ABF that's very handy. Short of any quantitative tests, the low-light performance just sitting on my bench is stunning. Oh, and point of interest, it actually does a full 1MP (1280x960), although it defaults to 720p.

I'm not surprised that it would break with a newer build, actually - it's quite possible that some of the the underlying structure GV uses was carried over from Win7 up until this build, and now they've changed that component, it doesn't work any more.

It's a long-standing rule of thumb in the photography world, that the larger a zoom range a lens has, the greater the sacrifice in quality. The more complexity you have, there more room there is for something to go wrong. On the whole, a "prime" (fixed-focal) lens has the fewest elements, the least glass, and thus will TEND to give the best results.

Well, as groovyman notes, from an administrator's perspective, there's always benefit to figuring out what will and won't work, just because you don't know what you're going to run into. But you're right, until GV comes up with some software features that specifically takes advantage of something Win8 provides, there's little point in getting too excited about it. GV will still run fine on Win7 *or* XP, and a DVR should *ALWAYS ALWAYS ALWAYS* be run on a dedicated system, so even on a new machine that comes with Win8, there's no excuse to not just blow it away and start clean. As it is now, the only advantage Win7 has over XP is the ability to use >4GB RAM (and that, only with Win7x x64)... and I have yet to see a compelling case for needing >4GB RAM in a DVR in the first place (matter of fact, I have old Vigil boxes out in the field still running happily on W2K and 512MB RAM). And of course, there NO cause to get so worked up about something NOT working in a pre-release OS when there's no official support for that OS. New OS, not on the market, and hardware that has no manufacturer support for that OS yet... again, it's the EXPECTATION that it WON'T work.

I've done it all the time throughout the years - not with CCTV, but in general. Whenever Microsoft makes a preview available I always try it out. It's a necessity in the IT field to be educated on new technologies that are coming out. The education needs to start well before the final version hits the streets. Agreed, but by the same token, it's silly to ASSUME that just because something (especially hardware) worked in a previous version, it's going to work fine in the new version right off the hop.

Chill out, dude - the others are right: there's no reason to ASSUME it should work with Win8 until such time as GV actually provides Win8 drivers for it. It's often be possible to "massage" (or sometimes "beat into submission") drivers for an older version of Windows to work with a newer version... but it's certainly never guaranteed. I've used XP drivers for an old video card and got them working fine with Win7... I've also tried Vista drivers under Win7 for an older audio chipset and had it "kinda" work (with plenty of glitches)... and had TONS of other old hardware that simply wouldn't work at all. The proper EXPECTATION is that until GV releases actual drivers for Win8, their hardware probably won't work with Win8. Same holds true of any other OS as well. The driver is what allows the OS to directly talk to the hardware - if it's not specifically designed for that OS, there's no certainty that the communication will be understood.

It only displays them small - if you click a picture, it will open larger in a new window, and I believe if it's larger than your screen size, there will be another Zoom button to go full-size. Oh yeah, many times... as noted above, I've found it caused by a variety of reasons: crooked/loose lens mount, faulty lens, dirty lens... user error...

That looks quite a bit better. Still a little soft, but better. BTW, you can embed images by using the "http://i.imgur.com/xdA5g.jpg' alt='xdA5g.jpg'>

I'm talking about where the lens mount itself attaches to the board - make sure that it's snug all the way around, no gaps between it and the board. If it slipped position, it may still feel solid, but still not be right. I've installed a couple Vivotek box cams and a dome now, and I agree, they're pretty solid. Not saying that the lens mount IS the problem... just that that's what your description makes it sound like. Wow, that's pretty bad - the tree and car are near the same plane and if one is in focus, both should be. I dunno what else to suggest... try another lens, if you have one, just for the sake of testing?

Actually in my line of work, zero latency would be a plus. However, as I stated above, there's no advantage to a technology that not only requires we replace much, if not all, of our infrastructure, is not capable of seamless integration with the rest of our system. No matrix switches or recorders capable of handling >1000 cameras. No ability to display on tens of monitors, etc. I can see the biggest benefit for you being in PTZ control, especially as this is one of the main areas where latency in IP cameras IS a problem. On that note though, I'm currently bench-testing an Axis Q1604 (their new highly-touted low-light/WDR toy), and I gotta say... latency might be MEASURABLE, but it's practically UNNOTICEABLE unless you're actually looking for it. I can point it at my screen, then watch on the DVR - moving a window on the screen, it's only intermittently that I can actually see a delay on the DVR.

Actually, if it's always left/right (no up/down), I would more suspect the lens mount was loose. Your average board cam design basically just has a threaded plastic tube situated over the sensor, and the lens focuses by threading up and down in that tube... if the tube's mount to the board is loose, it could allow it to be holding the lens on an angle to the sensor, which could also account for the focus always being off left or right. The other possibility would be something actually ON the lens glass (fingerprint smudge or something), but then the out-of-focus area would move around the outside of the FOV, not just left or right.

I take it this camera uses an M12 or M13 thread board lens? I've seen instances where the threads on those (usually on the camera itself) are a bit loose and allow the lens to wobble side-to-side - that sort of movement could definitely account for what you're seeing.

It still proves my point. Latency - bad, no latency - good. Latency is not inherently "bad". Latency is the very nature of RECORDED video: it happens now, you see it later. That's the whole point.

" title="Applause" />

I calls'em as I sees'em. SMPTE 292M (HD-SDI) was first published in 1998... when the vast majority of analog CCTV was still using VCRs. It's not new. It actually has ZERO latency. However... Having installed systems in a couple hundred gas stations, I can tell you right now, zero latency would be of zero benefit. Consider that 99% of the time, in a retail situation, you're going to be viewing recorded video rather than live - an "introduced latency" of hours, days, weeks, or even months. If someone IS viewing it live, they're probably sitting in a back office, and an extra half-second between when something happens and when they see it isn't going to make a speck of difference in the time it takes them to get up off their arse and trundle out to the front counter. At even higher storage cost. 30fps is overkill in the majority of situations. 60fps is pointless. I never said it didn't. But it's a niche market at best. The benefits offered are *relevant* in only very limited situations.

SDI is a very old broadcast standard, I don't know that I'd call it "next wave". Which are what, exactly? That's like selling someone a car that can run on leaded gas - nice idea, but obsolete. Coax is a limited-use cable; UTP is far more flexible, versatile, and frankly, cheaper. There's no compelling reason to wire an installation with coax just for SDI cameras, especially when SDI doesn't go past 2MP. That's a major disadvantage... since analog cameras DO.

I've never understood this statement. There's no logical basis for it. Your typical digital-recorder system consists of three basic systems: one to electronically capture an image; one to convert that to a digital file format; and one to store it, usually with some sort of indexing/search function. A analog DVR setup puts the latter two systems in one box (the DVR); an IP system puts the first two systems in one box (the camera). There is ZERO technical reason that either should be more "reliable" than the other. Both generally record to the same magnetic storage media (hard drive); both generally use copper cable for interconnect; neither has any other substantial point of failure over the other. Irrelevant; you can't make a "longevity" comparison based on that since IP video hasn't been common on the commercial market for more than 5-6 years. I've seen far more cheap standalone units that were dead or flaky out-of-the-box or failed within days of installation. Once again, an irrelevant comparison - the most common failure in either system is the hard drive, and both standalone and PC systems use (or CAN use) exactly the same drives.

^That was my first thought too - make sure you're using proper T586-A or -B wiring (doesn't matter which, just make sure it's the same at both ends).

*click* that's what that first image looks like: excessive compression plus excessive sharpening.

The higher the compression, the lower the quality, so it could be referring to compression level rather than video quality (despite the name). Have you tried it at both ends of the scale? Same with the "Custom" option? That would make NO difference. It's not like analog video, where adding electronics in-line can directly effect video quality. That looks more like it's just out of focus.

Looks like JPEG compression artifacts. What stream type are you using?

My first guess would be faulty cameras, but since you've replaced them, that pretty much rules that out. Next guess would be that those two simply aren't getting enough current, and/or the cable size and length is causing too much voltage drop. Do the cameras actually show signal loss, or are they simply dark at night? It sounds as if they're dropping out as soon as the IR turns on. First, make and model of the cameras would help (if they exist - "Digital Camera" or "Color CCD" or the like means nothing). Second, ANY specs you have on the cameras would be useful, particularly actual power (W) or current (mA or A) ratings. Third, specs on the power adapters: make, model, output voltage, output current, regulated/non-regulated, etc. Fourth, ACTUAL length of wire runs... and more importantly, SIZE of the power wires. DVR and video cable should have no bearing on the issue.