Soundy

Does VI have a demo of the 4.1 analog server? Last time I looked, 4.x appeared to only be an IP server...

So, are you saying that the adapter translates the information passed to it into a format usuable by your computer, or are you going to try and tell me that the adapter changes the information in some other way, as ak did. I'm saying the adapter has no way of knowing the TVL capabilities of the sensor. That's the standard Windows key combination to close the current window. No kidding. Did you know this before hand or did you find it out by trial while reading the post or by googling it? Not suprisingly it's a combination you'd have to press if the resolution you're trying to view is higher than your desktop resolution...effectively making it very difficult to close the window any other way. I've actually known that since about Windows 3.0 and OS/2 2.0. So no, I didn't have to try it or google it. How is closing the window supposed to help me if it's displaying video at a higher resolution than my desktop? Minimizing it maybe, or de-maximizing it, might help. Closing it won't, unless those keys are given a different function on some specific software. will you be shutting up now...or am I right in expecting even this wont be good enough for you It would, if it worked. It doesn't. You couldn't get it to work, so it doesn't work at all. Good arguement. Well, I followed your instructions to the letter. VLC doesn't do what you claim it does. If you know how to get it to do what you say it should, then either provide better instructions, or better yet, use a screen-recorder utility to make a video showing how it's done (with the TVL display). I thought the idea was to do it using a signal other than the one recorded by the DVR software. You say this should work with any hardware, so why not the DVR capture card? Or does it only work with single-input USB adapters? And BTW... what other signal am I supposed to be using here, if not the one provided by the camera? I want to know the TVL of that camera, is it not required to then use the video coming out of that camera? I do? What additional software would that be? This is not a gaming adapter; this is a USB-connected video-input-and-tuner adapter that's marketed specifically for playing and capturing video games via your PC display. The "game" component of it is a marketing term only. Yet more proof you're talking out your arse - you claim this process is entirely dependent on the software and should work the same with any hardware, but then you tell me all the hardware I'm using is wrong, when you obviously don't even know what the hardware is. What HD signals am I trying it with? This NLC5700 doesn't output HD, it outputs NTSC SD video. And again, I never specified any resolution for it to use. Wow... that's a great cop-out. "Hey, this will work if you follow these instructions"... "Okay, you followed the instructions I gave you and it doesn't work, so obviously YOU screwed up... but hey, I haven't actually used it for a long time... but it's still YOUR fault." Hey, I was just quoting what VLC told me. My bad for not including a screenshot. And BTW, 30fps is only accurate for black-and-white NTSC video. 29.97 is the commonly-accepted approximation for 30fps drop-frame for NTSC color video. No, it's based on your claim that VLC could easily reveal at least an approximation of the TVL resolution of the camera sensor. Umm, sorry... the whole point of the thread was to determine the "actual" TVL resolution of a CCTV camera sensor. You claim it's possible to do , at least approximately, with VLC. So far, you've been unable to prove that theory. THAT is where the waste of time comes in. I followed YOUR step by step instructions in an effort to substantiate YOUR claims. If I do it by my own methods, that doesn't do anything for your claims. Thus, I use YOUR method. The GameBridge requires no specific software. VLC accesses it via its own DirectShow drivers. The burden of proof is still on you to substantiate your own claims. I tried a method you said would work, and then within the same response you dismiss the attempts as me not knowing what I'm doing, stated I'm not using the correct hardware, and then berated me for using YOUR procedure. You've contradicted yourself repeatedly throughout this discourse and seem to be operating by the theory, "If you can't dazzle them with brilliance, baffle them with bull$#!t." Well sorry, I'm neither dazzled nor baffled. You want to be useful? Fire up a screen recorder, load up your VLC, and put a video up on YouTube for us showing exactly how this will work. Until then, it's just smoke and mirrors. Oh, but I forgot, you're done with this thread. So we'll see no proof of your claims, and you can sit back and back in your superiority. Well, enjoy that.

With a powerful enough system, it will handle it. But this is true with any PC-based DVR: there's a lot of throughput and data processing involved with those kinds of framerates, so you need to ensure your hardware is sufficient.

That doesn't preclude the use of a Windows-based (or Linux-based, or any other sort of PC-based) DVR/NVR... it just means you build a dedicated machine for that purpose. We install plenty of Windows-based DVRs that are highly reliable (in fact, 99% of our installs are Windows-based systems)... as long as people aren't using them for web surfing, IM chatting, email, etc. Most Windows instability comes from user-induced faults; prevent the users from f*cking things up, and your DVR will run very happily on a PC.

That depends on the actual capacity of the UPS, and the wattage of the lamp (what wattage is "normal"?). Given those two numbers, you could calculate the time fairly easily. Keep in mind that a UPS is designed to always supply its load when the power is on, and keep supplying it when the power goes out... emergency lights are typically designed to only go on when the power goes off. If you want this sort of functionality, you'd need to rig a relay circuit of some sort. Actually, most of your readily-available emergency lights are 12VDC bulbs that run straight off a 12V lead-acid battery, very similar to the one that's inside your UPS. It's far more efficient, since you're not needing to convert the 12VDC back up to 120VAC, a fairly wasteful process in itself. A standard emergency light is very simple: a charging circuit that consists of a step-down transformer, rectifier, ripple filter and usually some form of current limiting; the battery; the lights; and a relay between the lights and the battery that stays open as long as AC power is supplied. Lose the AC feed, the relay closes, and powers the lights straight off the battery.

That funny That's like that old joke, little Johnny walking around the house banging on a pot with a wooden spoon. His mom stops him and asks him why he's making all the noise, little Johnny says, "Mom, that's to keep the alligators away!" Mom says, "But Johnny, there are no alligators where we live!" "Well you see then, it's working!"

Hmm, I would tend to suspect the camera anyway... quick way to test is to swap the two of them and see if the problem moves with it.

See, there's where your assumptions fall down: the camera isn't connected to the computer. It's connected to the adapter. The software has to communicate with that adapter, not with the camera. That adapter has no way of knowing the TVL of the camera's sensor, it's just reading the NTSC output of it, 525 lines, 30 times per second (substitute appropriate numbers for PAL, if that's what you're using). For that matter, the assumption also trips over the fact that the sensor itself - which is where your relevant TVL number comes from - doesn't connect directly to the adapter or computer, but to the camera's internals, which generate the 525-line NTSC-standard output. That's correct... in my tests, according to your instructions above, it displays a 740x480 pixel window (plus frame, toolbar, etc.), and states the video resolution as 740x480. I didn't tell it what resolution to use; I didn't give it any configuration other than what adapter to use, and what input pin to use on that adapter. That's the standard Windows key combination to close the current window. will you be shutting up now...or am I right in expecting even this wont be good enough for you It would, if it worked. It doesn't. I have?? Where?? What software?? You've never suggested someone look into a software developement kit? ....hmmm http://www.cctvforum.com/viewtopic.php?p=101972&highlight=#101972heres a clueP: That's got nothing to do with this thread. How is this "the point of stupidity"? You claimed true TVL of a camera could be approximately determined using simple software such as VLC, regardless of the intermediate hardware used. I claimed it wasn't possible, you insisted it was, so I asked for the details. What you've provided so far doesn't support your claims, and I still say you're out to lunch. Or would be, if this idea worked, but it doesn't. That's the one thing I agree with.

Well, so far I've found that VLC doesn't view my Vigil ComArt HICAP50B as a "supported device"... so using it on the actual DVR is out. Version 1.0.0-rc3 of VLC on my laptop just locks up when I try to open my Adaptec GameBridge. 0.9.9 just crashes. Version 0.8.6 of VLC sees my GameBridge and shows me the camera video, but information is very limited: View -> Stream and Media Info -> Advanced Information shows me only the Codec (UYVY), the type of stream (video), the capture resolution (740x480), and the frame rate (29.970000). Switching to the Statistics tab, I get the amount of data demuxed, and a stream bitrate that changes with the actual movement in the image. Sorry, but the only relevant data here is actual capture resolution of the capture device, as I stated - nothing that would serve to indicate or even hint at the TVL of the camera itself.

480i is all you're going get using the standard video inputs. There won't be a resolution option, because you're limited by the NTSC video signal. Part of the problem you're experiencing is because most widescreen TVs "stretch" a standard-def picture to fill the full width of the screen. Another part is that most have poor upscaling in the first place - if this TV does 1080p, then it's taking what's essentially a 640x480 picture and stretching it to 1920x1080 resolution. It's also so huge and you're probably so close to it than any resizing artifacts and "jaggies" will be much more obvious. One thing you can do that will help is, as mentioned, change the aspect ratio to 4:3 instead of 16:9. The option WILL be there in the TV's menus. The only other thing that would improve it would be to use a component, VGA, DVI or HDMI feed, but from the look of the eBay listing, that unit doesn't have any of those outputs... so you're stuck with composite video at 480i.

I googled 'ctncomme' and found the manufacturer's webpage. Does this look like your card? You should be able to contact them for the software... try using their contact form here: http://www.ctncomme.com/ind_04.htm

What's the voltage reading AT the camera? The Nuvico should also work at 24VAC, so as long as you're not getting excessive voltage drop over the power run, there shouldn't be an issue there (the fact that the camera works fine on a separate monitor would suggest power isn't the problem). When you tested the monitor with the LCD, did you test it AT the camera, or at the cable you're trying to plug into the DVR? If the former, you may want to re-test the cable run and not assume it's okay just because it worked with the other camera (something could have even been damaged while installing the new camera). My other thought is that if the DVR has daisy-chained in/out jacks for each channel, it's possible they aren't terminated properly and the Nuvico and Pelco simply aren't seeing the load they expect. There may be a termination option in the settings (you're probably looking for a "75 ohm/Hi-Z" option - you'll want 75 ohm if there's nothing connected to the OUT for that channel), or a switch for each channel on the back... or, some systems will auto-detect the termination needs at startup and you need to cycle the power on the DVR *with* the camera connected. Other than that, there's really no reason pretty much any camera shouldn't work on that DVR, and I can't imagine why Nuvicos would specifically have a problem with them.

Okay then, let's bring it back on topic. Instead of theoreticals, tell us exactly how to use VLC to determine the TVL of our cameras. You say the hardware is irrelevant, so let's start with the obvious: tell me how I'm going to get the signal from the camera into my computer so I can view it in VLC. I have a number of different analog cameras to test this with. I have several computers with Windows XP Pro and the latest version of VLC. Come on now, it's put-up-or-shut-up time. No thanks, I get enough nonsensical babbling at home with my wife on a cleaning spree. I have?? Where?? What software?? Must be the former, because I don't have time for the latter.

That would be great, but I don't have access to that section.

Babbling? Hardly not. I'd still like to see computer hardware that is limited to 320x240. Software is coded to produce whatever the developers decide on (engineers create circuits that handle a predetermined amount of bandwidth determined by the components themselves, however the developers are the ones that create the software that ultimately decides how to utilize that hardware), so software can quite easily turn your dvr card, which by todays standards should be able to handle well over 5Mhz (keeping with the numbers posted here already) of bandwidth, into a piece of hardware that will only allow 320x240 as the max resolution. This has NOTHING to do with what the hardware is capable of...its a software limitation. Oh... so you're saying all these cards everyone is using that do 740x480 at best... that that's a limitation of the software? That all someone needs to do is step up and write software that will sample at ten times that resolution, and we can consider megapixel network cameras obsolete? I guess someone should have told that to all the developers of audio A/D converters 20 years ago, when 44.1k/16-bit stereo for CDs was pushing the limits. Guys, the digitizing hardware is irrelevant - your ADATs can actually do 192k/48-bit recording, it just needs the right SOFTWARE written for it. Sorry, but it don't work that way: the HARDWARE, the DIGITIZING HARDWARE, the ANALOG-TO-DIGITAL CONVERTER HARDWARE is still required to take your analog signal and put it into a digital form BEFORE the software can do anything with it... even at D1, you're going to hit that 480-pixel limitation (with NTSC) and you won't be able to determine TVL any higher than that. No kidding? I hadn't noticed. Yes, it's a whitepaper on "Understanding TV Lines", with an internal link SPECIFICALLY to the section on MEASURING TVL... which is why I added that with "and specifically". No need to be sarcastic, I was pointing it out in case you didnt mean to do this. I thought it was obvious from the "and specifically" that I was intentionally linking the same page. "See, here's some general information on the subject... and if you look here, here's some more specific content." No, the idea was to point the main page in general as a source of information, and then to the "measuring" portion specifically, as that was the topic of discussion. Without doing that, some might click the first link, not bother reading any farther, and then say, "Oh, that's nice, but I want to know how to MEASURE it, I don't care about UNDERSTANDING it." And yes, that does happen - I've been online for 20+ years, I see it all the time. People are lazy if you don't stick information like that right under their noses. I rest my case

I am thinking about $10-$15 month for home users. Do you think this is reasonable? I expect that most home applications (monitor pets, entrance to garage, etc) do not require 24x7 recording. And if I record motion activated events only - the traffic and storage becomes reasonable (within few GB a month) There's an alarm company in Canada, called AlarmForce, that has a similar type of business model: you pay nothing up-front for installation or the equipment, and $25/mo for the monitoring. The old-school alarm guys poo-poo it, but we had it once in a rental townhouse, and it works fairly well. The "brain" is just a little box that plugs into power and the phone line; the base price includes one motion sensor and one door sensor (both wireless). For a keypad, you use any existing phone in the house to enter your codes. The "brain" includes a speakerphone setup, so when it goes off, it calls the monitoring station, and they can communicate back directly. The thing we liked about it, being on a really tight budget at the time, was the payment model - most installed systems would have been in the $500-$1000+ range (installed cost), something we could never have afforded at the time. For someone who wants a camera for their home or small business that doesn't have the upfront cash for the system, yours may be a good idea. The catch to the AlarmForce model (there's always a catch, isn't there?) is that you have to sign up for a four-year contract, and early cancellation basically requires you to pay out the rest of the total amount to the end of that term. They also stipulate that they own the equipment, so when you do end your contract, they get the system back. The plus-side to that, for the user, is that they also warranty it for the entire time you have it - the only thing you have to do is change the batteries in the sensors once a year. I know, I'm sounding like a salesman for these guys... but I'm thinking, it's a business model that's worked well for them for a long time (the latest commercials also make a big deal that they haven't changed their monitoring rates in 15+ years), and it may give you some ideas for what you want to do: instead of selling the camera, lease it to the customer along with the service. If they ever terminate, you take the camera back, and you can lease it to someone else. Now the downside to that, with the cameras, is that the technology is moving so fast, but you could add in a clause that provides for future upgrades as well. The main idea is, it's additional peace of mind for the customer, that they don't have to ever worry about the hardware, and the ability to get it installed and running without a huge up-front cash outlay will be attractive to a lot of people, especially in today's economy. Of course, you'll have to work out what kind of monthly rate and contract term will allow you to recoup your costs properly - $25/mo for four years is a total of $1200, but compare that to what it would cost them to get the camera and a recorder, and then get it installed, and then add the remote recording on top of that. In the case of the alarm setup, monitoring for a regular home alarm at the time was $15-$20/mo., which added to even a mere $500 installation would have come to $1220-$1960 over the four years. The other thing you'd have to be sure to include is a stipulation that broadband internet is required on-site, and that the customer is wholly responsible for the reliability of his own internet connection (meaning, if it's flaky or goes down, he has to deal with the provider to get it going).

Hmm... That is interesting. Though at 1fps it is still about 100-200GB of data a month for a decent quality image - it is doable. Expensive, but doable. Not really that much - we have some older sites that do it for 8-12 cameras on a 120GB DVR. A lot depends on the motion and how carefully the motion-detection sensitivity and masking is set up, of course, but CIF @ 1fps is not a lot of data, especially by today's standards. At the other end of the spectrum, we have one site - a large upscale restaurant - that's recording at an average 4fps across 23 analog cameras at 4CIF, and five 1.3MP IP cameras, and they want 90 days' retention... for that, we have three 1TB drives in the DVR, and another 6.5TB in an 8x1TB RAID5 array...

Does it still jump if you move that camera to a different input? It could be some sort of electrical interference - does the wiring run near any sort of lighting or something with a motor (fridge, fan, etc.)? Does the jumping happen all the time, or just intermittently? It's most likely the camera is failing and will need to be replaced.

Got a specific model number of that DVR?

There's LOTS of middle-ground there. Most of our customers are fuel services, and with the two main ones that we do their new installs, corporate spec for analog is 30 days' retention, CIF @ 1fps (although we usually up it a bit for critical views like paypoint, ID, etc.). But, it's all high-quality gear and installs, no $50 IR lipstick cams. Most people wouldn't have the bandwidth for that. That is true. Are you thinking of including the camera in this offer? Well, I mean, I would record to my local DVR/NVR, but then I would ALSO send the video off-site to your service... in case, for example, the local machine is stolen or destroyed in a fire, or the local data is lost in some other way. Not at all. It could be good for the residential market... I just don't service the residential market at all I was just thinking of how it could be useful to our client base.

I'd like to see a couple of examples of this computer equipment that relies on something other than 1's and 0's. Computers dont care about input resolution, they dont care about output resolution, they dont care about format....they care about 1's and 0's. This is the same reason you can have both a PAL and NTSC camera hooked up to the same computer and watch both video feeds by doing nothing more than hooking the cameras up. Now software...thats a completely different story, unless you can read higher lvl comp languages you need this software to translate those 1's and 0's into a format you can read/understand, and it almost always does change the output into a format that the developers thought was better for whatever purpose/reason and, thank god, is also almost always configurable! A computer only changes the input signal when YOU make it (you make it do something, even if you dont know you're doing it, by your choice of software and in some cases hardware as well), otherwise it takes those 1's and 0's and pops them out the same as they come in. Unless VLC has changed its code it's not a software that automatically changes the input resolution so my rethought suggestion should still work This is babbling, it makes no sense. Your signal still has to pass through hardware before the software can do anything with it, and what your software - VLC or otherwise - can calculate on the data will be determined on the quality of that data. If your capture hardware can only capture at 320x240, then how is the software going to determine TVL resolution beyond 240 lines? Nobody's disagreeing with that. No kidding? I hadn't noticed. Yes, it's a whitepaper on "Understanding TV Lines", with an internal link SPECIFICALLY to the section on MEASURING TVL... which is why I added that with "and specifically".

I could definitely see this being marketed as a BACKUP service, recording in addition to the local NVR. If you could develop some sort of plugin or background service or something for PC-based DVRs or hybrids, that would stream their own analog recordings to your offsite storage, that would be a good selling point too. Power outages, you'd just have all your local equipment on a UPS, same as you would with local storage - local DVRs are subject to the same problems. Internet connectivity could be an issue, but as with any business internet solution, you might have to pay a premium to get the guaranteed uptime. My home cable broadband has been rock-solid for years - even on a basic residential account, I've had probably 99.99% uptime (not counting 12 hours or so when I forgot to pay my bill last month).

The problem with using all the existing cable wiring in your house for this is that it mostly likely all feeds back to one splitter for the incoming cable signal, so there's no way to route the signal, say, from a wall jack in the room with the DVR, to another wall jack elsewhere in the house. There are a number of different ways to accomplish what it APPEARS you're trying to do, it all depends on the specifics of what you're after. You can use a modulator to "add" the DVR signal to the cable feed where it comes into the house, and then tune the DVR on any TV in the place, or you can just run the DVR's video output straight to any one TV's A/V inputs.

CCTV_DU..was referring to OSX, not window$, two totally dif OS's. I think he knows that. http://www.parallels.com/

The problem is, you're still only measuring the capture resolution of the input device, be it a DVR card, or a simple USB TV-tuner device. It won't tell you the TVL resolution that the camera is outputting. This may be of some help: http://www.indigovision.com/whitepapers_resolutionandtvl.php and specifically: http://www.indigovision.com/whitepapers_resolutionandtvl.php#MeasuringTVLofadevice