Streaming webcams

I was envisioning a responsive interface with 2 video feeds, one for the direction of travel and another for the direction of the gun.
I figured because the server and client are on a local network, 2 video feeds should not max out the bandwidth of a wifi network and it would be easy.

Well as usual, there is more to the picture. Rob and I bought 2 webcams that are known to work in Linux and I started experimenting with different streaming applications.


VLC

VLC never ceases to amaze me, it is so versatile and just works for so many things.
Using X11 forwarding, the VLC GUI provides a very simple way of saying "Stream my /dev/video1 device over HTTP" and then browsing to that ip:port just works! You can also connect another remote VLC to the feed and view it that way.

This GUI action can then be translated into its command line equivalent and you would have a simple scriptable method of streaming a webcam.
The command line you end up with can be a little hard to create as there are a lot of sane defaults the GUI uses that aren't used by default on the commandline.


FFMPEG and FFSERVER

This is another incredibly complete set of tools for anything media related.
FFMPEG's way of accomplishing this is to configure and start an FFSERVER instance, which accepts HTTP video feeds and provides a simple web server to view it.

I created a couple of different configurations and this is where I first discovered the main problem with my idea.
It seems there is a limitation where 2 webcams cannot be streaming at the same time.

This could be a limitation of the drivers at an operating system level, or because some people have suggested the bus cannot support 2 cams at once.
Either way, it seems we will have to only use one webcam initially and maybe add functionality to switch between the two at a later stage.

The FFMPEG mailing list was very useful for helping me get this working, a big thank you to Belcampo for the help.


MJPG Streamer

This is an interesting project, an MJPEG is a Motion-JPEG, which is essentially a streaming set of jpeg images that make up the frames of a video.

Using MJPGStreamer is simple, just install the package from your software repository and execute a command like this:

mjpg_streamer -i "input_uvc.so -d /dev/video0 
    -o output_http.so -w /usr/www -p 8081" 

That is all you need to get video from the webcam and stream it over HTTP on port 8081.
Notice the optional -w /usr/www - During the installation of the package, it puts some HTML content there so when you start the server it can give you an explanation of what's going on and a demonstration of its features (and there are quite a few!)

I was pretty impressed with its simplicity and it means the client browser does not need any special video codecs installed, as long as the browser can render images.


Streamer

The last streaming option I experimented with was Streamer.
Streamer is very simplistic, all it does is take a snapshot or video from your webcam and dump it to disk as a file.

The reason I considered this program is because I tried a (slightly nasty) hack to get 2 webcams working at the same time.
By saving a snapshot from one, then a snapshot from the other in rapid succession, I was able to craft up a little ajax page that interleaves requests for these images, in effect providing 2 video feeds at once.
The refresh rate was a little slow, but it was the only way I could see how to accomplish 2 feeds at once... even if it wasn't very good!


The problems

The 2 biggest problems were:

• The limitation of only streaming one webcam at a time
• Long delays

The proper video streaming options (VLC and FFMPEG) have the nicest videos and a decent framerate, but the video has to buffer up a little first, which results in something in the order of 6-10 second delays - which is not ideal.

If I used Streamer with one webcam, the delay was quite small, but the framerate was not fantastic (1-3 fps). Using 2 webcams was probably <= 1 fps - but using 2 webcams was just a proof of concept.

MJPG seemed to provide a happy middle ground. The framerate and the delay were not ideal, but acceptable and this seems like the most likely solution for us at this stage.