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.

Give this a try on a Hikvision IP camera: h ttp://1.2.3.4/onvif/snapshot from any browser, or http getter, and see if you get a picture without any sort of authentication. Here, I put in http://192.168.0.31/onvif/snapshot. I double-checked in wireshark to make sure no authentication info was being passed. An Axis onvif shapshot requires authentication. Dahua and Hikvision do not. If port 80 is open to the world, anyone who stumbles upon your camera(s) can sneak a peek.

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.

J- You didn't answer the question. From that I presume you don't. Here is a tip: put any camera that writes to flash on a UPS. Just do it. Before the UPS shuts down, instruct the camera to stop writing. Welcome to Computers 101. When you graduate, then we can talk.

The IP camera -will- fail in numerous ways before the SD card in it does, if it does. You are so used to everything else failing in the camera (HW, FW or connecting SW, network, power) that apparently you have come to ignore it. Are all your cameras on a UPS? (I can answer that - mine are.) Anyway, flash is more reliable than the camera. Trying to make an argument the other way is...marketing.

This year's "extreme" is next year's "normal". You could buy junk SD cards today, sure. I would say the same thing about buying junk HDs. Don't do it.

Leaving aside yet another flawed analysis of expected time of failure for flash storage, I offer my point of view: I've had many HDs fail. I've also have had many run for as long as they remain useful. I've had zero CFs, SDs, SSDs fail. My CFs go back to 10 MB size. I suppose a CPU is more reliable (never had one of those fail, either), but next to them, flash storage is right up there. I don't think anyone (should) consider spinning rust reliable.

G.711 is 64 kbps. Almost always. G.726 is 32 kbps. Nearly always. G.726 is half the space and about the same quality. A bit more CPU but half the space makes it worth it. G.711 is much more common. G.711u (mu) is common in US/Can. G.711A is common in Europe. Or the other way around. G.726 has an odd-mode called AAL2, but that's sort of rare. It sounds odd if you decode it in not-odd mode. G.711u if you don't care about the space.

If you are still using Windows Phone, this WP app by me lets you start one camera at a time, or up to 10. http://www.windowsphone.com/en-us/store/app/netcam-x-delux/66274dac-f8c0-42e7-9537-ec1aff1c1477 NetCam X Delux is for Axis and Panasonic BL-C/BB-HCM network cameras, and others such as Dahua and Hikvision. Streams H264, motion-JPEG, and single-shot JPEG (M/JPEG). Audio is streamed with the H264 video, if available and selected. H264 up to 1920x1080 is handled, at a smooth 30 FPS. The trial is about 99% complete: no Load of a backup, and no suspend on back key (terminates always). WP 8.1 is required. --

Check wikipedia. The form of the basic authentication is: username:password You can probably find that at wikipedia, too. Feed that into a base-64 generator and out comes a base-64 (you can wiki base-64, too) string (wiki string?). So, if your username is joe and your password is blow, c:\>b64 -e < "joe:blow" > thebase64string.txt (Use whatever method the base-64 generator you find needs but that is how I would do it.) This is easily reversible. Anyone that sees that "out there" will (100% positively) know your username and password. But anyway, that is an mjpeg stream, not just a snapshot. The snapshot requires digest authentication, which is not reversible. You should go that way; the idea for using digest authentication is to not expose your username or password. h_ttp://1.2.3.4/streaming/channels/1/picture/ should require digest authentication (wiki...). If it is not (and how would you know? you would have to look at the network stream), you could see if adding the query, auth=digest does it (I don't need it here). .../streaming/channels/1/picture/?auth=digest Back to what the show-anyone-that-looks-my-password hik way, the output of the base-64 generator is what you give the auth= line, so something like .../streaming/channels/1/picture/?auth=OICU8124AaSDt4349adf== Anyone can take the "OICU8124AaSDt4349adf==" string and reverse the base-64 to get your username and password.

One or more of these WS-POE-8-48v60w passive Power Over Ethernet POE Injector for 8 IP cameras, VOIP phones or Access Points, 48 volts, 60 watts max http://www.amazon.com/WS-POE-8-48v60w-passive-Ethernet-Injector-cameras/dp/B0086SQDMM/ref=pd_cp_p_3 and some duct tape and you're all set. Use whatever Gbit switch you like. Go with single injectors for cameras that may need a lot of power. Gbit switches are cheap, and should be. Having to settle for a 100 Mbps fast ethernet switch (for $ reasons) to get POE is nuts. If you're handy you can make your own, but $6 a port is cheap enough.

Multicast is over UDP. It won't go outside a router, either, so your desire for "more than one location" is fine so long as it's still on your LAN. But, even a 6 Mbps stream times 10 viewers is nothing on a Gbit LAN. If you want to limit band/connections to the camera, put something like (...) in there and connect all clients to (...). (...) is whatever you want it to be. The only safe way to fly. Back to UDP. UDP is terrible for anything that fragments, and unless you are doing very small video frames (low quality 320x240[*]) you won't like what you see. Multicast is good for local/office conferencing, and if there's video in the mix, it's very small. TCP is the way to go for IP cameras. If it's not done right, you can back it up and get a lot of ...lag (the data is buffered until it's removed, and the buffers can get very big), but that's an implementation problem, and not the protocol. [*] Small H.264 video, that is. JPEG probably won't be so terrible