Send Motion-user mailing list submissions to
        motion-user@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
        motion-user-requ...@lists.sourceforge.net

You can reach the person managing the list at
        motion-user-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."


Today's Topics:

   1. Re: Motion 4.2.2 vs 4.1.1 CPU usage (MrDave)


----------------------------------------------------------------------

Message: 1
Date: Sun, 11 Aug 2019 09:48:26 -0600
From: MrDave <motionmrd...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Motion 4.2.2 vs 4.1.1 CPU usage
Message-ID: <6323cc9e-6e27-753a-43a5-080c416a0...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

In my opinion, the webcontrol is not going to have this impact. It runs 
all the time, serves up the page and then waits for next request.? The 
impact would be with the stream feed.? There is a testing option with

 ? stream_preview_method 99

that does not use MHD


On 8/11/2019 2:07 AM, tosiara wrote:
> 6 cameras is limited by your browser. Go to about:config and set 
> network.http.max-persistent-connections-per-server to something higher 
> than 6
>
> If you want to lower CPU on the server while watching all 6 or more 
> camera live streams - lower the stream's framerate. Encoding MJPEG at 
> higher framerates will consume significant resources. Motion's default 
> is 1 fps
>
> On Sat, Aug 10, 2019 at 10:17 PM rmbusy <rmbusy+mot...@gmail.com 
> <mailto:rmbusy%2bmot...@gmail.com>> wrote:
>
>     I know it's been awhile, but I finally have some useful
>     information to share on this topic.
>
>     After a lot of trial and error, I found 2 things contributing to
>     my higher CPU usage.? First is the setting of minimum_frame_time
>     in the motion.conf file.? I discovered that previously I had this
>     value set to 2, instead of the default of disabled.? Changing it
>     to 2 effectively lowered the runtime CPU utilization back to
>     around where it was previously with 4.1.1.? Whether or not this is
>     a good setting to have is still undecided.
>
>     The second issue, which seems to be the real problem for me, is
>     the new web interface.? When I connect to the 4.2.2 web interface
>     with a remote web browser (local machine is headless), the CPU
>     usage jumps from where ever it is (150% to 200%) to the max of
>     400%.? After that, the page becomes mostly non-responsive, and
>     causes the browser to use a lot of CPU on the remote machine.?
>     Also, with the new interface, it only shows the first 6 active
>     cameras on the main page (instead of the 8 I have configured).? If
>     one or more of the first 6 are not available (cameras haven't
>     responded yet at startup), then I'll see place holders for them,
>     and the remaining 7th and possibly 8th camera will be shown.
>
>     Is there a way to revert back to the 4.1.1 web server in 4.2.2 for
>     testing?? It looks like it was dropped from the build, but I
>     haven't dug into that too deeply yet.
>
>
>     --
>     Rob.
>
>
>
>     On 7/20/19 11:18 AM, tosiara wrote:
>>     Would be nice to see motion log from 4.1.1 and 4.2.2 first
>>
>>     On Sat, Jul 20, 2019 at 9:11 PM rmbusy <rmbusy+mot...@gmail.com
>>     <mailto:rmbusy%2bmot...@gmail.com>> wrote:
>>
>>         I heard you in the beginning Rusian, but I really want to
>>         understand why I'm seeing the increased CPU usage before I
>>         simply try reducing it by other means.? Believe me, your
>>         suggestion is on my list.? :-)
>>
>>
>>         --
>>         Rob.
>>
>>
>>         On 7/20/19 10:30 AM, Ruslan Matveev wrote:
>>>         Wow! Thats what I've been saying to topic starter from very
>>>         beginning ))
>>>
>>>         ??, 20 ???. 2019 ?., 20:28 tosiara <tosi...@gmail.com
>>>         <mailto:tosi...@gmail.com>>:
>>>
>>>             Solution for most popular RSTP cameras is to use low-res
>>>             secondary stream for motion detection, and main high-res
>>>             stream for pass through
>>>
>>>             On Sat, Jul 20, 2019 at 7:55 PM oleg.chekalin via
>>>             Motion-user <motion-user@lists.sourceforge.net
>>>             <mailto:motion-user@lists.sourceforge.net>> wrote:
>>>
>>>                 Hi All,
>>>
>>>                 Then if all is bad as is, could someone propose a
>>>                 solution, to avoid the high load impact to processor?
>>>
>>>                 I mean seam no way for capturing rtsp without
>>>                 coding/decoding date?
>>>
>>>                 Regards,
>>>                 Oleg
>>>
>>>
>>>
>>>                 ?????????? ? MI MAX 2
>>>                 tosiara <tosi...@gmail.com
>>>                 <mailto:tosi...@gmail.com>> | ??: 20 ???. 2019 ?.
>>>                 6:53 ?? | ?????????:
>>>
>>>                     I have tested RTSP H264 1280x960 20 fps running
>>>                     on ARM ODROID C1.
>>>                     Just running, without any recording it takes
>>>                     130% CPU. 4.1.1, 4.2.2, Ubuntu 16.04 and 18.04 -
>>>                     the result was always the same. NEON
>>>                     optimizations reduced to 125%, not much. Pretty
>>>                     all the time motion was decoding H264. The
>>>                     decoding, as already mentioned, is very CPU
>>>                     intensive
>>>
>>>                     On Sat, Jul 20, 2019 at 5:36 PM Colin Law
>>>                     <clan...@gmail.com <mailto:clan...@gmail.com>>
>>>                     wrote:
>>>
>>>                         On Sat, 20 Jul 2019 at 15:24, John D.
>>>                         Gwinner <j...@gwinner.org
>>>                         <mailto:j...@gwinner.org>> wrote:
>>>
>>>                             Ok, that helps me with my project ? we
>>>                             need to get 15fps or 30fps; (it?s a
>>>                             medical project).
>>>
>>>                             If you?re getting 2-5 and that high a
>>>                             CPU rate, clearly we?ll never get to 15.
>>>
>>>
>>>                         It also depends dramatically on the format
>>>                         of the data.? If it is mpjpeg for example
>>>                         then motion need do very little to decode
>>>                         the image, if however it is H264 then there
>>>                         is a vast amount of work required just
>>>                         extracting the images from the stream.? On
>>>                         my system running an H264 camera a lot more
>>>                         processor time is spent decoding the stream
>>>                         than is spent in motion detection.
>>>
>>>                         Colin
>>>                         _______________________________________________
>>>                         Motion-user mailing list
>>>                         Motion-user@lists.sourceforge.net
>>>                         <mailto:Motion-user@lists.sourceforge.net>
>>>                         
>>> https://lists.sourceforge.net/lists/listinfo/motion-user
>>>                         https://motion-project.github.io/
>>>
>>>                         Unsubscribe:
>>>                         
>>> https://lists.sourceforge.net/lists/options/motion-user
>>>
>>>                 _______________________________________________
>>>                 Motion-user mailing list
>>>                 Motion-user@lists.sourceforge.net
>>>                 <mailto:Motion-user@lists.sourceforge.net>
>>>                 https://lists.sourceforge.net/lists/listinfo/motion-user
>>>                 https://motion-project.github.io/
>>>
>>>                 Unsubscribe:
>>>                 https://lists.sourceforge.net/lists/options/motion-user
>>>
>>>             _______________________________________________
>>>             Motion-user mailing list
>>>             Motion-user@lists.sourceforge.net
>>>             <mailto:Motion-user@lists.sourceforge.net>
>>>             https://lists.sourceforge.net/lists/listinfo/motion-user
>>>             https://motion-project.github.io/
>>>
>>>             Unsubscribe:
>>>             https://lists.sourceforge.net/lists/options/motion-user
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Motion-user mailing list
>>>         Motion-user@lists.sourceforge.net  
>>> <mailto:Motion-user@lists.sourceforge.net>
>>>         https://lists.sourceforge.net/lists/listinfo/motion-user
>>>         https://motion-project.github.io/
>>>
>>>         Unsubscribe:https://lists.sourceforge.net/lists/options/motion-user
>>
>>         _______________________________________________
>>         Motion-user mailing list
>>         Motion-user@lists.sourceforge.net
>>         <mailto:Motion-user@lists.sourceforge.net>
>>         https://lists.sourceforge.net/lists/listinfo/motion-user
>>         https://motion-project.github.io/
>>
>>         Unsubscribe:
>>         https://lists.sourceforge.net/lists/options/motion-user
>>
>>
>>
>>     _______________________________________________
>>     Motion-user mailing list
>>     Motion-user@lists.sourceforge.net  
>> <mailto:Motion-user@lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/motion-user
>>     https://motion-project.github.io/
>>
>>     Unsubscribe:https://lists.sourceforge.net/lists/options/motion-user
>
>     _______________________________________________
>     Motion-user mailing list
>     Motion-user@lists.sourceforge.net
>     <mailto:Motion-user@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/motion-user
>     https://motion-project.github.io/
>
>     Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------



------------------------------

Subject: Digest Footer

_______________________________________________
Motion-user mailing list
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user


------------------------------

End of Motion-user Digest, Vol 158, Issue 19
********************************************

Reply via email to