Raspberry Pi Surveillance Monitor

Cameras are everywhere.

I noticed at work that we had a few IP cameras hooked up in the covered parking spots. I thought to myself how awesome it’d be if I had an awesome way to display the feed of these cameras right off the Raspberry Pi.

What you’ll need.

I’ve found the best results with the following:

First run though

I’ve never displayed more than one video at a time. So I didn’t know how much processing power would be required to output 6+ videos at a time. Needless to say I was very impressed by how well it decoded 6 videos - I decided to try outputing 9 videos and the Raspberry Pi B+ handled it BEAUTIFULLY.

The monitor I’m using has a resolution of 1600x1200. I want to take full advantage of it by displaying 9 videos at a time. The end results might not apply to all monitor resolutions- so keep that in mind.

Bump the GPU Memory

We will need to dedicate more RAM to the GPU in order to handle the increase load in the video stream. We will run the “sudo raspi-config” and go to “Advance Options” then select “Memory Split”. I chose 128MB which effectively doubles the onboard GPU memory available.

Before I applied this configuration change - the sizing of the Omxplayer windows were sporadic and I could only stream two videos at a time.

Finding the stream URL

Disclaimer - I’m providing the walk-through on how I found my stream URL and won’t apply to all situations.

Admittedly this took me a fair share of finding out. So I decided to include this on this writeup. What we need to find out is the RTSP URL of the camera streams in questions. I navigated to the camera’s interface that displays the feed in the browser. I entered my username and password and I’m now watching the live feed through my browser.

Camera login

Now that we’ve authenticated it’s time to find the stream URL + parameters. I used Firefox’s inspector tool to inspect the video element on the page:

Embed code

The exact code was:

<embed id="qt_video" src="sample.mov" qtsrc="rtsp://172.16.2.110:554/cam/realmonitor?channel=1&amp;subtype=0&amp;authbasic=Og==" bgcolor="#585858" scale="ToFit" autoplay="true" loop="false" controller="false" wmode="transparent" type="video/quicktime" pluginspage="http://www.apple.com/quicktime/" height="100%" width="100%">

The interesting bits were:

I came up with the following URL to try with Omxplayer:

rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=1&subtype=0

Omxplayer test

The RTSP protocol allows basic authorization through the formation of the URL. I had to wrap the entire command in a string and execute it because the password I was using intefered with normal command line execution (The password had an exclamation mark in it - womp womp).

The command I use for my initial testing was:

sh -c 'omxplayer --win "0 0 800 600" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=1&subtype=0; exec bash'

Make sure to translate the correct IP, username and password to the IP camera you have on your network. If everything went well - you should now have a live video feed in the top left of your monitor.

The grid

At first I tried a 2x2 layout on my 1600x1200 monitor. It worked wonderfully. Doing the math was the hard part. I came up with the following script (borrowed from t3chadd1ct’s blog):

#!/bin/bash
screen -dmS camera1 sh -c 'omxplayer --win "0 0 800 600" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=1&subtype=0; exec bash'
screen -dmS camera2 sh -c 'omxplayer --win "800 0 1600 600" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=2&subtype=0; exec bash'
screen -dmS camera3 sh -c 'omxplayer --win "0 600 800 1200" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=3&subtype=0; exec bash'
screen -dmS camera4 sh -c 'omxplayer --win "800 600 1600 1200 1080" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=4&subtype=0; exec bash'

This worked wonderfully by executing all the commands concurrently by running detached in the screen command. By running that script above you should now have all four feeds on the network being streamed at the same time. Wünderbar!

You may have notice the extra parameters for the Omxplayer command. The –win parameter will accept 4 arguments. X1, Y1, X2, and Y2. These are coordinates that translate to your monitor:

omxplayer --win x1 y1 x2 y2

I noticed that CPU usage on my Raspberry Pi B+ wasn’t even being touched. I was averaging out at a whopping 30-40% CPU load! Time for some more video streams:

#!/bin/bash

# First row
screen -dmS camera1 sh -c 'omxplayer --win "0 0 800 400" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=1&subtype=0; exec bash'
screen -dmS camera2 sh -c 'omxplayer --win "800 0 1600 400" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=2&subtype=0; exec bash'

# Second row
screen -dmS camera3 sh -c 'omxplayer --win "0 400 800 800" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=3&subtype=0; exec bash'
screen -dmS camera4 sh -c 'omxplayer --win "800 400 1600 800" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=4&subtype=0; exec bash'

# Third row
screen -dmS camera3 sh -c 'omxplayer --win "0 800 800 1200" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=5&subtype=0; exec bash'
screen -dmS camera4 sh -c 'omxplayer --win "800 800 1600 1200" rtsp://USERNAME:[email protected]:554/cam/realmonitor?channel=6&subtype=0; exec bash'

With a 2x3 monitor and 6 total videos - I was pushing the average load of the Raspberry Pi B+ to around 50%. Still impressive!

Stopping the streams

You can issue the following command to end all instances of the Omxplayer:

sudo killall omxplayer.bin

The result:

Now I feel a bit big brotherish:

Result

Known issues