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: Piping? (Rainer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 Apr 2021 07:05:09 -0400
From: Rainer <feyerpictu...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Piping?
Message-ID: <d5ea4d4a-1942-f59f-b73c-20cba255f...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Wow - that made a difference!
1st I activated 8 of the 10 cameras.
2nd I changed all primary fps at the camera to 8 from 10, and
secondaries from 20 to 8 (didn't even know secondaries can be changed
down before yesterday): that brought CPU of 4 cores from 100% to avg 85%
3rd changed movie_passthrough to yes - brought it down to 80%
4th installed and utilized x264 which brought is down to 65% avergage!
That in itself is already a HUGE improvement, so, TY all!
I would like to try and implement the netcam_highres, but am not
understanding the directions in the doc.
If I read it correctly, one would have to use a separate URL for primary
and secondary streams? If that is so, I can not find an area in the
cameras internal setup which allows for dual URL's.
I am sure I am missing something simple.
Rainer
On 4/3/21 1:06 PM, MrDave wrote:
> I am guessing that the piping section that references a single thread
> is somewhere in the use_ext_pipe part of the guide.
>
> What this section is referring to is that creation of the movies and
> motion detection are on the same thread.? Offloading the movie
> creation to another thread could possibly help but I'd be skeptical
> that is would resolve this issue.
>
> For the set up that you referenced, I would guess that Motion started
> 25+ threads and reviewing htop you'll probably see that thread names
> that have a "nc" in them are consuming all the resources.? "nc" refers
> to network camera and those threads are doing the capturing and
> decoding of the images from the camera. The thread names that are
> doing the motion detection and writing of the movies/pictures have a
> "ml" in the name.? (motion loop)
>
> There are a couple of things to consider when looking at addressing
> cpu usage.
>
> 1.? Decoding H264/H265 images uses _significantly_ more CPU than the
> motion detection and is directly proportional to the size of the image.
>
> 2.? The settings of the camera (which Motion can't control) can have a
> large impact on CPU usage of Motion.? If you set the framerate in
> Motion to be 4 and the camera is sending images at 30 fps, you may
> have the impression that Motion is only running at 4 fps.? That is
> inaccurate.? The _motion detection _thread runs at 4 fps.? The
> capturing and decoding thread (i.e. the "nc" thread that consumes all
> the CPU) still runs at 30 fps because it must be in-sync or very close
> to the camera fps.? In Motion version 4.3.2, an explicit parameter was
> added to allow for changing the speed of this thread but it is still
> best to revise the parameter in the camera.? Changing that parameter
> to make Motion only capture and decode at 4fps when the camera is
> still at 30fps will result in the camera disconnecting constantly and
> decoding errors.
>
> 3.? Revising the I-Frame interval for the camera can help. I-Frames
> allow the decoder to skip steps since it provides full images.
>
> 4.? Using the pass-through/highres options is the developer
> recommended method for multiple cameras.? This method sets the
> secondary network camera stream as the primary in Motion to do the
> decoding and detection (e.g. 352x288 at 5fps).? Then the primary
> stream of the camera(e.g. 2592x1944 at 30fps) is used as the high
> resolution in Motion.? When motion is detected on the smaller image
> stream, it triggers recording on the larger stream.? Since there isn't
> any decoding or encoding on the larger image stream, the CPU use is
> minimal.? It is not perfect for all situations but should be considered.
>
> 5.? Resizing the image will use more resources than doing motion on
> the original image.? I have seen that some users will have the camera
> send the image at 2592x1944 and then have motion resize it to 352x288
> so that the motion detection is only being performed on the 352x288
> image.? This trade-off will rarely result in lower CPU.? Using the
> example above, the resizing is done on the 30fps thread versus the
> motion detection is on the 4fps thread.
>
> 6.? Use the pass-through without highres.? This could be needed if the
> camera only has one stream or if the user needs to have the live
> motion stream at full resolution.? In this situation, the decoding of
> the image still occurs but when motion is detected, movies are written
> directly to the file without the need to re-encode the images.
>
> 7.? If any of the camera streams provide images in mjpg rather than
> H264/H265 use those to avoid the CPU cost of H264/H265.
>
> 8.? If you want to compile from the Motion source code, there is a new
> option in there to use HW decoding if you have VAAPI.
>
>
> On 4/3/2021 7:46 AM, Harlan Daneker wrote:
>> I'm just going to tell you what I did then you can see if it works
>> for you.
>>
>> Installed? x264
>> movie_output off
>> movie_extpipe_use on
>> movie_extpipe x264 - --input-res %wx%h --fps %fps --bitrate 2000
>> --preset ultrafast --quiet -o %f.mp4
>>
>> On Sat, Apr 3, 2021 at 8:46 AM Roger Heflin <roger.hef...@gmail.com
>> <mailto:roger.hef...@gmail.com>> wrote:
>>
>> ??? In my experience motion uses a thread per camera by default.
>>
>> ??? type top and then hit "H" and it will show you the threads, my
>> ??? processes show as mlX:<cameraname> so long as they are separate
>> ??? listing in top then they are separate threads each capable of
>> using a
>> ??? cpu core.
>>
>> ??? With very many cameras running at 8fps CPU could be an issue on
>> ??? slower/older machines.
>>
>> ??? I have a 2 core set-top type box running 4 x 2560x1920 cam and
>> 2fps is
>> ??? using about 40% of the entire machine (passmark: 1127/1626). ?I use
>> ??? JPEG images and not video because the framerate can be turned down a
>> ??? lot further, and each image is a complete image, and my camera's
>> RTSP
>> ??? stream is UDP and 1 in 10k packets or so get lost causing false
>> motion
>> ??? detection.
>>
>> ??? The prior box I had was an even weaker set-top box and? for it to
>> run
>> ??? the framerates had to be even lower.
>>
>> ??? The passmark on your cpu is 1385/2208 (singlecore/wholemacine)
>> and it
>> ??? only has 2 actual cores, and 2 hyperthreads, so it is about 40%
>> faster
>> ??? than the machine I am referencing above.
>>
>>
>>
>>
>> ??? On Sat, Apr 3, 2021 at 6:48 AM Rainer <feyerpictu...@gmail.com
>> ??? <mailto:feyerpictu...@gmail.com>> wrote:
>> ??? >
>> ??? > Hi all,
>> ??? >
>> ??? > my question is about motion piping.
>> ??? >
>> ??? > I am using a Lenovo i5 4 core 650 CPU with 3.20 GHz x 4
>> ??? >
>> ??? > Currently using 3 cameras, all Hiks, 2 and 4 MP each. The
>> ??? cameras are
>> ??? > using up 30-35% resources.
>> ??? >
>> ??? > I have altogether 10 cameras, but when I use all of them in
>> ??? motion (even
>> ??? > without recording clips or pics) it chokes at 100% CPU use (all
>> ??? cores).
>> ??? >
>> ??? > As I am reading through the manpages again, i read a section on
>> ??? piping,
>> ??? > apparently making use of the cores as motion only uses single
>> ??? core, is
>> ??? > that correct?
>> ??? > Does anyone have experience with piping, would it possibly
>> ??? reduce the
>> ??? > CPU load?
>> ??? > Rainer
>> ??? >
>> ??? >
>> ??? >
>> ??? > _______________________________________________
>> ??? > Motion-user mailing list
>> ??? > Motion-user@lists.sourceforge.net
>> ??? <mailto:Motion-user@lists.sourceforge.net>
>> ??? > https://lists.sourceforge.net/lists/listinfo/motion-user
>> <https://lists.sourceforge.net/lists/listinfo/motion-user>
>> ??? > https://motion-project.github.io/
>> ??? <https://motion-project.github.io/>
>> ??? >
>> ??? > Unsubscribe:
>> ??? https://lists.sourceforge.net/lists/options/motion-user
>> <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://lists.sourceforge.net/lists/listinfo/motion-user>
>> ??? https://motion-project.github.io/
>> <https://motion-project.github.io/>
>>
>> ??? Unsubscribe:
>> ??? https://lists.sourceforge.net/lists/options/motion-user
>> <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
>
>
>
> _______________________________________________
> 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 178, Issue 4
*******************************************
