Comments

Thursday 01, January 01:33

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.