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 crashing or stops working (Harlan Daneker)
2. Re: motion crashing or stops working (S Andreason)
3. Re: motion crashing or stops working (Harlan Daneker)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Feb 2021 15:32:41 -0500
From: Harlan Daneker <hdane...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] motion crashing or stops working
Message-ID:
<CAC1WkiRVwZxFwwntYUnfGF08UfJsbeE4i2h14j3cyMSbq=x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I just wanted to mention I had trouble with grey frames with cameras that
use the h.265 codec. htop will tell you the percent of CPU usage for each
thread.
On Thu, Feb 25, 2021 at 3:20 PM S Andreason <sandrea...@gmail.com> wrote:
> Good questions,
>
> I tried both versions, on both pi's, of course the one watching 3
> cameras at 640x480 has higher cpu% than 1 camera at 640x480.
>
> Considering slightly different amount of movement outside, but very
> close to none, I don't really see a big change between versions (second
> and third columns of 6).
> max / min top% over a minute:
> pi (cams) 4.3.1git 4.3.2 4.3.2+1web 4.3.2+2web 1
> event
> pi1 (3) 5 70.5 / 54.2 74.1 / 57.5 67.8 / 58.1 67.9 /
> 57.3 137.5 /
>
> pi3 (1) 9 - / - 16.2 / 13.9 18.9 / 14.9
> pi3 (1) 5 16.6 / 11.9
>
> If I intentionally move 3 cameras at same time to max it out,
> pi1 (3) 5 3 events = 300.3% / __
> So the above normal usage is well under 400% (4 cores)
>
> I thought I would see a big change with log_level at 9 but it did not do
> the 45 lines per second dump into motion.log this time. I don't
> understand what triggered that this morning...
>
> Since the majority of my grey frames (or rainbow smudges) were at low
> movement levels, and only one camera having an event, I can infer they
> had low cpu load.
> But yes I can see how high cpu load would would cause problems. Although
> when I was testing to determine how many cams a pi could manage, I found
> it drops frame rate first, so a 15 fps camera drops to 12 or 13 fps in
> the output video. But 640x480 it handles ok. High res 2560x1440 it can't
> handle even one stream fully at 10 fps. It can manage 6 fps.
>
> I opened 2 pages in 2 tabs, and then 2 different browsers, and did not
> see any change, I saw maybe 2% difference, but not consistently. However
> the reloading jpeg image for me does not load, so I think I'd need to
> figure out how to get past that block to make it work harder.
> More directly, If I load from my browser
> http://192.168.5.121:8081/stream
> I get error: The connection was refused, and Page load error.
>
> This has not bothered me since I use mpv to watch streams live.
>
> I don't have any firewall settings to block it, so maybe I should ask
> how to get that working across the local network?
> Can the stream be delivered to an address other than 127.0.0.1?
>
>
>
>
> rmbusy wrote:
> > Out of curiosity, what does "top" show for CPU usage with both
> > versions? Whenever I get grey screens, or corrupted video from
> > streaming cameras, it has a direct correlation to CPU usage maxing
> > out. Typically I'll need to reboot the cameras once they get into that
> > state.
> >
> > On my system (quad core, ARM based, 400% CPU max), top shows the CPU
> > usage is around 175% to 200% w/o a browser connected. If I connect to
> > the built in web page, it maxes out around 375%. If I open a second
> > page from another browser, then cameras start failing.
> >
> >
>
>
>
> _______________________________________________
> 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: 2
Date: Thu, 25 Feb 2021 13:28:38 -0800
From: S Andreason <sandrea...@gmail.com>
To: Motion-user <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] motion crashing or stops working
Message-ID: <7b7a1ca5-5a23-1b62-c886-02e7f95bb...@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Right. jumping around in the stream does leave the decoder confused
until the next valid I-frame is received.
Let's look at what I have configured:
203_T: Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568),
yuvj420p(pc, bt470bg/bt470bg/smpte170m), 640x480, 493 kb/s, 15.32 fps,
15 tbr, 90k tbn, 15 tbc (default)
204_W: Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568),
yuvj420p(pc), 640x480, 171 kb/s, 10.07 fps, 10 tbr, 90k tbn, 90k tbc
(default)
206_E: Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568),
yuvj420p(pc), 640x480, 93 kb/s, 10.03 fps, 10 tbr, 90k tbn, 90k tbc
(default)
205_N: Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661),
yuvj420p(pc, bt709), 640x480, 733 kb/s, 15.19 fps, 15 tbr, 90k tbn, 30
tbc (default)
Oh Hikvision is not directly comparible. I recall vaguely I didn't like
something about their H.265 implementation.
Idea... I'll change the Alptops to H264, and restarting to motion-4.3.1+git
204_W and 206_E: Stream #0:0(und): Video: h264 (Main) (avc1 /
0x31637661), yuvj420p(pc), 640x480, 560 kb/s, 15.45 fps, 15 tbr, 90k
tbn, 180k tbc (default)
Still has a delay, although 3-4 seconds is not as bad as 8. Probably
worsens over time.
I'll have to wait 28 minutes to start seeing today's issue#1.
mpv for H.264 is a bit smarter about not displaying incomplete frames,
it freezes for a second or 2 until the next I-frame arrives. Not exactly
relevant to the problem.
If I move the camera, it does not have grey frames now, of course, but I
do see it lost 3 frames after 0.47 sec, and the clock shows the next
frame at 0.758 sec is an I-frame as the camera's clock advanced to the
next second consistent with a GOP (Group Of Pictures) of 30 = 2 sec. I'm
not sure which case that supports. The pi might have lost frames due to
cpu load, but the first 8 frames were written/encoded properly. Also no
frames were lost afterward.
When I tried moving the camera yesterday, I did see grey frames etc
during movement, in fact several times during movement there were
corrupted and jumps of missing frames. So not just at the beginning
second when the encoder is catching up. Maybe I should've shared That
video... if it's relevant without complicating the bug report.
Put simply, before trying 4.3.1+git, I have never seen this level of
corruption making the resulting video unusable.
I think the problem is how motion advances the stream to "live" is
different for this camera, To the point, it doesn't succeed.
Yes, htop gives 2 more ways to count cpu%
? 1? [|||||||||???????????????????? 21.3%]?? Tasks: 35, 30 thr; 1 running
? 2? [||||||||||??????????????????? 25.7%]?? Load average: 0.72 0.53 0.59
? 3? [|||||???????????????????????? 11.5%]?? Uptime: 06:47:02
? 4? [||||????????????????????????? 11.4%]
? Mem[|||????????????????????? 131M/7.27G]
? Swp[????????????????????????? 0K/100.0M]
? PID USER????? PRI? NI? VIRT?? RES?? SHR S CPU% MEM%?? TIME+ Command
?5485 motion???? 20?? 0? 364M 82984 28048 S 73.6? 1.1? 2:14.87
/usr/bin/motion
?5492 motion???? 20?? 0? 364M 82984 28048 S 20.1? 1.1? 0:43.60
/usr/bin/motion
?5489 motion???? 20?? 0? 364M 82984 28048 S 14.0? 1.1? 0:18.48
/usr/bin/motion
?5494 motion???? 20?? 0? 364M 82984 28048 S 12.7? 1.1? 0:20.04
/usr/bin/motion
?5493 motion???? 20?? 0? 364M 82984 28048 S 10.0? 1.1? 0:17.70
/usr/bin/motion
?5491 motion???? 20?? 0? 364M 82984 28048 S? 8.7? 1.1? 0:16.75
/usr/bin/motion
?5490 motion???? 20?? 0? 364M 82984 28048 S? 7.4? 1.1? 0:16.32
/usr/bin/motion
?5499 pi???????? 20?? 0? 7960? 2792? 2436 R? 0.7? 0.0? 0:02.14 htop
That is pi1 running motion-4.3.1+git for 3 cams
And... 37 minutes later, no false events. But since H264 does not have
the grey frame symptom, and just freezes until the next I-frame, then
it's reasonable to imagine it will just have moments of not watching
until the next I-frame, and there's no way to know about it.
So, a workaround that is. Change to H264 we must.
But the delay... is now up to 7 seconds. Still a very big problem.
Harlan Daneker wrote:
> I just wanted to mention I had trouble with grey frames with cameras
> that use the h.265 codec. htop will tell you the percent of CPU usage
> for each thread.
>
------------------------------
Message: 3
Date: Thu, 25 Feb 2021 16:54:29 -0500
From: Harlan Daneker <hdane...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] motion crashing or stops working
Message-ID:
<cac1wkirckcramnbpwjt7c_j8hz5obkb6j-rzcysm1dkzbhz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
For some UNKNOWN reason "changing the video format from 60hz to 50hz solved
my delay problems". It makes zero sense, but it worked. May be something
that only affects the cameras I'm using.
On Thu, Feb 25, 2021 at 4:29 PM S Andreason <sandrea...@gmail.com> wrote:
> Right. jumping around in the stream does leave the decoder confused
> until the next valid I-frame is received.
>
> Let's look at what I have configured:
> 203_T: Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568),
> yuvj420p(pc, bt470bg/bt470bg/smpte170m), 640x480, 493 kb/s, 15.32 fps,
> 15 tbr, 90k tbn, 15 tbc (default)
> 204_W: Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568),
> yuvj420p(pc), 640x480, 171 kb/s, 10.07 fps, 10 tbr, 90k tbn, 90k tbc
> (default)
> 206_E: Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568),
> yuvj420p(pc), 640x480, 93 kb/s, 10.03 fps, 10 tbr, 90k tbn, 90k tbc
> (default)
> 205_N: Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661),
> yuvj420p(pc, bt709), 640x480, 733 kb/s, 15.19 fps, 15 tbr, 90k tbn, 30
> tbc (default)
>
> Oh Hikvision is not directly comparible. I recall vaguely I didn't like
> something about their H.265 implementation.
>
> Idea... I'll change the Alptops to H264, and restarting to motion-4.3.1+git
> 204_W and 206_E: Stream #0:0(und): Video: h264 (Main) (avc1 /
> 0x31637661), yuvj420p(pc), 640x480, 560 kb/s, 15.45 fps, 15 tbr, 90k
> tbn, 180k tbc (default)
>
> Still has a delay, although 3-4 seconds is not as bad as 8. Probably
> worsens over time.
>
> I'll have to wait 28 minutes to start seeing today's issue#1.
>
> mpv for H.264 is a bit smarter about not displaying incomplete frames,
> it freezes for a second or 2 until the next I-frame arrives. Not exactly
> relevant to the problem.
>
> If I move the camera, it does not have grey frames now, of course, but I
> do see it lost 3 frames after 0.47 sec, and the clock shows the next
> frame at 0.758 sec is an I-frame as the camera's clock advanced to the
> next second consistent with a GOP (Group Of Pictures) of 30 = 2 sec. I'm
> not sure which case that supports. The pi might have lost frames due to
> cpu load, but the first 8 frames were written/encoded properly. Also no
> frames were lost afterward.
> When I tried moving the camera yesterday, I did see grey frames etc
> during movement, in fact several times during movement there were
> corrupted and jumps of missing frames. So not just at the beginning
> second when the encoder is catching up. Maybe I should've shared That
> video... if it's relevant without complicating the bug report.
> Put simply, before trying 4.3.1+git, I have never seen this level of
> corruption making the resulting video unusable.
>
>
> I think the problem is how motion advances the stream to "live" is
> different for this camera, To the point, it doesn't succeed.
>
> Yes, htop gives 2 more ways to count cpu%
> 1 [||||||||| 21.3%] Tasks: 35, 30 thr; 1 running
> 2 [|||||||||| 25.7%] Load average: 0.72 0.53 0.59
> 3 [||||| 11.5%] Uptime: 06:47:02
> 4 [|||| 11.4%]
> Mem[||| 131M/7.27G]
> Swp[ 0K/100.0M]
>
> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
> 5485 motion 20 0 364M 82984 28048 S 73.6 1.1 2:14.87
> /usr/bin/motion
> 5492 motion 20 0 364M 82984 28048 S 20.1 1.1 0:43.60
> /usr/bin/motion
> 5489 motion 20 0 364M 82984 28048 S 14.0 1.1 0:18.48
> /usr/bin/motion
> 5494 motion 20 0 364M 82984 28048 S 12.7 1.1 0:20.04
> /usr/bin/motion
> 5493 motion 20 0 364M 82984 28048 S 10.0 1.1 0:17.70
> /usr/bin/motion
> 5491 motion 20 0 364M 82984 28048 S 8.7 1.1 0:16.75
> /usr/bin/motion
> 5490 motion 20 0 364M 82984 28048 S 7.4 1.1 0:16.32
> /usr/bin/motion
> 5499 pi 20 0 7960 2792 2436 R 0.7 0.0 0:02.14 htop
>
> That is pi1 running motion-4.3.1+git for 3 cams
>
> And... 37 minutes later, no false events. But since H264 does not have
> the grey frame symptom, and just freezes until the next I-frame, then
> it's reasonable to imagine it will just have moments of not watching
> until the next I-frame, and there's no way to know about it.
>
> So, a workaround that is. Change to H264 we must.
> But the delay... is now up to 7 seconds. Still a very big problem.
>
>
> Harlan Daneker wrote:
> > I just wanted to mention I had trouble with grey frames with cameras
> > that use the h.265 codec. htop will tell you the percent of CPU usage
> > for each thread.
> >
>
>
>
> _______________________________________________
> 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 176, Issue 37
********************************************
