Hi Corentin

Pretty sure Andrew answered your mpg-streamer query. I downloaded it from sourceforge and compiled it locally. I use SuSE 11.4, but I doubt that will be a barrier. One of the nice things about it is that my 7 cameras now have 2 of them on a remote P2/600 and another on a P4/2400 that just act like netcams. I should point out that motion no longer connects to /dev/videox devices for any camera. They all use mpg-streamer.

You have to copy the www directory somewhere. One of the bash script startups on my main machine is;

cd /spare/motion
killall -w -TERM motion
killall -w -TERM mjpg_streamer
cd mjpg-streamer
export LD_LIBRARY_PATH="$(pwd)"
./mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 1280x1024 -f 10" -o "output_http.so -p 8090 -w ./www" &
./mjpg_streamer -i "input_uvc.so -d /dev/video1 -r 1280x1024 -f 10" -o "output_http.so -p 8091 -w ./www" &
./mjpg_streamer -i "input_uvc.so -d /dev/video2 -r 1280x1024 -f 10" -o "output_http.so -p 8092 -w ./www" &
cd ..
/usr/local/bin/motion -c /spare/motion/day.conf

My thread conf file has some entries;
# Maximum number of frames to be captured per second.
framerate 5
# URL to use if you are using a network camera, size will be autodetected (incl http:// ftp:// or file:///)
netcam_url http://192.168.20.248:8090/?action=stream
# The setting for keep-alive of network socket, should improve performance on compatible net cameras.
# 1.0:         The historical implementation using HTTP/1.0, closing the socket after each http request.
# keep_alive:  Use HTTP/1.0 requests with keep alive header to reuse the same connection.
# 1.1:         Use HTTP/1.1 requests that support keep alive as default.
# Default: 1.0
netcam_http keep_alive

Yes the framerates don't match. I doubt that's an issue, but havent checked

I haven't really tracked down the exact reason for the WiFi issue. It manifests as a horiz band over part or most of the image. I made it much better by using "snapshot" instead of "stream", but its definitely interference based. ie another WiFi system. That should however force a TCP retry at that layer. I haven't done any line sniffing to see what is going on. It may even be that the motion netcam code ignores retries on the basis that speed is of the essence. I even wonder if it isn't UDP.

The WiFi link isn't real strong signal wise either, maybe -78dBm which is pretty close to the noise floor. Every time I hop channels away from the interfering source though I clear the problem. How bad? Well it depends on what service is running on the interfering system. Sometimes I get a large mpg file of just grey bands! ie it looks like movement. There is also significant latency over the WiFi link even at 48Mbps. Not seeing any interface errors though. One day I will try another WiFi modem at the remote box.

Cheers Bob


On 01/09/12 21:51, corentin barbu wrote:
Hey Bob,
Glad to read that somebody made it! I'd definitely be interested by more details:
- I cannot find anything about mpg-streamer in google, is it a specific program?
- I'm under linux is your solution working in linux?
- how bad is the problem with the WiFi?

Thanks,

Corentin