2007-04-03 11:54:42

New section: Panoramas

I have finally got around to properly adding some of the 360 degree bunny panoramas I've taken. Take a look on The Panoramas page.

1 Comments

2007-02-28 23:20:50

Camera developement stopped

As is fairly obvious I would think, all developement on the cameras has stopped for the moment.

Unfortunately I have been involved in another large project which is taking all my spare time. Many apologies for the lack of cameras.

1 Comments

2006-11-01 22:53:57

Breeder advertisments

On occasion you may see adverts for rabbit breeders down the left hand side of this site. I do NOT support the breeding of rabbits and would be grateful if you could make a note of the site and email me (or just comment on this news item) so that I may filter them out to ensure they do not appear. Many thanks.

2 Comments

2006-10-04 20:49:43

Cameras Update

Still plodding on...

Am making good, if slow, progress. Am now able to exchange HTTP headers with VideoLAN and recieve the stream. If you are going to be debugging HTTP headers then take my advice and avoid HTTPSpy. It only modifies the flippin GET line! That one had me stumped for a while until I tried HTTP Sniffer instead, which gave me the TRUE headers. Bah!

Also have the shared memory segment up and running after a few teething problems with permissions.

Lastly I now have a proper architecture designed for managing connections and giving proper feedback (rather than the cams just "not working"). I am finally happy that I have a robust and clean sequence for connection, so all good :-)

As for timescales, hmm. Never ask a coder for timescales. ;-) Seriously, it all depends on how much free time I get to work on it. I would say all the major technical hurdles are out of the way, so now it is just a case of blatting out the rest of the code. {sticks finger in air}, mebbe another week? (famous last words)

8 Comments

2006-09-30 22:52:00

CGI programming

Just a quick update to say that things are moving albeit slowly

I am having difficulty finding time to develop at the moment, but I have passed couple of small milestones.

1) I have successfully run a test CGI binary on my host's server. This is good because I was getting the dreaded "premature end of script headers" for ages. This turned out to be due to compiling as C++ for some reason. When I changed to raw C, all was fine. Not quite sure why, and haven't the time or inclination to work it out either. If C works, then C it is :-). If anyone has any ideas then I'm all ears

2) I have got to the point of successfully opening a socket to my home camera server from my CGI proggy running on my host's server. I was concerned that they would have restricted then opening of sockets willy nilly so that is great! The more I find out about CGI, the more I am impressed with just how much you can do. :-)

As an aside, I am now running the camera server box at init-3, so have had to brave the vlc command line. Luckily this is all working fine too, and the extra control I have had via the command line has enabled me to fine tune the stream. I did a few experiments and I have found that my PIII 500 is able to encode one 320x240 @ 30FPS stream using about 45% of processor. I can drop this to 15FPS which is a barely noticable difference, and I get a drop to 30% usage. If I then up the resolution to 480x320, the usage jumps to 50%, which is a bit too near the line for my liking, so I will probably run two streams at 320x240@15FPS to start with at least.

So, work continues on the CGI stuff. I have the basic boilerplate stuff in place for both programs, and am connecting to the stream as I say above. I am now working on the guts of sharing the stream data across processes (using a shared memory segment), and working out the tricky details of reference counting on the stream server, and being able to restrict the number of clients. I will update as soon as I have any more news.

0 Comments

2006-09-20 21:31:34

Linux developing

Well my hosts have now decided that they don't offer compiler support after all. Pah.

Luckily for me they are running RedHat enterprise, and my distro is Fedora 5 so hopefully they should be pretty compatible

So now I am developing on my garage linux machine. At first I was just using gcc over a secure shell, but I've finally bitten the bullet today and installed a proper dev environment (KDevelop), and am using it remotely via XMing (Windows X-Server)

So C++ coding of the cgi stream server has begun. It's fairly slow progress at the mo due to my unfamiliarity with coding for linux. Having to read up a lot about IPC mechanisms and the like, and to be sure I understand it all enough that I don't eat resources on my host's server (Leaving orphaned processes / pipes / whatever lying around) Still, I am pleased with how it is going so far.

No time estimates yet I'm afraid. All depends on how much time I get to devote to it. A wild guess would be around 2 weeks

2 Comments

2006-09-17 21:48:39

Camera 2 now working

Whilst I am waiting for my hosts to sort themselves out, I kept myself busy by taking a look at the shed camera.

Turns out it was a short in the camera itself rather than my wiring (amazingly). All sorted and it's now working too :-)

Below is a screen grab off the network. This is the new uality you will get online as long as my cacheing idea works

Also been readin lots about Unix coding so my cgi proggy will play happily with my host's webserver

0 Comments

2006-09-15 18:38:32

Progress...

Some progress to report

I have knocked together a quick proxy script and it only flippin works!

Before you get too excited I should add that this it just a proof of concept script in php, which I do not want to run as a final solution as I am concerned about the amount of resources I will be hogging on my host's server. Basically for every person viewing a camera, an instance of the script will be running. Running in an interpreted scripting language like PHP is not good. Yes, I could supply a stream right now using this, but I really don't want to pee off my hosts unecessarily ;-). However, it is good to know that I can get a clean stream through my host, so that is a major hurdle overcome.

So the next step is to get a C++ version written. I have just today got SSH access to the server, and am now waiting on my host to supply access to a compiler. Been reading up on CGI coding while I wait

I have also downloaded the source code for that Java MPEG4 player, and a coding environment (Last time I coded Java was J++!). I have also been checking out the official MPEG specs to find the transport format. Having had a look, I am tentatively hopeful to be able to add MPEG transport stream support to the applett. This will mean video for everyone without having to download or configure anything! :D

One last note. The applett does NOT support H.264 (It seems H.264/AVC is a bit complex to decode on the fly with java). So it looks like I will be using MPEG4 ASP instead. The bandwidth requirements are a little more with this, but if I can get this CGI cacheing idea to work, then it won't be a problem. :)

1 Comments

2006-09-12 20:54:10

Format matchmaking

Just a quick update to confirm I am still working on this.

Despite Quicktime allegedly support HTTP streaming, I can find no mention of this in the official docs, and no-one seems to have gotten it working. Looks like RTSP only with live video on Quicktime :-/

I have successfully tested a stream from work using the VideoLAN client, albeit not over our proxy (which is currently dead). I was amazing watching the buns in realtime from work! :D:D

In my search for a way to let people stream in their browser, without having to install VideoLAN and configure a load of stuff, I have come across this java MPEG4 player. I was extremely chuffed until I couldn't get it to work :(. I suspect it only accepts MP4 container format, whereas I am streaming in MPEG TS (VideoLAN doesn't support MP4 over HTTP - ARGH!). It is open source, so I am toying with the idea of adding TS support myself. This will not be a small project thought :-/)

I am still planning on streaming an H.264 stream for people who really want to see the cam whilst I am faffing with Java and the like, but first I want to see if I can write some php code to act as a proxy. I'm really not mad keen on exposing my home router to all and sundry :-). Whilst thinking about this, I also wondered whether it would be possible to write a CGI proggy to cache a small buffer of video on my host's server, and then simply farm that out when other people connect. This would be terrific if I could get it working as it would mean I only need 1 or 2 upstreams. Result - vastly superior video quality! Dunno if my hosts will get shirty about hogging resources on the server though, so may have to write it in C++ rather than php.

Anyway, hope to have a little proxy script in place within a couple of days, and then I will offer a temporary stream.

0 Comments

2006-09-09 16:12:26

JPEG SHMAPEG

I am deeply vexed!

In looking for a decent free MJPEG server, I began to wonder whether it might be better just to code my own. That way I could react dynamically to the number of people watching the cams, so if only 1 or two people are watching, I could ramp up the jpeg quality on the fly and they would get a much better picture.

A brief search for an open source jpeg library later, and I find that the IJG library is the defacto standard, and is in fact already installed as part of my Fedora distro! :D

I have a play encoding images to get an idea of what quality levels to use. I am horrorstruck!

I have been aiming for a rate of about 16kbps. This should allow between 10 and 15 people to view a cam stream simultaneously on my 288kpbs ASDL upstream bandwidth. At a minimum 10 frames per second (Although I was aiming higher), that gives 1.6kb, or 0.2KB per JPEG image. That seemed mighty small to me, so I did some tests with the cjpeg tool to see what kind of image sizes I was getting. The IJP library has quality settings of 1-100. I started with 5:

Erm. That doesn't look good. It also weighs in at a whopping 1.7KB. Just a tad over the 0.2KB I was aiming for!

I continue playing, going even LOWER in quality. Here is a 2, and a 1 quality setting

An absolute joke, and weighing in at 1.4KB and 1.3KB repectively. In fact, to get a reasonably viewable image, I need quality 15:

This image is 2.6KB in size. This would give a frame rate of 0.76 frames per second, or 1 frame every 1.3 seconds! At that rate, I might as well use my old method of FTPing up the image and letting people view it directly from my host's server!

So how, I wonder to myself, did VideoLAN manage to produce such a good quality image at such a low bitrate?

Answer. It lied.

Despite me setting 16Kbps, and it recording a stream rate of 16Kbps, I take a look at the actual traffic coming over the network. Ah. That would be 700Kbps then!!

I am deeply vexed!

So MJPEG is now back out of the window, along with easy Web viewing. I have no choice but to use an advanced video codec that can handle such low rates. H.264 seems the obvious choice, but videoLAN's implementation seems incompatible with Quicktime - the only mainstream media player that can handle H.264

MPEG4 part2 (ASP) is a possiblility, but quality tests have not been good. I would have to up the bitrate which means less people being able to view the cameras

Flash video would be an ideal choice, as 98% of people have the Flash plugin installed, and Flash 6 and up use some variant of H.263 which should hopefully be reasonable (Although I have yet to test). Flash 8 and up also support the VP6 codec. Unfortunately Flash uses the RTMP protocol to stream, and VideoLAN support for RTMP is too basic at the moment. So that means running either Flash Media Server (out due to cost and the fact it needs an MS server OS), or the open source Red 5 server, which is working on reverse engineering the RTMP protocol. I do not know how far or how useable this is yet though - something to look into

So there you go, I'm a bit directionless now TBH. I may serve up an H.264 stream for now until I can find a better solution, but people will have to install the VideoLAN client to watch it. I will update this page with instructions on how to watch if I decide to do this.

0 Comments

2006-09-08 20:53:30

MJPEG Woes

I have spent HOURS today trying to get a valid browser compatible MJPEG stream out of VideoLAN with no joy. Only afterwards do I notice on the VideoLAN site that multipart jpeg mux support is only available in the current source builds (screams). No errors from VideoLAN when I try and use these options, it just doesn't work. Bah!

So the upshot is I either have to download and build the latest VideoLAN source, and then play "parameter fiddle" for another day, or I give up on VideoLAN and find another Linux MJPEG server.

There do seem to be a few around, but they are all fairly raw. I will have to have a play with them to find the best. This means the cameras will be delayed I'm afraid :(

I did think "blow it", and was gonna offer a stream using the VideoLAN ActiveX control for those who wanted to see it, but in order to use the control, you have to install the enter VideoLAN suite, and then the control isn't signed either so you have to go and fiddle with your IE security settings to get it to work. Nobody if gonna bother with all this just to see some buns, so I haven't bothered.

I am now heartily sick of the whole thing. What I thought would be the easiest bit of all has turned into a nightmare :(

3 Comments

2006-09-07 22:29:54

We have bun pics!

Spent today trying in vain to get VNC working so I can remotely administer the camera server without having to trapse down to the garage. All seems fine but either something is wrong, or I cannot find a compatible VNC client for Windows 'cus I'm blowed if I can get it to work :(

Nevermind, I have installed Xming on my XP box instead and this is working fine to give me a remote client

Sooooo, Camera server is now sat in the garage, and connected to the run camera. And whaddya know! It works!

These images are not direct grabs, but rather grabs from an MJPEG stream at a tiny 16kpbs. This is the quality you will get online when you view the cams. Before you moan too much though, bare in mind that this is 25 frames per second video, NOT the 1 frame per 3 seconds I was running previously.

I have also been playing with the H.264 codec again. Below you can see some grabs from an H.264 stream (again at 16kbps). At first it looks impressive as the quality is far better than MJPEG: (These are nighttime infrared shots BTW)

However, the nasty surprise comes when movement takes place. Here is a sequence as Sparkle jumps down from the step. Note the huge pixelation that occurs due to the large frame changes:

Although the image recovers fidelity fairly quickly, I'm just not sure whether this is a feasible codec to use. This is quite apart from the massive processor load that it gives the server, along with the problem of displaying it in a browser. Currently only Quicktime supports H.264 at the moment, and I have been unable to get a compatible stream so far, despite much tweaking and delving through docs. The other possibility is to offer the VideoLAN plugin itself.

One other problem you will notice in the above images is the massive overexposure of Sparkle. Another good example here:

This is because the infrared light is emitted from the camera, so objects close to the camera recieve a lot more light than the far end of the run which is in near darkness. This wouldn't be a problem except that the cheap camera use a metering system where is tries to average the entire scene to mid grey. The dark back corners of the run cause the camera to overexpose the true subjects (ie the buns).

One way around this would be to mount another IR light at the back of the run, to provide more uniform illumination. Something else I will have to look at in the future.

I was hoping to have a rudimentary stream online by the end of today, but it appears that the MJPEG stream being encoded by videoLAN is not quite right, because I cannot get either native Firefox support, or and Java or ActiveX controls to render the stream :(

It could end up with the videoLAN plugin yet...... :/

2 Comments

2006-09-06 20:07:07

Stree-e-e-e-eam. Stream stream stree-eeem.

Made good progress :)

House and garage is now wired with Cat5 ready for camera server to sit in garage

Linux installed and configured. After a couple of days of tinkering I finally got a video image out of my grabber card. However, there was fairly significant corruption with the image (This is via XawTV):

Yet more fiddling, tweaking, research and trawling through the images at The BTTV gallery later, I discovered that my card was NOT a Kodicom clone at all, but rather a Tibet Systems "Progress DVR". Manually setting the card type in the BTTV driver brought forth perfect video! Wahooo!

This is great news in two respects. 1) Linux supports the card properly and openly instead of the crappy proprietory drivers I had with Windows, and 2) I didn't fry the card with my dodgy wiring! :)

After spending 2 HOURS trying to download and install VideoLAN (Who said Linux was easy? ;)), and much more fiddling and tweaking, I finally had video streaming over the LAN to my Windows box. Hallelujah!

I have since been spending more time testing codecs to try and determine the best way forward. I still think MJPEG is the way to go, so now am looking at how best to present this in people's browsers. According to my research, Mozilla based browsers should be able to support this natively, but when I tested I only get the current image in the stream displayed. Any ideas anyone?

For MS or IE based people, I think I will provide a choice of a java plugin, or an Active-X control. Java would be preferable but of course not everyone has that since MS stopped shipping it with Windows. Active-X is the option for these people, and I plan to nick the Axis camera control for this purpose.

I have toyed with using Javascript to update the JPEG too, but I doubt this will update fast enough (30 frames per second). May have this as a fallback though. We will see.

So there you go, that's the current status. I hope to have at least one camera up and online by the end of the weekend. Watch this space! :D

2 Comments

2006-09-06 19:35:20

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).

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 ;-)

2 Comments

2006-09-06 19:25:38

All new news!

Right! In an effort to keep this website from stagnating like it has over the last year or so, I figured I would turn this news page into a personal blog of sorts. Yes, some of it may not have anything to do with bunnies, but at least people will know I am still alive, and things ARE happening behind the scenes.

I have spent today writing a decent news / blog system so I can update easily and frequently. The old news page was boggo standard HTML which was a just slightly more effort than I was prepared to expend :)

So welcome to the all new news page. You are able to make comments about each entry just like a standard blog using the link at the bottom of each item. I will also be overhauling the site a bit to make it more alive and interactive. I have already fixed several problems today that have been niggling me over the past year. Hopefully things will continue getting better.

0 Comments