Re: [Motion-user] 8081 - only port that's open?

[Jason S. <jas...@gm...>]

Yeah, that's kind of what I was thinking. One thing, speed wise, that it
doesn't compete in is just viewing the RTSP/H264 stream directly through
VLC or something. I'm pretty astonished at what video comes through with
the little network footprint that it takes up.

On that note, I had messaged the mailing list a few days ago but received
no response. I guess H264 isn't supported on Motion at all?

-J

On Thu, Nov 29, 2012 at 12:58 PM, David Horner <do...@co...> wrote:

>  If it seems to run faster from the motion server than from the camera it
> may be because motion takes the vid from the cam and compresses it again.
> It may do a better job than the raw feed from the camera so the bit rate
> may be less. also motion may fill in frames with earlier semi decoded
> frames and send it if it doesnt get enough data to build a full frame.
>
> On 11/23/2012 11:59 PM, Jason Sauders wrote:
>
> 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 192.168.1.15:8081 and
> 192.168.1.15:8082 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
> 192.168.1.11/video4.mjpg. 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: http://imgur.com/NlOpf
>
>  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.
> -J
>
> On Fri, Nov 23, 2012 at 11:49 PM, Bob Bob <bob...@bi...> 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.
>> -J
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Motion-user mailing list
>> Mot...@li...
>> https://lists.sourceforge.net/lists/listinfo/motion-user
>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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!http://p.sf.net/sfu/zoho_dev2dev_nov
>
>
>
> _______________________________________________
> Motion-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/motion-userhttp://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts
> and peers. http://goparallel.sourceforge.net
> _______________________________________________
> Motion-user mailing list
> Mot...@li...
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
>