IP Cameras

From Leeds Hackspace Wiki
Jump to: navigation, search

Fligg(?) acquired a cheap Chinese IP camera for testing. If we can get it to behave, the plan is to acquire more and deploy them around the space.

IP address is hard-coded at telnetd is running on port 23, root password is "xmhdipc".

Language is hard-coded as Chinese. Only a single byte to change, but awkward as it's on a cramfs filesystem on a native MTD device with presumably very limited write cycles. Big 5Mb binary /usr/bin/Sofia does everything: streams rtsp, runs web server. Tries to connect to secu100.net for evil.

Moar data

Chipset is Hi3518 (datasheet). It has an ARM926EJ-S and 40Mb RAM.

Contents of the included CD (160Mb).

Someone else playing with such a camera. Includes SDK, local mirror (600Mb).


The camera has 8 megabytes of NOR flash (64K pagesize), split into six partitions. These are accessible as /dev/mtdblock{0,1,2,3,4,5}.

  • /dev/mtdblock1 on / type cramfs (ro,relatime)
  • /dev/mtdblock2 on /usr type squashfs (ro,relatime)
  • /dev/mtdblock3 on /mnt/web type cramfs (ro,relatime)
  • /dev/mtdblock4 on /mnt/custom type cramfs (ro,relatime)
  • /dev/mtdblock5 on /mnt/mtd type jffs2 (rw,relatime)

U-Boot config (located at flash offset 0x30004, preceded by CRC32):

   bootcmd=fload;bootm 0x82000000
   da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
   du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
   dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
   dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
   dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
   up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
   ua=mw.b 0x82000000 ff 1000000;tftp 0x82000000 upall_verify.img;sf probe 0;flwrite
   tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 uImage; bootm 0x82000000
   dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
   bootargs=mem=40M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:256K(boot),3520K(romfs),2560K(user),1280K(web),256K(custom),320K(mtd)
   ver=U-Boot 2010.06 (Apr 07 2012 - 17:11:2)


    Linux LocalHost 3.0.8 #96 Sat May 17 13:27:56 CST 2014 armv5tejl GNU/Linux


   Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
   tcp        0      0 *               LISTEN      700/upgraded
   tcp        0      0  *               LISTEN      721/Sofia
   tcp        0      0 *               LISTEN      721/Sofia
   tcp        0      0 *               LISTEN      721/Sofia
   tcp        0      0   *               LISTEN      721/Sofia
   tcp        0      0    *               LISTEN      721/Sofia
   tcp        0      0  *               LISTEN      709/dvrHelper
   tcp        0      0    *               LISTEN      708/telnetd
   udp        0      0 *                           721/Sofia
   udp        0      0*                           703/searchIp
   udp        0      0  *                           721/Sofia
   udp        0      0   *                           -
   udp        0      0 *                           721/Sofia

(Would be really nice to dispense with some of these.)


The following will save camera output to a file.

  gst-launch-1.0 rtspsrc location='rtsp://' ! queue ! rtph264depay ! h264parse ! matroskamux ! filesink location=cam.mkv

The result isn't seekable but the following makes it so:

  mkvmerge -o cam-seekable.mkv cam.mkv

I've heard reports that UDP streaming is less reliable than TCP. More testing needed.


  • 0.sdp is 1280x720, 11fps, H.264, ~1Mbit/sec
  • 1.sdp is 352x288, 12.5fps, H.264

(However the sensor claims 25fps.)

Things to do

On the camera:

  • Get nfs mounting to work, get access to sane userland.
  • Get DHCP client installed.
  • Get NTP client installed.
  • (Optional) Make a real rootfs with OE or embdebian or similar, boot it over NFS.


  • Logging infrastructure. Storing the output of one camera stream should take about 15GB/day.
  • JPEG output for web page display
  • (Optional) Transcoding of the stream for viewing in web browsers that lack H.264 support