As far as I know the motion server:8081 is a common garden variety
tcp one. ie it is a single connection between client and server.
When you have more than one client you are actually running more
than one socket instance on the server. From two clients you would
of course have different source IP addresses.
You are thinking about a broadcast protocol? ie just putting packets
out on the wire and running a service on each client to "capture"
what is needed. There are quite a few video standards that do that
kind of thing, but motion by itself I think would need a buffer
program. vlc might be able to do it, don't know for sure.
I use to have the "teleport" problem when I ran a 6 IP (net) camera
system on a pair of P3/900's about 5 years ago. That was actually a
mixture of the boxes being CPU bound, a narrow disk drive channel
and having a lot of packet collisions on the WiFi links. I ended up
nice-ing the lesser needed processes, running RAID0 and tuning the
WiFi environment better. It never completely fixed things, but it
got a whole lot better.
The trick as always is to discover where the bottleneck lies. You
can do the maths to a degree and its also about looking about system
loading. (eg top) At 30fps you can make some guesses about the
individual sizes of jpegs. My home system for example runs between
200 and 400Kbytes per image as saved, but the web server (with a
lower jpg quality) is about 100K per. That means at 30fps I might be
doing 100 Mbits/sec MJPEG streaming down the USB cable. If motion
was capturing every frame as movement I'd also see that 100MBit/sec
on the Ethernet since I use NFS and some mjpeg-streamer boxes. The
8081 web server stuff is actually quiet glacially slow here. I set
webcam_maxrate to 1! If you are doing 30fps at maybe 100Kbytes per
image you are using somewhere around 30 Mbits/sec on the Ethernet.
The numbers may sound daunting, but it's real easy to work through
On 24/11/12 14:15, Jason Sauders wrote:
So, it seems as if I suck. Remember how I said I have
3 thread files open and one is for the wireless cam that we use
when we go away? Yeah, evidently that one had 8082 in the
settings, so for whatever reason it was seeing thread3 8082 and
saying unable to connect, despite the fact thread2 8082 was
existent. Switched thread3 to 8083 and thread2 to 8082 and it
works great now. Durp durp. I KNEW it'd be something simple.
I have another question though semi off topic to this
particular issue. I see in the settings that I can independently
control the fps that's coming through the webcam url to keep
that lower than the actual recorded stream. That makes me wonder
with something. For a while with a previous issue I was trying
to figure out why Motion was recording my feeds with skipped
frames. If I would be outside walking around, you'd see me
jumping forward about 3-5 steps every 2 seconds. It was as if I
was continually teleporting. I realized that it was due to the
fact that my Linux server downstairs which runs Motion also has
an LCD monitor hooked up to it. I full screen Firefox and let it
run the mjpg stream so when I'm in the basement I have an active
live visual of what's going on outside. The problem was it was
duplicating the streams. One live for me to see in the browser,
and one for Motion to record. My actual camera was getting
stressed due to duplicating two 30 fps streams and that's why
Motion was receiving choppy feeds. Once I turned off the browser
(or switched to a 2 fps stream... my camera has 4 preset streams
built in that I can customize) the issue went away entirely.
That little story above leads me into the next question. When
I'm viewing the webcam stream using ip.address.of.server:8081,
is the camera still duplicating streams? I.e. is it doing one
stream to the browser and one stream to Motion like it was
before when I was using the direct mjpg stream in the browser?
Reason I ask is I'm just wondering if Motion somehow has the
capability to "forward" the singular stream it's recording from
to the browser without duplicating it, or if it actually does
have to duplicate it since it's two locations receiving the
This seems exceptionally confusing to put into words, but
while we were on the topic of this newly solved durp-durp
mystery I figured I'd throw it in here and see what you guys
Thanks again for your quick responses. Sorry the solution was
a bit of a face palm on my part.