This page is a comment honey pot.
You are welcome to post your spam here.
Cameras and stuff
This page is a comment honey pot.
You are welcome to post your spam here.
A sidetrack from these two posts: Extracting password from Dahua firmware image and Dahua IPC-HFW4300S
To recap: I managed to extract various UBI (NAND flash) images from firmware image.
binwalk -e {firmware_file}
Which gave me the following files:
check.img
custom-x.ubifs.img
dhboot.bin.img
kernel.img
partition-x.cramfs.img
pd-x.ubifs.img
romfs-x.ubifs.img
user-x.ubifs.img
web-x.ubifs.img
I started with romfs-x.ubifs.img as initial grep revealed it contained root password hash (matched to ‘vizxv’).
Mounting UBIFS is not a straight forward (eg cannot use loop).
With help of two guides I found (here and here) I managed to figure out how to mount these images.
apt-get install mtd-utils
modprobe nandsim first_id_byte=0x20 second_id_byte=0xaa third_id_byte=0x00 fourth_id_byte=0x15
modprobe ubi mtd=0
tail -c+65 romfs-x.ubifs.img > romfs
ubiformat /dev/mtd0 -f romfs
ubiattach -p /dev/mtd0
mkdir target
mount -t ubifs /dev/ubi0_0 target
note: tail -c65 strips the header.
mounting contents of romfs-x.ubifs.img gives some insight on the root file structure:
drwxr-xr-x 2 500 500 5192 Apr 2 2013 bin
drwxr-xr-x 7 500 500 480 Feb 18 2012 dev
drwxr-xr-x 6 500 500 960 Feb 24 2013 etc
drwxr-xr-x 2 500 500 160 Jan 13 2012 home
drwxr-xr-x 2 500 500 4832 Feb 22 2013 lib
lrwxrwxrwx 1 500 500 11 Dec 31 2013 linuxrc -> bin/busybox
drwxr-xr-x 13 500 500 864 Dec 5 2012 mnt
drwxr-xr-x 2 500 500 160 Jan 13 2012 nfs
drwxr-xr-x 2 500 500 160 Jan 13 2012 proc
drwxr-xr-x 2 500 500 160 Jan 13 2012 root
drwxr-xr-x 2 500 500 2728 Dec 25 2013 sbin
drwxr-xr-x 2 500 500 160 Jan 13 2012 share
drwxr-xr-x 2 500 500 160 Jan 13 2012 slave
drwxr-xr-x 2 500 500 160 Jan 13 2012 sys
lrwxrwxrwx 1 500 500 8 Dec 31 2013 tmp -> var/tmp/
drwxr-xr-x 2 500 500 160 Jan 13 2012 usr
drwxr-xr-x 3 500 500 224 Jan 13 2012 var
looking at /etc/inittab
:
...
::sysinit:/etc/init.d/dnode
::sysinit:/etc/init.d/rcS
...
the /etc/init.d/dnode
sets up some of the device nodes, nothing interesting there…
while /etc/init.d/rcS
contains some interesting stuff:
/sbin/ubimkvol /dev/ubi6 -s 2500000 -N config
mount -t ubifs ubi6_0 /mnt/mtd
Here what I found out from contents of each UBIFS file:
UBIFS | description |
---|---|
check.img | contains some hardware IDs |
custom-x.ubifs.img | /mnt/custom customisation files? |
dhboot.bin.img | bootloader |
kernel.img | kernel image |
partition-x.cramfs.img | contains partition.txt |
pd-x.ubifs.img | /mnt/pd/ product description files |
romfs-x.ubifs.img | / root |
user-x.ubifs.img | /usr/ |
web-x.ubifs.im | /mnt/web/ webUI related files |
Interesting bit regarding partition-x.cramfs.img, that it contains partition.txt:
# name cs offset size mask_flags
U-Boot, 0, 0x0000000000200000, 0x0000000000100000, RW
hwid, 0, 0x0000000000300000, 0x0000000000100000, RW
updateflag, 0, 0x0000000000400000, 0x0000000000100000, RW
partition, 0, 0x0000000000500000, 0x0000000000100000, RW
custom, 0, 0x0000000000600000, 0x0000000000340000, RW
product, 0, 0x0000000000940000, 0x0000000000340000, RW
Kernel, 0, 0x0000000000c80000, 0x0000000000580000, RW
romfs, 0, 0x0000000001200000, 0x0000000000800000, RW
web, 0, 0x0000000001a00000, 0x0000000000800000, RW
user, 0, 0x0000000002200000, 0x0000000001980000, RW
syslog, 0, 0x0000000007200000, 0x0000000000400000, RW
config, 0, 0x0000000007600000, 0x0000000000400000, RW
backup, 0, 0x0000000007a00000, 0x0000000000400000, RW
END
all this is effort was to find the telnet password...
I am missing /mnt/mtd mount point, specifically /mnt/mtd/Config/passwd file, which looks like contains telnet password (possibly?)...
UPDATE: solution to the password debacle is here (at the end of the article).
Now the question where the portion of the telnet password 7ujMko0
comes from? "Inspecting" (running strings
) telnetd
binary from flash image reveals that it is hard coded into telnetd
. If Dahua ever changes that value I know where to find it now.
I wanted to access my Dahua IPC-HFW4300S via telnet (as there is no ssh access).
Unfortunately Dahua does not provide the root password (purposely, as it is hardcoded backdoor).
The currently documented password (vizxv) does not work.
So I got the firmware image (which is achievement, considering Dahua stance on firmware) and managed to extract hash.
First of all the firmware image needs to be extracted from zip, I’ll skip this part and jump straight into extracting binary parts from the firmware:
binwalk -e {Firware_File}
The binwalk utility should have extracted the following files:
check.img
custom-x.ubifs.img
dhboot.bin.img
kernel.img
partition-x.cramfs.img
pd-x.ubifs.img
romfs-x.ubifs.img
user-x.ubifs.img
web-x.ubifs.img
the file of interest is romfs-x.ubifs.img
as it has hits when grep-ed for ‘root’:
root:$1$jSqQv.uP$jgz4lwEx2pnDh4QwXkh06/:0:0:root:/:/bin/sh
Now we have a hash which we can brute force with John The Ripper tool.
I settled for 1.8.0 jumbo version with CUDA support.
CUDA seems to be about 2.5 times faster on Nivida GTX560ti than a very beefy 2x Intel Xeon E5-2660 (with 20 cores total).
Particular thing to I had to do to compile (beyond wget-ing and un-tar-ing the arhive) is to modify the entry from gcc-4.6 to gcc-4.8 in Makefile, as it would throw compilation error (gcc-4.6: error trying to exec ‘cc1plus’: execvp: No such file or directory).
line 152:
CCBIN = /usr/bin/gcc-4.8
‘make’ once done that (and libssl-dev is installed), and it should compile.
to run:
./john --format=md5crypt-cuda {hash_file}
The password turns out to be ‘vizxv’ (without quotes). This is not the telnet password (possibly console password).
UPDATE:
I was directed towards correct password here: http://www.cctvforum.com/viewtopic.php?f=19&t=44381
Here are telnet credentials
username: admin
password: 7ujMko0{webui_admin_password}
For example webUI admin password is 123456 then the telnet password is 7ujMko0123456
This is how you buy genuine Hikvision cameras in New Zealand:
You don’t.
All I wanted to buy is a genuine Hikvision camera locally (with correct Language flag set in firmware, and basic support).
I went onto global Hikvision website and checked listed distributors for New Zealand. I also e-mailed Hikvision regarding the New Zealand distributor.
The Hikvision website lists Atlas Gentech as their distributor. This was confirmed via email as well.
From quick look on Atlas Gentech website it appears that they are deal with trade only (ie wholesale shop).
I have contacted Atlas Gentech, and they confirmed that you need to be a company to deal with them.
They provided me with couple of their customers I could enquire regarding buying Hikvision cameras.
Both of the contacts given were security companies (not a retail shop), as well as what appeared to be “one-man” operations. The security companies naturally have no interest in selling hardware to customers, they are more naturally inclined to sell services (ie. installation and monitoring). There is simply a conflict of interest there to start off.
I have contacted these companies. Only one responded.
Originally I have enquired about DS-2CD2032-I with 12 mm lens. I have been told that it is unavailable and was given two options:
DS-2CD2232-I5 for approximately $700NZ + GST (~$620USD). BTW I have bought DS-2CD2232-I5 from Aliexpress for $95USD. The most expensive DS-2CD2232-I5 on Amazon was around $240USD, while the US version (with correct language flag) is sold around $170USD.
and DS-2CD4232FWD-I a vari-zoom/vari-focal camera for approximately $1200 + GST (~$1073USD). The DS-2CD4232FWD-I can be bought for about $400 USD on Aliexpress.
The camera bought from Aliexpress physically does not differ from cameras that being sold here. The only difference is the language flag (which is fixable), and obviously support/CGA.
I also found that the Aliexpress sourced camera can be bought on trademe for $250NZ ($194USD).
I had expectations of paying maybe 2 times of the US Version, the expectations were completely shattered when Atlas Gentech confirmed that quoted $700NZD + GST was reasonable (and not bullshit RRP price). lets assume that US Version retails for $200USD (a bit higher than $170USD on Amazon). The $620USD is over 3 times of the retail price of US Version.
Remember when camera sold on Aliexpress for $95USD the Alixpress makes a cut, the seller on Alixpress makes a cut and the Hikvision still makes a profit. Looking at the cost of Ambarella SoC (wholesale around $20USD), the cost of making the camera is around $40-50USD. Selling camera for $620 USD is pure greed.
Hikvision is blatantly ripping off New Zealanders, because they can. Shame on you Hikvision for doing so, and shame on you for artificial differentiation of the markets by setting the language bit. Geo-locking in Internet world is stupid and futile.
Shame on you Hikvision for violating GPL as well, since when I bought the cameras there was no mention of the licence, and the camera definitely uses GPL licensed software. The GPL code requests were fallen to silent ears. This company is behaving like a greedy parasite, taking from community and not giving anything back.
Bought it from Aliexpress as I have completely given up on sourcing genuine camera in New Zealand.
Ordered with 12mm lens option for the driveway monitoring.
Internally it is exactly the same as Hikvision DS-2CD2032-I IP camera. Same CPU/RAM/Sensor/Firmware.
Externally it is rather large and bulky. It is all metal construction, except the default mount – flimsy plastic. I have used an arm from an old CCTV camera, it bolted perfectly fine to one of the bottom threaded holes. It had another threaded hole at the back giving plenty of mount options. The hood adjustment did not make any sense, fully extended at around half of centimetre, it looks like the screw (which was also a bit too small) holding it was put in slightly wrong place.
One thing I didn’t like is the cable was external, on DS-2CD2032-I it is routed internally through mount allowing for more discreet installation. I simply used split piece of 20mm conduit around it to make it more difficult for cutting.
The IR LEDs are very powerful, in fact they are too powerful as number plates are not visible due to excess light bounced from reflective surface. As bonus it lit up the area for other camera.
With 12mm lens it has sufficient zoom to clearly see along our long drive way.
continuation from Hikvision DS-2CD2032-I IP camera
As a quest to solve the dropped frames issue I have upgraded the firmware from Version V5.2.0 to V5.2.3.
This was done successfully, except the interface has switched to Chinese (and no option to choose otherwise).
Model DS-2CD2032-I
Serial No. DS-2CD2032-I20141014CCCH482137191
Firmware Version V5.2.3 build 141024
Encoding Version V5.0 build 140714
Basically the camera I bought supposed to be international version but upon inspecting the serial number it looks like it is Chinese.
The Chinese versions have CCCH while international version have CCWR in their serial numbers. Cameras that sold as “International Version” on amazon are actually Chinese versions with multilingual interface. The correct camera to buy is “English Retail” version. Caveat Emptor!
I found a workaround without modifying the firmware: drop into developer console in the browser and type the following:
javascript:chooseLanguage("en");
There is also a hack by CBX here . This is a permanent solution, but I will probably not go that way since I don’t need use WebUI very often. Shame on you Hikvision for having regions! Since it is same hardware and software anyway…
So far with new firmware I cannot see any changes whatsoever (that concern me).
The loadavg is still very high (around 4). Not sure about original problem, will need to run the camera for a while (since it does not manifest itself immediately).
I have contacted CBX and he as kind enough to provide me with the patch for token amount of money in exchange.
The camera now has correct language ID:
# prtHardInfo
...
language = 1
...
Dahua IPC-HFW4300S
Bought from amazon for $110USD (via Youshop).
I have decided to go with Dahua as replacement of my recently purchased Hikvision DS-2CD2032-I, due to severe stream errors (shitty firmware?) on DS-2CD2032-I.
UPDATE: firmware update fixed the errors with DS-2CD2032-I.
UPDATE: the stream errors are due to nature of these cameras and UDP. The TCP stream is perfect.
Youshop managed to “lose” it, I had to “recover” it from unclaimed pile.
The camera described here was sourced from Amazon.
It came in a retail box, but with Chinese labels. The instructions where also Chinese.
The camera came with preconfigured IP address of 192.168.1.108.
The default username is admin, password is also admin.
WebUI
The web interface is somewhat OK, no video stream visible in any browser on Linux (requires ActiveX?). Typical shitty Chinese webUI.
The video settings do work.
The config Export does not work.
“Live” tab (or anything having video output) is completely useless without even bothering to tell me that “plugin” is missing.
When these idiots will learn that not everyone uses IE6?
The camera has exactly same issues with RTSP and UDP, when used with ffmpeg as . When used with -rtsp_transport tcp
flag the stream is stable.
The image quality is good (very close if not better than Hikvision DS-2CD2032-I).
Streams
The camera has 3 streams (configured via webUI, 3rd stream disabled).
The trick was to find out the stream URL that works without authentication.
Main stream: rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=0&proto=Onvif
Sub stream: rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=1&proto=Onvif
Sub stream (disabled by default): rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=2&proto=Onvif
Note: proto=Onvif
is the key to bypass authentication.
The snapshot URL is: EDIT: the 9989 port access is unreliable, the reliable snapshot URL is: http://{CAMERA_IP}:9989/
http://{CAMERA_IP}/cgi-bin/snapshot.cgi
Interesting that switch to/from IR is gradual.
Another very good thing about this camera is that it runs High profile on their h264 streams:
Metadata:
title : RTSP Session/2.0
Duration: N/A, start: 0.009967, bitrate: N/A
Stream #0.0: Video: h264 (High), yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], 25.33 fps, 100 tbr, 90k tbn, 49.95 tbc
/proc/cpuinfo
:
Processor : ARMv6-compatible processor rev 5 (v6l)
BogoMIPS : 526.25
Features : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant : 0x1
CPU part : 0xb36
CPU revision : 5
Hardware : Coconut
Revision : 13ec300a
Serial : 0000000000000000
kernel:
Linux version 2.6.38.8 (jenkins@localhost.localdomain) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 PREEMPT Tue Sep 30 18:53:02 CST 2014
free -m:
total used free shared buffers
Mem: 131 83 47 0 0
-/+ buffers: 83 47
Swap: 0 0 0
df -h:
Filesystem Size Used Available Use% Mounted on
ubi0:romfs 4.9M 4.9M 4.0K 100% /
devtmpfs 65.6M 0 65.6M 0% /dev
tmpfs 65.7M 576.0K 65.2M 1% /var
ubi1_0 21.1M 14.3M 6.8M 68% /usr
ubi2_0 708.0K 60.0K 648.0K 8% /mnt/custom
ubi3_0 708.0K 72.0K 636.0K 10% /mnt/pd
ubi4_0 4.9M 3.3M 1.5M 68% /mnt/web
ubi5_0 708.0K 84.0K 552.0K 13% /mnt/syslog
ubi6_0 708.0K 232.0K 404.0K 36% /mnt/mtd
ubi7_0 708.0K 44.0K 592.0K 7% /mnt/backup
Similar to Hikvision DS-2CD2032-I this camera runs very "hot" CPU wise: sitting around loadavg 10.
In all aspects IPC-HFW4300S is very similar to DS-2CD2032-I hardware wise. Same CPU, same clock frequency, similar amount of RAM (128MB for Dahua and 96MB for Hikvision).
Linux wise they run same kernel version (2.6.38.8). Although Dahua runs older busybox version (v1.18.4 vs Hikvision v1.19.3).
Both of these manufacturers violate GPL badly..
It looks like the developers at Dahua use Jenkins, specifically this error message gives it away:
00:00:08|[prc] ERROR (/home/jenkins/jk_slave_centos6/workspace/IPC_DH3.S0507_IPCAmbarella2.420/tmp_build_dir/PRC_A5S/build/platbuild/../../src/module/submod/i2c/prc_i2c.c|I2C_isr|454): I2C0 dev0x68 wait ack timeout
Even though Dahua are very protective with the firmware, I found newer firmware here (will install once I get shell on the camera):
http://wrightwoodsurveillance.com/forum/thread-89.html
I have upgraded firmware from:
Software Version 2.210.0000.11.R, build : 2014-01-15 WEB Version 3.2.1.164499
to:
Software Version 2.420.0003.0.R, build : 2014-09-30 WEB Version 3.2.1.223527
without any issues...
The rest
Now for the shitty part of the camera:
The camera is configured with telnet.
There is no SSH service. It does not look like telnet can be disabled from WebUI (or SSH enabled).
Trying to login to telnet with default admin password fails.
I have managed to extract root hash from firmware file (see here):
$1$jSqQv.uP$jgz4lwEx2pnDh4QwXkh06/
Googling it reveals nothing.
After running JtR for a few hours on GPU, I got the password as 'vizxv' (without the quotes).
The password did not work for any of user combinations...
Still trying to access the telnet...
UPDATE: as per these findings telnet username is admin
and password is 7ujMko0{webui_admin_password}
, so if webUI admin password is admin
then the telnet password is 7ujMko0admin .
Pros:
Good picture quality.
Solid metal construction.
High profile is available for h264 streams.
Cons:
Really shitty support.
No official firmware available.
Windows-centric Web UI.
Telnet is always ON.
Telnet is set up with a different, hard coded root password (Dahua back door).
RTSP urls are a bit long.
UPDATE: after upgrading the firmware the "Live" tab now has controls, as well as option to download plugin. Well almost, the download link http://{camera_ip}/webplugin.tar.bz2
gives you nice 404. Fucking idiots.
The config import/export still does not work.
NOTE: if camera is used with OpenCV make sure to add ?tcp at the end of the url!!! This camera is even more buggy than Hikvision DS-2CD2032-I and it drops UDP packets on even small sub streams. Here is example of the url needed for OpenCV to work reliably:
rtsp://{camera_ip}:554/cam/realmonitor?channel=1&subtype=0&proto=Onvif?tcp
Bought it in July 2012, from gowifi.co.nz, for ~$200NZD.
At the time it was good value for money.
It is 720p PoE IP camera.
Image (night, with artificial light):
Streams:
There are four rtsp streams:
Main stream: rtsp://{CAMERA_IP}/live/ch00_0
(1280×720)
Sub stream 1: rtsp://{CAMERA_IP}/live/ch01_0
(640×368)
Sub stream 2: rtsp://{CAMERA_IP}/live/ch02_0
(320×176)
Sub stream 3: rtsp://{CAMERA_IP}/live/ch03_0
(160×96)
There are four snapshot urls:
Main stream: http://{CAMERA_IP}/snapshot.cgi?chan=0
(1280×720)
Sub stream 1: http://{CAMERA_IP}/snapshot.cgi?chan=1
(640×368)
Sub stream 2: http://{CAMERA_IP}/snapshot.cgi?chan=2
(320×176)
Sub stream 3: http://{CAMERA_IP}/snapshot.cgi?chan=3
(160×96)
Technical info:
Linux AirCam 2.6.28 #1 PREEMPT Sun Jun 9 01:03:42 EEST 2013 armv5tel GNU/Linux
Processor : FA626TE rev 1 (v5l)
BogoMIPS : 532.48
Features : swp half thumb
CPU implementer : 0x66
CPU architecture: 5TE
CPU variant : 0x0
CPU part : 0x626
CPU revision : 1
Hardware : Faraday GM8126
Revision : 0000
Serial : 0000000000000000
total used free shared buffers
Mem: 127712 103684 24028 0 3784
-/+ buffers: 99900 27812
Swap: 0 0 0
Pros:
Very good web UI (Chinese manufacturers should learn from it), everything works on non-Windows OS, even live view.
Stable RTSP stream.
Ran without issues for over 2 years.
Fantastic support from Ubiquiti (firmware availability, forum, and documentation is great).
Cons:
Average image quality.
No IR.
Low sensitivity (performs poorly in low light).
Noise correction is overzealous (the image has oil painting feel).
Flimsy plastic body and mount.
Camera is not 802.3at or 802.3af compliant so does not work with ; it needs it’s own 24V injector.
The Ubiquiti even provides their own version of Zoneminder. Although I used it for short period of time, I found it is too CPU intensive and because it stores the video clips as collection of images, I found it a bit impractical. I settled for my own motion detection (built python OpenCV).
Probably will be retiring it in favour of more modern camera…
Very sturdy all metal construction. Quality casting and solid mount.
Bought it on amazon for ~$120 USD.
Seller didn’t ship to NZ so got it sent via Youshop.
It is a PoE camera, so I hooked it up via TP-LINK TL-SG1008PE 8-Port Gigabit PoE Switch
The camera came preconfigured with unusual static ip address of 192.0.0.64. In Windows world it supposed to be configured via some utility, so theoretically it is not a big deal. All I had to do is RTFM and add the 192.0.0.1/24 to the machine I was trying to configure the camera from.
The web interface can be used with OS independent browser for basic configuration (beyond that you are out of luck, unless you use Windows).
It came with firmware Version V5.2.0 build 140721 and encoding Version V5.0 build 140714.
The picture quality is very good (substantially better than Ubiquiti AIRCAM HD)
Night+Light (low level flood light):
There are two streams that can be configured independently.
I have configured one for 1080p/15fps (not 25fps due to increased frequency of stream errors, see below in the issues), and another for 320×240/10fps for motion detection. The key issue is to increase I-frame frequency to at least every 10 frames (due to RTSP stream errors).
How to access camera:
Default username/password: admin/12345
Main stream URL: rtsp://{CAMERA_IP}/Streaming/Channels/1
(although rtsp://{CAMERA_IP}/
works too.)
Sub stream URL: rtsp://{CAMERA_IP}/Streaming/Channels/2
Main stream snapshot URL: http://{CAMERA_IP}/Streaming/channels/1/picture
Sub stream snapshot URL: EDIT: sub stream snapshot is exactly same as main stream snapshot, in fact using any number above 0 in url /Streaming/channels/{X}/picture leads to same result.http://{CAMERA_IP}/Streaming/channels/1/picture
Technical details:
Linux version 2.6.38.8 (root@HIK-RD-CI-Frontend) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ).
CPU: ARMv6-compatible processor [4117b365] revision 5 (ARMv6TEJ), cr=00c5387f
# cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 5 (v6l)
BogoMIPS : 525.92
Features : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant : 0x1
CPU part : 0xb36
CPU revision : 5
Hardware : Coconut
Revision : 13ec300a
Serial : 0000000000000000
# free -m
total used free shared buffers
Mem: 95436 89024 6412 0 528
-/+ buffers: 88496 6940
Swap: 0 0 0
It looks like it is based on ambarella chipset…
The camera runs “hot”, with loadavg hovering around 5 (it sometimes for no apparent reason gets to 10, and causes issues).
The stream can be accessed via avplay/ffplay:
avplay -rtsp_transport tcp -i rtsp://$IP:554
(or VLC). To do so without authentication it must be disabled from web UI.
It would have been an awesome camera if not for the issues…
Web UI (if you can call it “web” with all the windows centric crap)
Live View:
Note: MJPEG selection is also broken. Only way to get Live View working is to install vlc plugin for Firefox.
Image Configuration:
Shit be broken: none of the things in the image settings sub-menus can be changed except the IR schedule.
Maintenance:
More shit be broken: I guess the idiots who built it never actually tested this page, beyond IE. The export config button does nothing. Thank you Hikvision for working reboot button!
The BIG issues…
UPDATE: As per , the firmware update resolved 99% of the stream error issues.
Most show stopping issue is (are) stream errors. Currently the camera is completely unusable with UDP RTSP stream. It is usable to a degree when stream is forced to TCP (-rstp_transport tcp).
The stream errors get worse when load average reaches 10 (it normally does so after 24-48 hours of operation). Once it hits 10 the camera needs to be rebooted to be usable again (otherwise every second or third frame is corrupted).
The Stream errors look like this:
...
[h264 @ 0x20fdd20] error while decoding MB 71 13, bytestream -22
[h264 @ 0x20fdd20] concealing 6578 DC, 6578 AC, 6578 MV errors in I frame
....
[h264 @ 0x20fd4a0] Cannot use next picture in error concealment
....
[h264 @ 0x20fdd20] left block unavailable for requested intra4x4 mode -1 at 0 62
...
[h264 @ 0x20fee20] cabac decode of qscale diff failed at 89 48
...
quick google search shows other people reporting same thing for this camera.
I found a random Russian site describing the issue with different camera from Hikvision, specifically stating that the issue started with firmware v5.X (while v4.X was fine). Here: http://anteh.ru/notes/freebsd/notes_ipcamconfig.html
I have contacted Hikvision regarding RTSP erros, they never replied… From google searches it looks like Hikvision provides no support whatsoever.
The “web” interface is a joke. When logging in you are greeting with multiple of “no plug-in found”. Only basic configuration can be changed (thank you for that Hikvision, otherwise I would be returning the camera).
Image setting does not work (the sliders do nothing), out of all settings in Image tab only thing that works is the IR schedule.
The export config does not work, not sure about reset to defaults or update firmware. The layout is broken on that tab as well.
It looks like the “web” interface never been tested on anything other than IE. Making web interface windows-centric is very stupid and short sighted. You can install VLC plugin in firefox for Live-View to work, beyond that you “need” Windows. Good thing is that I will not be using web interface very often.
Someone needs to make openwrt/tomato style project for IP cameras, to liberate the users from stupid web interfaces that these cameras come with. It is ironical that you need Windows OS to manage a Linux device. We can thank piracy for windows “developers” that flooded the market and creating crappy software like the web interface on this camera.
Admitting defeat I have bought Dahua IPC-HFW4300S. Initial reason I settled for Hikvision (and not Dahua) was simply because of the firmware availability. Dahua does not provide firmware updates whatsoever, stating that the only official suppliers are provided with firmware (good luck finding one in NZ).
It seems to me with all these cheap cameras the whole firmware thing is a big GPL violation….
UPDATE: I managed to borrow a windows machine, and web ui still didn’t work until I used IE and installed their activeX plugin.
Why Ubiquiti (who BTW do not specialise in IP cameras) can do a nice web interface that works on all devices while Hikvision cannot?
Leave a Reply