Quantum`

Does anyone know what plugins work for the HikVision (2132) streams in Linux? I see that in IE it works with WebComponents, but there's no equivalent in Linux. I've installed libquicktime, but I get a red circle with a slash through it. Watching the browser console I have GET XHR http://192.0.0.62/ISAPI/PTZCtrl/channels/1/capabilities [HTTP/1.1 500 Internal Server Error 12ms] GET XHR http://192.0.0.62/ISAPI/PTZCtrl/channels/1/presets [HTTP/1.1 500 Internal Server Error 26ms] The VLC plugin gives the same thing, and MJPEG gives a broken link. HikVision firmware v5.2.5 build 141201

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)

Neither. sftp. It's not as easy as iSCSI nor as bloated a dinosaur as NFS, but it gives military-grade directory-level security on the NAS.

I didn't read it closely enough to see you were planning indoor cams. I second the 'why', unless you want to monitor babysitter, teens (, or wife)? Myself, I have only two cams: - on a 7' pole at the far corner of the front yard, looking at the house and whole front yard. The pole and camera are buried in a thick fir tree and painted camouflage. (Hiding cameras vs advertising them is a philosophical question which I'm not going in to) - looking out a hole beside the garage door of the detached garage, looking down the driveway and at the whole back of the house. So I have 100% coverage of the house and (longish) driveway with two quality cameras, and I even get cars going down the street in case something happens elsewhere, it may be a point of evidence. My garage is 30' away from the house and it houses my backups and security cam computer. (in case of theft or fire in the house) I did an expensive wifi upgrade to 802.11ac, but found that wifi will not bridge for Xen (need Xen to run Winduhs since I'm a Linux house) so I had to ditch it. I went with powerline networking for the garage to the house, and it works great. PoE for the pole cam of course.

Unfortunately SADP wouldn't install properly. I ended up holding down the reset button for 15 seconds, then ran a hacker scanning tool to find it was at 192.0.0.61 . (for some reason)

Just got my Hik 2632's from the Chinese eBay vendor, but one is invisible. Lately they've been coming with IP 192.0.0.62, but this one's not there, or at .64. I'm doing a full class A scan with nmap now, but that's going to take forever. What I think is going on here is somebody thoughtfully changed the IP to their favorite, before I got the camera. Is there a way to use the Reset button (or some other method) to set back to factory defaults?

It depends on how low your standards are. Myself, I have to have things crystal-clear and doing exactly as I want. So domes are out. (IR reflectance & focus issues) I am happy with my current Hik DS-2CD2632F-IS's. SD cards in case the recording computer is stolen, alarms for IR sensors, audio recording (!), good clear 3mp video, and good night performance.

Yes iVMS is pretty much useless in Linux. I managed to get it installed (with 32bit dependencies in my 64bit machine), and the camera set up. But for some reason in the Main View, the video doesn't show when I click on the camera on the left. And since I can't see any text I can't find out if there may be error messages or problems. Very impressive, HikVision. Why can't they provide the source code so I can fix it and compile it for 64bit? It's free, isn't it?

Thanks, but apparently no one is using it. All the text is gray on the same color gray background, so the text is invisible. Charming. I have the white-windows to fill stuff in, but I don't know what they are. It's not possible to highlight the text, and it's immune to themes. Very covert... The Linux WebComponents linked above simply isn't seen by any browser. The libs land in /usr/local/lib/WebComponents, but probably because it's 32bit and my browsers are 64bit, they don't see it.

Thanks. No wonder I couldn't find it; it's segregated in Europe. Those are pretty old though and are not 64bit. With CentOS packages, Quicktime gives a black screen (libquicktime), and gxine doesn't even recognize the stream with all plugins installed. The VLC plugin gives a black screen. Maybe I'll have a go at compiling webcomponents. Probably there'll be something missing. I wanted to examine the actual video format to see what the problem might be so I tried to scp an mp4 from the SD card, but the camera doesn't have scp installed (or much else else), so I have to set up an ftp on the server.

OK, I guess no one runs Linux here. For networking, I want RTSP to run as UDP, not TCP. I've set UDP in Local Config, but then Live View fails. And RTSP is still TCP. Anyone know how to make RTSP, UDP? Anyone know what "SDK port" 8000 is for? Any way to make it UDP? Know how to set up email? (Basic and Smart Events have no email tab, and it's nowhere else) How to make it save to the local SD card rather than to the Windows system running the browser? (I've formatted the card and it sees it, but Local Config doesn't give any way to save to it) I'm beginning to think v5.2.5 is snakebit.