Hi Andrew and Bob,
Thank you so much guys for the details. As for mpg-streamer I had tried with the .deb but it doesn't install ... I'll give a shot to the compilation from sources.
One thing I don't understand is how you connect the interferences on the image with the WiFi. Does it affect even the cam not connected through WiFi?
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;
killall -w -TERM motion
killall -w -TERM mjpg_streamer
./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" &
/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.
# URL to use if you are using a network camera, size will be autodetected (incl http:// ftp:// or file:///)
# 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
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.
On 01/09/12 21:51, corentin barbu wrote:
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?
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Motion-user mailing list