Bob, thanks for your response. I do have a question for you. Were all 6 of these cameras wireless cameras, or did you have wired cameras on the LAN as well? I have to assume they were wireless, which based on that + everything else you said, yeah I can imagine it was a bit of a headache. 

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 and 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.

The System Monitor screenshot:

Based on the seconds counter just below the Network History graph (60, 50, 40, etc.) the different stages go like this:

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 explanatory.

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 term storage.

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 <> wrote:
Hi Jason

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 it.

Cheers Bob

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 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 part.

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
Motion-user mailing list