In this final post I’ll show how I made the camera video feed available on the Internet.

One thing I wanted from the outset was for Internet clients not to make direct connections to the camera itself. I was a little worried about the ability of the web server and CPU in the camera to cope with multiple clients, and also the security implications of direct access. A second requirement was to have multi platform access – that is, desktop and iOS. This potentially means different streaming video formats.

We have one linux server in the house, which is used for many different things and runs virtual machines. My back-of-an-envelope plan looked something like this:

First step was to create the VM, but remember that the camera feed is in a DMZ using a VLAN, so the VM must live there too. In KVM it’s possible either to send all traffic to a guest system and let it process the VLANs or, you can separate the tagged VLAN traffic in the host system so the guest is dumb and just sees untagged frames. Clearly the latter is preferable so that were the guest to suffer attack from the Internet, it ought not to be able to put traffic onto the house workstation network. The guest is completely within the DMZ.

With that done and a basic Ubuntu system installed, I started work on Apache and VLC (the Swiss Army Chainsaw of video processing). First up, VLC…

Luckily the camera’s video feed comes in MJPEG format with a discoverable URL. The idea is to take this feed, duplicate it, and transcode the respective feeds into something suitable for a desktop browser and for iOS. As a bonus, I’ll timestamp the video to make it easy to tell if the transcoder has crashed (the timestamp would be wrong). After a lot of reading online about how to configure VLC I came up with the following monstrosity:

/usr/bin/cvlc -I dummy http://guest:guest@172.16.30.10:8888/videostream.cgi?rate=0
  --sout='#duplicate{

    dst="transcode{
      width=320,heigh=240,fps=25,vcodec=h264,vb=256,acodec=none,
      venc=x264{profile=baseline,level=30,keyint=30,ref=1},
      sfilter=marq{marquee=\"[%Y-%m-%d %H:%M:%S]\",position=8,size=18}
    }:std{access=livehttp{
        seglen=10,delsegs=true,numsegs=5,
        index=/var/www/streaming/cats.m3u8,
        index-url=/streaming/cats-########.ts},
      mux=ts{use-key-frames},
      dst=/var/www/streaming/cats-########.ts}",

    dst="transcode{
      width=640,heigh=480,fps=25,vcodec=theo,vb=512,acodec=none,
      sfilter=marq{marquee=\"[%Y-%m-%d %H:%M:%S]\",position=8,size=18}
    }:http{mux=ogg,dst=127.0.0.1:8081/catcam.ogg}"

  }'

Of the two transcodes (“dst=”), the second is more straightforward. It creates an Ogg format stream using the Theora video codec, which modern browsers should be able to cope with. This is a video stream being served from VLC’s built-in web server, so I’ll need to proxy it via Apache. The configuration also applies a filter (“sfilter=”) to add a timestamp on the video stream.

The first transcode uses the new HTTP Live Streaming support in VLC. This is a rather elegant specification from Apple (which is why I selected it for the iOS clients) for simple and efficient delivery of streaming video. It creates a set of files and assumes you have a web server to serve them. The files each contain a few seconds of video, and the client retrieves them and plays one after another. The “######” templates an incrementing number within the segment filename. Again, the timestamp is added to the video stream.

CPU load for the above runs at about 60% (in the VM) on the dual core Athlon X2 245e processor. I wrapped the above in an Upstart init file, and just in case VLC gets its knickers in a twist, I added a cron job to periodically stop and start the service.

Now on to Apache. It needs to proxy the Ogg stream and serve the Live Streaming files, and prevent any other access to the web server:

# redirect any non-cat requests to the cat index.html
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/streaming/cats.*
RewriteCond %{REQUEST_URI} !^/stream/catcam.ogg$
RewriteCond %{REQUEST_URI} !^/index.html$
RewriteRule ^(.*) http://%{HTTP_HOST}/index.html [R,L]

ProxyReceiveBufferSize 16384
ProxyRequests On
ProxyVia On
ProxyPreserveHost On

<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>

# VLC server stream
ProxyPass /stream/catcam.ogg http://localhost:8081/catcam.ogg
ProxyPassReverse /stream/catcam.ogg http://localhost:8081/catcam.ogg

Last but not least for this server, we need a web page which offers up the two video streams. This uses an HTML5 video tag:

<!DOCTYPE html>
<html>
    <head>
        <title>Cat Cam</title>
        <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
        <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
    </head>
    <body>
        <h1>Cat Cam</h1>
        <video id="video" autoplay="autoplay">
            <source src="/streaming/cats.m3u8">
            <source src="/stream/catcam.ogg" type="video/ogg; codecs=theora">
            Your browser doesn't appear to support the HTML5 <code>&lt;video&gt;</code> element.
        </video>
    </body>
</html>

All that remains is to enable a NAT rule and firewall pinhole on the home router for the web server (which is, of course, in the DMZ network connected directly to the router).

Let’s see the end result, taken on my iPhone this evening, also demonstrating the automatically activated night vision mode:

It’s nice to be able to check in on the wee beasties when I’m out at work. Other than a lot of reading about VLC, it wasn’t particularly difficult to do, and I think the end result is really quite good.

This post will cover the network changes made at home for the camera, and in the next, how it was made available on the Internet (for us to check up on away from home).

Naturally the camera needed to go on our home network, but I was a little wary of what shenanigans its software might get up to. For example I know the camera automatically registers itself with a public dynamic DNS service; it’s possible to update the firmware to disable that feature.

A safe design is to set up a DMZ, and put the camera on that. Our workstations in the house would be able to talk to the camera, as would the Internet, but the camera would not be permitted access to our workstations. Without dedicated cables for the DMZ I needed to enable a VLAN on the network. Thankfully the switch, wireless access point, and router we use support VLANs.

The switch is a Netgear GS108E, an eight port gigabit device (it lives in the loft, and I ran Cat5e inside the walls to recessed sockets in each room). It’s a simple job to enable a tagged VLAN on the ports to the router, the wireless access point, and our linux server (which I’ll come back to, next time).

I set up a new SSID on the wireless access point dedicated to the camera, which placed all traffic onto this new tagged VLAN. Now the camera and router were linked, via the switch, on a separate path from the rest of the house.

At the router I needed to configure a VLAN subinterface and add some access control lists to set up the DMZ access rules I mentioned above. The DMZ of course needs its own subnet so I gave it a new /24 network.

So far, so good: workstations in the house can now browse to http://172.16.30.10:8888/ (the new DMZ network, via the router) and log in to the Loftek camera to see video of the cats. The camera can only initiate connections to the Internet, or reply to requests from workstations in the house.

In the next post, I’ll talk about using our home linux server to make the camera video feed available on the Internet.

You may recall from blogs passim that our cats, since moving to the current house, live in a heated shed in the garden. I think they love it:

• cushioned, heated “igloo” beds,
• thermostatically controlled heater for winter,
• a few shelves so they can sit in different places or at the window to look out,
• a cat flap which lets only them enter and leave,
• carpeted floor(!).

A true cat palace, I think you’ll agree. We visit several times a day for feeding and cuddles, and mostly they’re out in the fields behind our house, failing to catch any wildlife.

One thing I miss is just being able to check up on them any time, to see that they’re okay. When they were in the house, of course you’d see them all the time. A good friend of mine mentioned cheap wireless webcams (or CCTV cams).

In this blog post and probably one other, I’ll talk about my selection and installation of the camera and how I made it Internet accessible (well, it’s still “Cats and Code” after all). Here’s an executive summary of the story:

Enough sleeping... it's time for hunting.

Several companies make so-called Internet-enabled cameras, for different budgets and with varying software quality. At the domestic end of the market are:

• Axis, which might be more appropriate for business than the home, because the quality is high, with a price to match.
• Foscam seem to be the one everyone goes for if they want a little home security on a small budget, with quality.
• There are several far-east clones of the Foscam, many sharing the same designs, for example Loftek.

After some research online and a trawl through the Amazon marketplace, I selected the Loftek CXS 3200 Black. I didn’t want to spend much money at all, in case no camera would work inside the shed, but this model at least had good reviews and several useful features.

Like most similar models the camera can pan and tilt and runs an embedded web server so you can view the video and control the camera. The 3200 automatically switches between day and night vision modes, but interestingly includes the “IR cut” feature. This filters infra red when in day vision mode, to solve the common problem of (e.g.) green foliage appearing purple.

The camera is, of course, wireless, which is handy because the shed has power but no networking. I mounted the camera upside-down as in the image below, and was pleased to find the 3200 has settings to invert the image and pan/tilt controls so everything appears the right way up when viewing the video feed.

Loftek CXS 3200 Black

In the next post I’ll talk about the technical set-up of the camera on our home network.