40th Floor

I'll presume this is about an H* camera. Pre would be the period in seconds before the triggering event to record (to capture what happened before the event). Delay would seem to be the same as anti-dither, only a better word. It may do something else, though. I suppose it could be the period over which to continue recording after the triggering event. Anti-dither would be the period in seconds during which any further triggering is ignored. ... probably. I don't use those built-in things but instead the fine piece of software in my sig.

One camera could be doable. I would not want to do that for any remote connects. Put it on a network sniffer and see all your bits go flying by in the clear. Connecting by HTTPS (rare, already), doesn't mean the software is going to use that channel for the stream. FTP to a remote site? That's all in the clear. Now they (yeah, them) have control of your ftp site, not just for your videos - if even - but to use as a drop site for malware, file distribution, and other things you don't want traced back to you. Chances are, if you have even considered using FTP, you may not notice that happening right under your nose. How will you know? Change your password often, and don't allow anonymous logons. For home (local-only) use, and one camera, I suppose it would do fine for starting out. Why are you even considering it, though?

He's probably mistaken, though that wouldn't be the first camera to do that (cheapo Panasonics, for one). The reason to go 48 volts is the drop over distance on the tiny wires. 12 volts would be ... well, you could calculate the drop based on wire gauge and temperature -- google it -- too much of a voltage drop at 300 feet. So, at the camera, the 48 volts (what's left of it) is taken back down to 12 volts (or whatever it ultimately requires). Maybe that's where the other Smith is confused. Or not. You could always measure the voltage yourself. Get a throw-away cable and cut an end off. Find the wires to test. Hook it up to a VOM. If there's 12 V he's right. If it's 48 he's not. P.S. If he's right then only those cameras could work on that machine.

I don't know about A* but I know the one in my sig will. Enable the Ext1 and Ext2 in this http://40th.com/cnx/camnet_camsetup_info.html and it'll do what you want. Set Event by network type to EBNT_ONVIF, and set the camera make/model to Hikvision/HIK_IPC1.

Dahua is not in the list. Maybe it goes by another name.

There's nothing special about motion detection and Onvif profiles. I've got a very early Onvif 1.01 camera that generates events using the then-standard way of handling those events (c. 2009); nothing special at all going on - fully documented. With later Onvif versions you get a new way to handle this but nothing much different from the other way. The message layout as sent is standard-ish, but the content is not. Some cameras have very basic content; some like H* can also have very complex content. And of course, what works in one FW version may not in the next. And so it goes. A* is good at breaking things, to name one. Now, what any particular NVR/application does or accepts is another ball of wax.

This is my favorite. http://www.amazon.com/Labtec-VERSE-980184-0403-Discontinued-Manufacturer/dp/B00008XOMX All of a buck-fifty when I got it. I use it on an outdoor Toshiba and the sensitivity is excellent. Yeah, discontinued it says. More $ does not mean better performance for this application (IP camera). I've tried others but nothing picks up more than that. The thing is, you can't just use any mic-camera combo, so prepare to experiment. I would not put out $150 for a mic for any sort of IP camera. Could have gotten 150 of those Labtecs for that. Good luck on the speaker out. For that, bigger (speaker) is better. You'll want it amplified (a couple of real watts of output power is plenty for a short wire distance). Anything small is just going to be too hard to understand. And it might still be.

Toshiba ikwb15 is ready in 20 ms from start at client to server and back to client. Blows everything else away. The critera is not well defined. Delay as seen on the screen versus real life (like waving your hand), or/and delay before something appears on screen (like waving your hand, but nothing appears until the second hand wave, or third, or), or what. The first can be from the serving (camera) but much more likely is at the receiving (viewing) side. The second could be the either, or, both. Disable authentication. Don't use ssl. The first case (wave hand versus see hand wave time difference) is the only real problem. Good luck with that. I'd say RTSP it not a significant contributor to delay (case #1 delay). The decoding process (typically designed from non-realtime streams, like movies) is by far the worst. Some streams decode forward, too, and you have to wait to decode those before you display what you may have already received. Anyway, ikwb15, 0.02 secs and it's there. It uses an Axis ASIC. From 10 years ago. Made by TopView. Quality stuff. Except for the dome. But then all domes are junk.

H* fixed the no-creds snapshot peek but it still advertises the same URI for getting a snaphot. Software expecting an onvif camera to supply a working snapshot URI will come up empty as far as getting anything out of that URI (there's no response so eventually it'll time out; I tried it in a browser and it's still spinning a minute later). Some fix. : XmlIn::GetNextPrefixAndLocalName mode= 1.2 'trt:GetSnapshotUriResponse' XmlIn::GetNextPrefixAndLocalName mode= 1.3 'trt:MediaUri' XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:Uri' XmlIn::GetNextValue mode= 3.0 'http://192.168.0.31/onvif/snapshot' XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:InvalidAfterConnect' XmlIn::GetNextValue mode= 3.0 'false' XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:InvalidAfterReboot' XmlIn::GetNextValue mode= 3.0 'false' XmlIn::GetNextPrefixAndLocalName mode= 1.4 'tt:Timeout' XmlIn::GetNextValue mode= 3.0 'PT0S' : In 5.1.8.

Right, probably not the best place. Where else have you asked? Are you depending on the NTP timestamp from the SR packet? Well there's your problem. I'll mention a couple of reason why I think that. 1. Not all IP cameras will send SR. Big one. 2. NTP times, or the time-of-day known to the camera, is an uncertain quality. I've got a D* camera that, while it gets NTP from a time server just fine, is always off up to 30 seconds, sometimes more, as if it held that time until it finished starting up and then set itself to that time. I can see how the SR NTP timestamp could be a good source of sync'ing cameras, especially if they are not at the same location where you could have different packet delays between cameras. However, since the cameras themselves can be wildly off, much more than any delay, it means it's not dependable, even if all cameras send SRs as you expect.

Not for a cell phone. But if you have a landline, or something that connects through a (say) USB modem, then something like this http://40th.com/CNX/ which, on an event, dials a number, or calls a number then plays a .wav file (a voice modem is needed for that). If you have internet at the location then I think it's easy enough to dial, or call. It's a large html page so don't do it on a mobile. http://40th.com/CNX/gfx/10_camsetup_evtActions.png

user:pass@ hasn't worked in IE since IE6, and then not the later v6 ones. If you aren't doing it over SSL you are sending you creds in plain-text, and not only that, but also make it so simple that a cut-and-paste -- no reverse base-64, for example -- is all anyone needs to get on your camera and do whatever you could do. http://www.cctvforum.com/viewtopic.php?f=19&t=41641 If you are asking whether someone can get a snapshot if you don't open the camera's http port to the internet, no, not for that particular problem. This IS the onvif "(way)" to get a snapshot on Hiks: /onvif/snapshot. It's over the http port (like most Onvif cameras), so the problem then becomes one where you either accept possible snooping, or, if you don't open (forward) this port, not accessing your camera from the internet at all, not via http. Supposedly the snapshot free-for-all problem was fixed in FW 5.2.0 for these cameras, if you can find it (or any later ones). This problem is known by almost no one, so not finding FW updates is not the first problem for most affected by this.

Programmer fits perfectly for me. That is exactly what I do. Onvif profile G... By the way, and I think you asked back there, I got into this topic because of the flash angle (life of), not flash as storage on a camera specifically. It has its place, but if the network is there, and its fast, I would always store off-camera. I can pull 6 Mbps x 20 over 24 hours, just as a start, without any concern, and access that at any time, instantly. If this were stored on-camera, I'd have very slow access (65 GB a day, per camera). If a camera was made to fall back to on-camera storage when its network was down, that would be good (if only it worked every time). Or if it only recorded on (rare) motion or event, that would work. I saw WD's 16+ ms average access time for its purple and ... beyond belief; that was slow 20 years ago. That's one thing, but to then see places like THG say "[nevermind that slow access because WD tells us so]" is ... what's beyond beyond belief? Critical reviews have left the internet - no biting the hand that feeds. Jumping forward: The hard drive will be gone in 10 years. They know it.

ck2[1]: Fork inserted. Done. There was one DLL updated a couple years ago. I call myself a programmer, sometimes computer programmer. Always have. No funny looks with that. I know the "engineer" thing has been around for nearly 25 years, though. "Developer" doesn't say much about anything, either. Anyone in the process could be one (art, design, marketing) so that's kinda like saying "I am a worker". But then you sure had me fooled so what do I know. As for fear of failure: How many times has the power gone out there? How many times has a flash failed? One example of things that go wrong all the time, and for which most do nothing about it (like using a UPS). Write to any drive and while doing so pull the plug. Luck is the all that keeps very bad things from happening (on FAT-based drives, especially). Yup. That's why things have service schedules. Replace before their time, or cross your fingers. I heard Intel's SSDs do a Logan's Run after so many writes, but I also heard of SSDs far outlasting their design life. As for the WD purple, a textbook case on how to market a bottom-end drive to those who should know better. What in the world got you to go with that, other than the marketing -- it got you, huh? LOL [1] But the next thing is simply amazing. Well, to me.

ck2 was done in 2009 and released in 2010. It supports whatever was around back then, even h264[1]. There is a web page devoted to it where you could read about it if you really wanted, Carl. It's very old stuff, though., serviceable as it is (October will be 5 years running here with no crashes). It's not like you are into new things, Carl, even if they aren't all that new. Come on, don't pretend you know things you don't. [1] http://www.networkcamerareviews.com/forums/about4008.html Only kidding. Sort of. SD cards are cheap. If you are scared of it going bad out of the blue (as if nothing else will before, and instead), replace it like you would anything on a service schedule, be it at 274 days or at 2 years.