Quantum`

Here's an idea: Buy a Hik 2532 with 2.8mm lens and mount it in the car. Maybe one looking out the front and one out the back. Put in a 64GB SD card, replace the sorry mic, and connect the network to a low-power wifi access point. No need for any PeeCee. Find a 12V car wire for power to the DC connector. The cameras would record all the time (even when parked) to the SD card, and you could connect to them with the phone to view and download videos in case of a crash or other incident. Maybe even make the front one swiveled in case you're pulled over. No need for the IR, or even the case. I don't really have a fix on how large this camera is nor the configuration of its controller card, but doable? Anyone have the 2532?

I have them set to Video+Audio. I have streaming set to UDP so I don't get video in the Live Preview. I run Linux exclusively, so the Hik plugin doesn't work. Also I'm 64bit, and the (ancient) Hik plugin for Linux is 32bit. I depend on the RTSP stream, viewed in VLC and indeed there's sound there from both cameras. The experiment I ran was to first cut part of a recording, then to download another recording. Then I opened each in MediaInfo and then KDENLive. No audio track at all in the cut clip, and an audio track in the downloaded one but it doesn't play the audio in VLC (or anything else) for some reason.

Here's a retarded thing: In Hik's web interface, on the Playback tab, when you clip a piece of video (with the scissors), it does not save the audio. There is no audio track in the file. Another retarded thing: If you download the file that's actually on disk which was recorded by the camera, you do get the audio track in that file, but it will not play in VLC or any other app. Audio plays just fine watching the direct RTSP stream live.

Oh, you know what the compression artifacts are, is the NX remote desktop software. When I run the stream on a local machine it's quite clear. (attached) And even that is reduced to 1920x1080 from the native size. See what you think. Still, the bitrate is extraordinarily low. H.264 magick? I am getting disturbing messages from VLC though: [h264 @ 0x7fe4c400b9e0] error while decoding MB 109 8, bytestream -47 MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (200000). 487028 bytes of trailing data will be dropped! [00007fe4b018db78] freetype spu text error: Breaking unbreakable line [h264 @ 0x7fe4c40eaca0] error while decoding MB 100 16, bytestream -33 MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (400000). 267723 bytes of trailing data will be dropped! [h264 @ 0x7fe4c400b9e0] error while decoding MB 95 38, bytestream -23 Ostensibly there's a place to set buffer size in VLC menus, but I can't find it.

As I say quality is Highest. When I set bitrate higher, as trees sway there's pixellation. At 6144Kb/s it sort of switches between fuzzy and clear. Yes I'd say two cameras, each at 6144Kb/s, running both in a 1.5Mb/s stream is pretty compressed, but I don't know why.

It's going to vary all over the map. Best thing is to check the datasheet. But it'll be more than 2.4W, even without IR. That's the answer you're resisting. Maybe you need better cable. ToughCable shielded cable and shielded connectors. And inject silicone grease in those connectors before you terminate, for a gas-tight connection.

I am astounded to be running two cameras now which together, use less than 1.5Mbps of network bandwidth! And this is in a Nomachine NX window which also is using bandwidth. These are the Hik 2632's running at highest rez (2048x1536), Highest video quality, and at 6144Kbits/sec. With audio! My tricks: Variable bitrate, SVC on, and most importantly UDP in Local Config. G.726 for audio and Environmental filter on. Of course I'm not using an NVR, but instead the RTSP stream directly (as NVRs do), since I run Linux and there's no other choice. Don't worry, RTSP knows when you've switched to UDP; UDP doesn't have the overhead of TCP, and RTP keeps packet discipline for you. It is incredible to be using this low a bandwidth for near-top quality. Yeah, it's using alot of CPU (upper-right, 4 bars), but that's only because VNC isn't hardware-accelerated. If I can find an RTSP client that is, well... A trick for focus: Get some electrician's tape and go to where you want the best focus (as it varies with depth-of-field). Put up a cross, and focus to make the cross sharp.

I bought a Mobotix 'darth vader' a couple years ago, and despite what they say it never could give more than 5 frames per second. I sold it on ebat soon after I bought it.

And what do you give to cover your guarantee?

Yes I have 64GB SD cards in my two 2632 Hik cameras, and also they FTP all events to the backups server which is in the far end of the garage. (in case of fire or theft) I don't have sensitivity or zones down quite yet, but ultimately the cameras will email my phone. Sandisk now makes 'long-wear' SD cards specifically for video. They rate them for about a year, if constant use. Hik cameras, in Live Preview, call for the video on port 554 via RSTP. (I've confirmed in Wireshark) RSTP does authentication and herds through the RTP transport stream. Unfortunately the default RTP stream is TCP which, although it ensures the packets get there, has alot of overhead. In Hik cameras you can set this to UDP thankfully, and RTP does a fine job with integrity, but then the Live Preview goes away in the web interface. I'm looking for an Android app that can do RSTP using a URL which might look something like: rtsp://admin:12345@192.0.0.64/h264/ch1/main/av_stream?udp or rtsp://admin:12345@192.0.0.64/h264/ch1/sub/av_stream?udp VLC in CentOS does these links just fine (including audio!), but haven't had time to look in Android. Haven't gotten that far yet. No one actually knows what port 8000 is for; AFAICT, nothing useful.

Problem of the OP was as others said 'split pairs'. This makes a difference because ethernet uses 'differential signaling'. Each twisted pair is intended for a function, and the two wires in the pair are referenced in relation to one another. So it matters which pairs go together. Also as others said, solid wire (not stranded) is necessary for longer runs and decent speeds. Stranded is used where the cable has to flex; it lasts longer before breaking. And all-copper of course. I always use ToughCable, and Ubiquiti's connectors. I always solder the cable ground wire to the shield of the connector, and use the hood. For outdoor connections I first inject silicone grease into the connector before I stick in the wires, for a gas-tight connection. (Auto parts store: "dielectric grease" for distributors. Whatever you do, don't use silicone caulk; it gives off acetic acid to cure, which corrodes copper. RTV is fine but grease is best) I've had cases where a camera is on a pole, and thus is grounded; but because of the cable ground and a difference in potential between the pole ground and building ground, there is a ground loop which causes a 60Hz hum in other equipment. Most guys would cut the cable ground to fix this, but that affects the differential signaling and PoE reference, so I insulate the camera's mount to the pole.

Huh?

Everyone mounts the cameras on the building. That's not very good for evidence. I have mine on poles at the far corners of the yards, so I have 100% coverage of the house and both yards with two cameras. (buriable ToughCable) Both are hidden in thick fir trees and painted camouflage. Invisible. I know, being visible has its deterrent, but I have different things in mind.

I run Linux exclusively, and so there is no software for me, effectively. I've just gotten two Hik cameras set up and have them set for local storage and to do motion detect. I plan to tie in to their SNMP which should ring a tone on my server when an event happens, and I'm trying to dissect the protocols of the camera for video streams to display them. So far I have RTSP, but that's TCP and thus pretty slow with lots of overhead. Also if I can get sshfs installed to the cameras they can record to a remote NAS with SFTP. Since I'm doing New Science and no one else knows about these things, it's taking me a while to deconstruct things though.

Um... I'd hate to be your kids. What kind of message is this sending. As far as that goes, I can't see any reason to have a camera anywhere inside your own house. (unless you're concerned about your wife or babysitter)