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? (tosiara)
----------------------------------------------------------------------
Message: 1
Date: Sun, 4 Apr 2021 08:44:07 +0300
From: tosiara <tosi...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Piping?
Message-ID:
<cachtdwsq6ep+_knev4unjrpwelgyaa8xd1vft3rnr6hhrgz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I will also add to MrDave's reply, the extpipe feature is only for
encoding. If you experience high load without even recording, this won't
help you in any way.
Extpipe is extremely useful in two cases:
1. Low power multi core systems. Allows to offload encoding to another
cores and save space for motion thread
2. Using custom third party hardware accelerated encoder/codec that motion
does not support
On Sat, Apr 3, 2021, 20:08 MrDave <motionmrd...@gmail.com> 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>
> 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> 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
>> > 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
>>
>
>
> _______________________________________________
> Motion-user mailing
> listMotion-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/motion-userhttps://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 3
*******************************************
