Comments

Thursday 01, January 01:33

Camera status

OK, so the current situation is thus:

Two cameras are in place. One covering the external run, and one the inside of the shed. The inside is still currently just an empty shed with some cardboard boxes for the buns to hide in. The inside camera also seems to be dead :( This is possibly due to a short in my dodgy wiring, or possibly due to the camera itself being buggered. Who knows, but it's way down on my list at the moment.

Both of these cameras are cheap analogue infra-red CMOS jobbies bought from ebay. Quality is not brilliant but they are cheap, see in the dark, and weather proof. They are now powered from a transformer inside the shed. The video signal is carried along RG59 coax to the garage, which is where my video server will be situated. I spent some time a few weeks ago fitting some wire trunking to keep the coax dry and protected from UV damage.

I plan to buy two more cameras. These will have to be wide angle, so a little more expensive but not too much. One will cover the majority of the back garden for when the buns are out, and the fourth will cover the front of our house for security purposes (and will NOT be available on the website ;). Who knows, I may even add a camera to the bunny room in the house too in the future.

The garage was a complete mess until two days ago, due to us storing some friends furniture while they move house. I have spent the last two days knocking up some shelving to tidy all the crap, and ready to hold the server/s.

Okay, next problem. The server will be in the garage. My router is in the lounge. Yes, it is indeed a wireless router, but wireless networking around here is a fragile joke. I have 4 other wireless networks in neighbouring houses competing for airspace (and yes, two of them are totally unsecured), so it is just not dependable enough to be a solution. As luck would have it I have just laminated the entire ground floor, so all the skirtings are off, with just enough space behind to run some ethernet cable. One 30m CAT5 cable duly ordered from dabs, and waiting for the missus to go out so I can drill through walls without her moaning :) (And I will also run some upstairs too for the desktop PCs).

The video server consists of an old Pentium3 500 that I resurrected for the job, together with a 16 input video grabber. Now multi-input video grabbers are VERY expensive (Circa £1k), so I was particularly chuffed with myself when I sourced one from Hong Kong on ebay for a mere 190 notes. Of course I have since discovered that these "ebay specials" are in fact dodgy clones of Kodicom cards (a fact discovered by trawling through about 900 images of video grabber PCBs). The software that shipped with it was, quite frankly, crap. However, I was perturbed to find that the supplied drivers did not allow access to the frame buffer, so I was stuck with their software if I wanted to see my cameras :(

Some desparate searching did turn up some open source WDM drivers for the chipset used on the board, but alas, I could not get them to work.

I fudged it in the end by using the supplied software to stream to the network, then used their Web Active-X control in my own software to decode the stream and grab frames that way. A small amount of reverse engineering of the web code soon uncovered the calls to change cameras etc, but it was still a horrendous bodge, and the encoding, decoding and grabbing was all too much for my poor P3, so I ended up having to decode and grab from a second PC.

Anyway, all of this is now in the past. This time, I thought to myself, I will do it right. Said P3 now has Linux sat on it, and those luverly people over at video4linux.org had already included support for the board in the kernal (Although I have yet to actually try it - ooer).

OK, that takes care of image aquisition (hopefully), but now how to get it onto the web? Having seen the good Mr T's cameras running over a rngpwelfare.com, I really REALLY wanted proper streaming this time, rather than jpegs updating every 3 seconds. The big problem is the woeful upstream bandwidth of ADSL. My router reports 288kbps to play with. Better than normal but still naff all. To give say 10 people a camera stream, that means 28kbps per stream!! Much of the last few days has been spent researching codecs. The new H.264 (MPEG4 part 10) codec seems to be the current bees bollocks, especially for ultra low bitrates, but it has two big problems. One, Windows Media Player doesn't blimmin support it (spit). I could get around this by making windows people download Quicktime, or the VideoLAN Active-X control, but I really wanted something that would cause the minimum fuss for people. The other big problem is the amount of processor overhead is takes to encode. I did some tests on my 3000+ Athlon 64, and one 320*200 stream was eating up 50% of my processor! 3 cameras on a Pentium3? Forget it!

My research is thus still ongoing. Surprisingly, it seems like the lowly MJPEG codec might be my best bet at such low rates, but more testing is needed.

Yet ANOTHER complication is that I am looking to replace our current Sky+ box with a Linux based PVR. Ideally I would want to feed the camera streams into that too, so that we can view them on the TV. However, this means encoding them to MPEG. Yet, more processor load. I am also looking at saving clips with any movement on them for security purposes using something like ZoneMinder. This is yet MORE processor load (and quite a bit too). I am having nasty visions of 3 PC's for video processing alone. The missus will not be happy :(

Anyway that's enough for my first entry I think. Next few days consist of wiring up the LAN out to the garage, and getting the Linux box networked and configured. Then I can try the run camera on it and start doing some proper performance testing. Watch this space for the latest disasters ;-)

Guest      2007-09-25 21:49:18

aceoqifu edhq zdoj jvsmt kcdzq xduz rxdhqc

Guest      2007-09-25 21:49:29

bfwolxydv gmkual acsutq uwzg pbrjoitf hbwtflouk chuqwji http://www.ahiljxb.rnkhwxa.com