I'm not sure how definitive this is or if it really helps
paint a clearer picture, but I decided to conduct a quick 1
minute test here to see how certain streams compare. I utilized
System Monitor built into Ubuntu and watched it closely and took
a screenshot at the end of it. I wanted to see if there was any
sort of performance hit when I would browse to my webcam URL of
Motion. I bookmarked two sites in my toolbar, one with the
custom html/css page I made which streams
both in the same screen (so I can see the front and rear camera
in one page), and the other was a direct stream of my rear
camera, so it wasn't two cams like the first one, but only one
camera. It was streaming to the exact same URL Motion is set to
(netcam_url), which is
If anything, this would suggest that the video4.mjpg URL would
have a greater chance of performing better since it's one camera
instead of two.
My plan was to break up the tests into 10 second segments.
Sure, not overly scientific but I still think the results were
some food for thought. My webcam_maxrate was set to 30 fps,
the cameras themselves were set to 30 fps, and each thread
file for each camera was set to 30 fps. Overall, 30 was the
ideal target because it was the heaviest fps setting possible.
The plan was this:
Stage 1 - Motion disabled, no streaming.
Stage 2 - Motion running, no streaming.
Stage 3 - Motion running, streaming webcam_url to front
and rear camera simultaneously.
Stage 4 - Motion running, streaming direct video4.mjpg url
of only the rear camera.
Stage 5 - Motion running, no streaming.
Stage 6 - Motion disabled, no streaming.
Based on the seconds counter just below the Network
History graph (60, 50, 40, etc.) the different stages go
Stage 1 - 60 to 55
Stage 2 - 55 to 45
Stage 3 - 45 to 35
Stage 4 - 35 to 15
Stage 5 - 15 to 5
Stage 6 - 5 to 0
If you look at the graph, you can see stage 2 and 3 were
identical the entire time. This suggests that there's no
additional network traffic being pulled from the camera to
handle the stream as I had touched base on earlier. Once
stage 4 hit you can see some additional network traffic hit
the scale, plus you can see my RAM begins taking an odd up
and down series of hits as well. After that it's pretty self
One thing I thought was interesting is last time when I
had the choppiness issue, I thought for sure the camera was
getting stressed because it was pushing out two streams of
30 fps feeds. This kind of irked me because the camera has 4
stream presets, so I thought it'd be weird it would get
bottlenecked that badly by 2x30fps. That being said, I just
remembered I did swap out a 10/100 switch for a gigabit
switch a few nights ago. Just now when I tried to duplicate
the skipping I noticed before, I was unable to, which
suggests the gigabit switch likely solved the issue and it
wasn't necessarily the camera itself. I guess because I
thought it was the camera being overloaded that was causing
the skip I had kind of forgotten that I did the switch swap.
That being said, it still doesn't take away from the fact
that utilizing Motion's built in web server seems to be
lighter duty on the network than to stream to the direct
URL's of the cameras, at least based on my findings. I can't
even recall why I did this, but in my custom HTML page I
made, both cameras were streaming directly to their mjpg
URLs. After this I have since switched them to
ip.of.server:8081 and ip.of.server:8082. I just felt the
performance was a bit better when using the Motion web
server. It just seemed to be a bit smoother when a car drive
by, whereas with the video4.mjpg direct stream to the
camera, it certainly worked very decent, but I felt as
though I could notice some hesitation here and there as the
feed was displayed. I have to wonder if this is Motion being
smart enough to simply pass the stream it's already acquired
directly to the viewer instead of making the camera fire out
a secondary stream, like with running the regular Motion
process + streaming the direct mjpg URL to the browser.
Beyond this point I still have to wonder what the next
bottleneck is. I have to assume it's my software RAID array
writing to the hard drives. Part of me wants to get an SSD
and have the OS on it and point Motion to write data to it
as well. Then once a night via bash scripts move the data to
a fat RAID array in the system. That way I have the write
speed of an SSD while retaining the fat RAID array for long
Anyway like I said, nothing overly scientific, but it
brings enough of a visual to the table to suggest that
gigabit is your friend and Motion's built in web server
seems to be a bit lighter on the network load than direct
camera URL streaming.
As always, thanks for the insight. It's appreciated.
On Fri, Nov 23, 2012 at 11:49 PM,
Bob Bob <firstname.lastname@example.org>
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
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
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 it.
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
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 feed.
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 say.
Thanks again for your quick responses. Sorry
the solution was a bit of a face palm on my
Monitor your physical, virtual and cloud infrastructure
from a single
web console. Get in-depth insight into apps, servers,
SAP, cloud infrastructure, etc. Download 30-day Free
Pricing starts from $795 for 25 servers or applications!
Motion-user mailing list