prupert

Make Your Own Baby Night Vision Video Monitor…Again

So, a while back, I posted about how to hack your own baby monitor. However, it was all fairly easy and didn’t require that much geekery. This time, however, I have gone all out and have produced what I think is a neat little set-up.

I am using a small thin-client PC, an HP T5700 with only a 750Mhz Transmeta Crusoe CPU and 512MB Ram. My PC is low-power and silent (perfect as it is running in our bedroom). I am also using a cheapo Nightvision Webcam from eBay (make sure it is true nightvision and not just some LEDs that you can turn on and off – the description needs to  say that the webcam uses IR LEDs and that they are “invisible to the human eye”) with a combined microphone.

To stream the video from the webcam, I use the rather excellent motion via sudo apt-get install motion. You’ll need to mess with the settings in motion.conf to activate the webcam server and to allow access from users other than localhost, for reference, here is mine. Then, all you need do is set motion running at boot, there is startup script included with motion when you install it, but I am pretty sure that is borked, so I just added “motion” to my /etc/rc.local file. Thus, to view the video, I simply browse to the http://IPADDRESSOFPC:8081, which is easily opened in VLC.

To stream the audio from the microphone on the webcam turned out to be a much more difficult process, as I detailed in the post prior to this one. Suffice to say, FFmpeg came to my rescue, so I simply run the command:

ffmpeg -f oss -i /dev/dsp -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://234.5.5.5:1234

at boot and my microphone is miraculously streamed to rtp://234.5.5.5:1234, which I can open in VLC (if you are using Linux, you have to use the most recent version of VLC, i.e. 1.1.1, previous versions don’t play well with rtp streams on Linux).

I use the following simple script on my laptop to view both streams, so I can see and hear our lovely daughter, even when she is sound asleep in a dark room:

#!/bin/bash
echo "starting vlc"
VPID=( $(ps -e | grep vlc | awk '{print $1;}'))
if [ $? = 1 ];then
echo "error getting vlc PID, exiting"
exit
fi
while [ -n "$VPID" ];do
kill $VPID
VPID=( $(ps -e | grep vlc | awk '{print $1;}'))
done
cvlc http://192.168.1.5:8081 &
PID1=$?

echo video status $PID1
if [ "$PID1" == "1" ];then
echo "error starting vlc video"
exit
fi
vlc rtp://234.5.5.5:1234 --equalizer-bands="0,0,15,15,15,-20,0,0,0,0" &
PID2=$?

echo audio status $PID2
if [ "$PID2" == "1" ];then
echo "error starting vlc audio"
exit
fi
exit

This set-up has worked perfectly for the last week and even my wife appreciates my geeky skills on this one! Plus, I have a very small WiFi router (a La Fonera2) which makes the system completely portable, as the video feed can be viewed on pretty much any device. This now frees my IP webcams for the job they are much better suited for, home security. The end result are videos of this quality (to be clear, this is a freezeframe from the video feed, taken in a pitch black room):

So, why do all this? Well, for one, it can only up your geekery skills But also, motion has some cool features, that, for example, let you take regular photos, allowing you to make cool time-lapse videos of your baby as she grows and develops (or sleeps through one night – man they move a lot). motion also has built-in motion detection (that is its main job) so I am sure you can configure it in such a way to act as an early warning system if the baby stops moving (I am thinking the horror that is cot-death here, but I have yet to fully look in to getting this to work yet). Also, if have a spare PC lying around that you can put aside for this, it means that in the future you can use that PC for other jobs as your baby gets older. I am planning to, for example, get a cheap touch screen monitor off eBay, to allow me to turn it into an interactive activity centre for our daughter, to help her learn numbers and the alphabet (there are already some great tools in Ubuntu for just this purpose, but I am learning Python and hope to program my own bespoke software for the job). You could add some speakers and use the PC to play soothing music to your baby to help her sleep or even go all out and hook up some kinda remote-controlled mobile. The options are endless and hopefully it’ll mean that once your baby is all grown up, she wont think of you as her embarrassing geeky mum / dad, but her “makes-really cool stuff for me to play with” mum / dad….

Stream Live Audio from a Microphone in Near Real Time in Ubuntu

I have been endeavouring over the past few months to hack my own baby monitor. I initially kinda cheated, by using an IP-webcam.  However, that isn’t nearly as geeky as using a PC and USB webcam (plus, I also wanted night-vision, and IP-webcams with nightvision are not cheap). I got myself a cheap USB webcam from eBay that has six IR lights for nightvision and a built in mic. I’ll post later about sorting out the video feed, which turned out to be relatively easy. Sorting out the live audio feed turned out to be much harder.

My basic set-up is: a PC (I am using a small thin-client, so low-power and silent) running Ubuntu Lucid, a USB webcam with built in mic (with an audio output jack for the mic) and a wired connection to my LAN. I aim to listen to the audio on at least two separate PCs using VLC, so the format of the audio stream wasn’t much of an issue. It turned out to be much more difficult than I expected to get a real-time stream, as the latency with many options turned out to be terrible.

First, I needed to determine what the audio input was. As I had only installed a minimal install of Ubuntu, I needed to install ALSA, the linux sound architecture, via sudo apt-get install alsa-base alsa-utils. Next, I had to set up the mixer levels, since my PC is headless and I was doing this all via SSH, I used the ncurses alsamixer which allows you to set mixer levels via the command line. Don’t forget to run alsactl store afterwards to save your settings. As a result of doing all this, /dev/dsp now pointed to my microphone input.

Next, I needed a way of streaming the audio over my network. As I am a big fan of FFmpeg, that was my first choice, as it comes with a rather neat little streaming server called FFserver. FFserver works in the following way, you set up various streams using an ffserver.conf file, run the server and then run FFmpeg and direct FFmpeg’s output to FFserver. Here is the ffserver.conf file that I used.

After lots of trial and error, I eventually got this going using the FFmpeg command: ffmpeg -f oss -i /dev/dsp http://localhost:8090/feed1.ffm, but the latency was terrible, hitting almost 30 seconds. From what I can gather, FFserver doesn’t get nearly as much love as FFmpeg, the FAQ for FFserver freely admits that audio and video will drift out of sync alongside other issues, so I realised that FFserver was not for me.

Next, I tried using icecast2. Icecast is a streaming music solution, primarily designed to allow you stream music over a network, based on WinAmp’s Shoutcast technology, essentially making your own radio station. I used icecast2 in combination with darkice (since you need a program to send the audio to the icecast server, so it has something to stream). Darkice was perfect as it is designed to stream live audio from the audio input. Both programs are configured via xml files. Here is my icecast.xml and my darkice.xml. You’ll have to edit both these files somewhat, to make sure the log file location is correct for example. Due to the bizzare way that alsa sometimes works, /dev/dsp doesn’t always work. So in the case of darkice, I used hw:0,0 instead. This refers to the same thing, but in a different way it seems (the reasons for it go beyond me, I think it refers to the first card and the first input (the first being 0, the second being 1 etc)).

I would then run the icecast2 server using: icecast2 -b -c ~/icecast.xml and then darkice using: darkice -c ~/darkice.cfg. I had to run the darkice command using sudo, as there were some permission problems with accessing the mic input. This worked much better than FFserver, the delay was now down to about five seconds, but I got constant buffering issues, meaning the audio constantly cut off for ages. Also, over time, the delay would gradually get worse and worse, till it was as bad as the thirty second delay I got with FFserver. Once again, this wasn’t good enough.

My next effort was a complete hack, from the client PC that I wanted to listen to the audio on, I would run the following: ssh server 'cat /dev/dsp > /dev/dsp'. This would literally copy the input from the microphone on the server (my thin client) to the output of my local PC using SSH. Remarkebly, it worked as well as using icecast, but once again there were buffering issues, as I was trasnferring raw uncompressed audio.

So, my next option was using VLC. From doing lots of googling, I had read many people recommending it. My issue with VLC is that it is not a lightweight option and seemed somewhat overkill to me.

The huge advantage with VLC is that it acts as both client and server, taking the audio input and streaming it (although it actually does this using the Live555 streaming media module).

VLC also allows you to stream audio using various protocols; http, rtp, rtsp among others. Once again this wasn’t easy to get working, but after lots and lots and lots of trial and error, I finally came to the following command that worked for me: cvlc -vvv alsa://hw:0,0 --sout '#transcode{acodec=mp2,ab=32}/

:rtp{dst=192.168.1.5,port=1234,sdp=rtsp://192.168.1.5:8085/lily.sdp}' .

This basically takes the microphone input, transcodes it into an MP2 file (despite having FFmpeg installed, VLC would refuse to transcode to MP3) and then streams it via rtp to the address rtsp://192.168.1.5:8085/lily.sdp.

I then simply entered rtsp://192.168.1.5:8085/lily.sdp into the network stream input in VLC on the client PC and I got live audio, in near real time!! FINALLY!! The delay was about 1.5 seconds, it required very little bandwidth and seemed to work well…..for a while. Sadly, there were three problems with this. First; only one client could connect at a time, secondly; the stream would fail after a while, sometimes after five minutes, sometime after two hours, but it would always fail and third it would totally slaughter the CPU. Once again, this was no good for listening out for a crying baby.

Finally, I came to the perfect solution, funnily enough going full circle and using FFmpeg. From my googling of VLC and fixing stream dropouts with rtp, I found out that FFmpeg can stream via rtp nativley, with no need to use FFserver. I thought this couldn’t possibly work, but I tried it out using the following command: ffmpeg -f oss -i /dev/dsp -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://234.5.5.5:1234. This is similiar to the VLC command, except that this time I am converting into MP3 and streaming to the address: rtp://234.5.5.5:1234. Once again, all I need to do is enter rtp://234.5.5.5:1234 as the streaming source in VLC. There are a few huge advantages with this method, first, the CPU usage is only about 25% on my naff little 750Mhz Transmeta Crusoe. Second, it seems multiple clients can connect at once and third, it seems rock solid. I have had this command running for three days straight with no problems. Memory usage seems to creep up over time, but that’s about all. I still get the roughly 1.5 seconds latency, and that is rock solid, it never gets any worse than that over time. Finally, a solution that works. So now, I use the following script, that is run at boot, to stream live audio in real time over my LAN:

#!/bin/bash
echo killing old ffmpegs

PID=( $(ps -e | grep ffmpeg | awk '{print $1;}'))
if [ $? = 1 ];then
echo "error getting vlc PID, exiting"
exit
fi
if [ ! -n "$PID" ];then
PID=1234567
fi
echo killing ffmpeg with PID $PID
kill $PID

echo starting ffmpeg
ffmpeg -f oss -i /dev/dsp -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://234.5.5.5:1234 2> ~/ffmpeg.log &

FF=$!
echo ffmpeg started with PID $FF
exit

This simply kills any other FFmpeg processes running and then starts a new FFmpeg process to stream the audio input (I kill old processes, so I can run this script if for some reason the stream fails and always be sure that only one instance of FFmpeg is running at any one time).

So, it took me about a month to get this far, but I am finally happy. There are other options that I also tried but could never get to work, such as the ability to share audio inputs using Pulse Audio (I got them to share, but it seemed to constantly crash my network) or using the Live555MediaServer directly (the one that powers VLC) or MPEG4IP but they both were poorly documented and were too complicated. I’ll write up about the video portion of this next, to show how I hacked my own baby monitor.