Webcam Tradeoffs

February 15th, 2006 · No Comments

I just made some wholesale changes to the way our webcams work. For those not familiar with our webcams they’re a hosted by Computer Science and offer some nice webcam views of the Halifax to those who are interested in seeing what’s going on in the city (or our server room).

The images were previously streaming directly off the webcams themselves. They’re Axis 2120 cameras which are completely self-contained allowing for simple setup and maintenance. The downside is that they tended to buckle under the load when we had a lot of people visit the webcams. So we’ve shifted things around to help improve the stability of the cameras. The first step was to get the webcams to deliver their images to the webserver. Then alter some script examples provided by Axis to get the webserver to stream the images. It sounds easy, but it’s fraught with little problems that are very difficult to debug. On the bright side it’s all working now and I’m pretty happy with the end result.

But the title of this post is Webcam Tradeoffs. This implies that not everything has turned up roses and that’s indeed true. The benefits are that we’ve improved the stability of the delivery of our streams and we’ve also increased the resolution of the stream size from 352 X 240 to 704 x 480. The cost is that the frame rate has dropped from a maximum of 30 fps (realistically 24 fps on most good days) down to a solid 10 fps.

Overall I think the benefits will shine when most people want to look at the webcams. Our overall traffic doubles on a day when it’s snowing. That 100% increase is due to webcam traffic. This isn’t the only time we see increased traffic to the webcams but it’s certainly the most dramatic. By offering better peak stability we’ll be able to serve that segment of our website’s audience better when they want to use our website the most.

From what I’ve read, it’s theoretically possible to get the framerate up but it will cost a lot in terms of development time and bandwidth. Cranking the framerate up to 20 fps will double the amount of bandwith consumed both from the cam to the webserver and from the webserver to the audience. Right now that’s not realistic because the webcam to server and server to audience traffic is flowing over the same pipe. The next phase of the plan involves moving the webcams in the CS building onto our backend network to help alleviate the front end network load on the webserver.

So what’s next? Well I’ve been looking for it for a while now and I think I’ve found it. We’ve got a new location for the fourth webcam. It’s got a couple of logistical issues which we’ve got about 90% solved. Just waiting to go to a fabric store to finish the last 10%. Hopefully we’ll have it up shortly and I’ll be sure to announce it when everything’s ready for production.