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: Image Corruption on RTSP streams (Pascal Martin)
2. Re: Image Corruption on RTSP streams (greg thomas)
3. Re: Image Corruption on RTSP streams (Dave Howorth)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Jan 2019 22:34:12 -0800
From: Pascal Martin <pascal.fb.mar...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Image Corruption on RTSP streams
Message-ID:
<CAOJ9py5TyQkURCWZuB5CjF=xxy0ctbjgxopemd+mxnna61w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am not sure what 35-40% utilization means in that case. Motion is single
threaded per camera, so each camera will not take more than 25% of the
entire pi CPU resources. Otherwise motion may be prevented from using the
CPU for other reasons.
I also noted that motion's CPU usage is highly variable, possibly due to
optimization in the case of no movement. This could mess up average CPU
usage.
The video game performance approach could be more appropriate. What is the
actual frame rate achieved by motion? Or, more practically, what is the
actual time spent by motion to process each frame? If this is more than 0.1
second, it would be too slow to sustain 10 fps.
One might want to record the millisecond accuracy time before processing
each frame. The average and variance of the delta could be telling.
Disclosure: I flunked stats in College. ?
Thanks.
Pascal.
From: greg thomas <geete...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Cc:
Bcc:
Date: Mon, 7 Jan 2019 22:07:31 +1300
Subject: Re: [Motion-user] Image Corruption on RTSP streams
The Pi it's running around 35-40% utilisation, so I don't think it's a
processor constraint. That said I still do not know what the cause is.
I know the corruption affects both cameras in the same way in color or
black and white/IR, and it only seems to impact the bottom 1/3ish of the
image.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Tue, 8 Jan 2019 20:18:58 +1300
From: greg thomas <geete...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Image Corruption on RTSP streams
Message-ID:
<CAGe5y2dbvtKB=6tuffd2unsxd5tj66b60hq-5bb0jc8xuh0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Pascal,
35% is overall system utilisation. From a motion perspective top shows
it as consuming ~145%, which I interpret as roughly 70% on each of two
cores given that I have two cameras, or ~35% of a four core system.
Greg
On Tue, 8 Jan 2019, 7:35 PM Pascal Martin <pascal.fb.mar...@gmail.com wrote:
> I am not sure what 35-40% utilization means in that case. Motion is single
> threaded per camera, so each camera will not take more than 25% of the
> entire pi CPU resources. Otherwise motion may be prevented from using the
> CPU for other reasons.
>
> I also noted that motion's CPU usage is highly variable, possibly due to
> optimization in the case of no movement. This could mess up average CPU
> usage.
>
> The video game performance approach could be more appropriate. What is the
> actual frame rate achieved by motion? Or, more practically, what is the
> actual time spent by motion to process each frame? If this is more than 0.1
> second, it would be too slow to sustain 10 fps.
>
> One might want to record the millisecond accuracy time before processing
> each frame. The average and variance of the delta could be telling.
>
> Disclosure: I flunked stats in College. ?
>
> Thanks.
> Pascal.
>
> From: greg thomas <geete...@gmail.com>
> To: Motion discussion list <motion-user@lists.sourceforge.net>
> Cc:
> Bcc:
> Date: Mon, 7 Jan 2019 22:07:31 +1300
> Subject: Re: [Motion-user] Image Corruption on RTSP streams
> The Pi it's running around 35-40% utilisation, so I don't think it's a
> processor constraint. That said I still do not know what the cause is.
>
> I know the corruption affects both cameras in the same way in color or
> black and white/IR, and it only seems to impact the bottom 1/3ish of the
> image.
>
> Regards
>
> _______________________________________________
> 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...
------------------------------
Message: 3
Date: Tue, 8 Jan 2019 09:39:31 +0000
From: Dave Howorth <d...@howorth.org.uk>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Image Corruption on RTSP streams
Message-ID: <20190108093931.34a98...@acer-suse.lan>
Content-Type: text/plain; charset=UTF-8
On Tue, 8 Jan 2019 20:18:58 +1300
greg thomas <geete...@gmail.com> wrote:
> Hi Pascal,
> 35% is overall system utilisation. From a motion perspective top
> shows it as consuming ~145%, which I interpret as roughly 70% on each
> of two cores given that I have two cameras, or ~35% of a four core
> system.
If you press the '1' key whilst in top, it shows individual CPU
core usage. Press '1' again to revert to normal overall usage.
> Greg
>
> On Tue, 8 Jan 2019, 7:35 PM Pascal Martin <pascal.fb.mar...@gmail.com
> wrote:
>
> > I am not sure what 35-40% utilization means in that case. Motion is
> > single threaded per camera, so each camera will not take more than
> > 25% of the entire pi CPU resources. Otherwise motion may be
> > prevented from using the CPU for other reasons.
> >
> > I also noted that motion's CPU usage is highly variable, possibly
> > due to optimization in the case of no movement. This could mess up
> > average CPU usage.
> >
> > The video game performance approach could be more appropriate. What
> > is the actual frame rate achieved by motion? Or, more practically,
> > what is the actual time spent by motion to process each frame? If
> > this is more than 0.1 second, it would be too slow to sustain 10
> > fps.
> >
> > One might want to record the millisecond accuracy time before
> > processing each frame. The average and variance of the delta could
> > be telling.
> >
> > Disclosure: I flunked stats in College. ?
> >
> > Thanks.
> > Pascal.
> >
> > From: greg thomas <geete...@gmail.com>
> > To: Motion discussion list <motion-user@lists.sourceforge.net>
> > Cc:
> > Bcc:
> > Date: Mon, 7 Jan 2019 22:07:31 +1300
> > Subject: Re: [Motion-user] Image Corruption on RTSP streams
> > The Pi it's running around 35-40% utilisation, so I don't think
> > it's a processor constraint. That said I still do not know what the
> > cause is.
> >
> > I know the corruption affects both cameras in the same way in color
> > or black and white/IR, and it only seems to impact the bottom
> > 1/3ish of the image.
> >
> > Regards
> >
> > _______________________________________________
> > 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
------------------------------
------------------------------
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 151, Issue 11
********************************************
