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: Gray glitching but only one of of two identical cameras
(Barry Martin)
2. Re: Gray glitching but only one of of two identical cameras
(Roger Heflin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 27 May 2021 07:41:18 -0500
From: Barry Martin <barry3mar...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Gray glitching but only one of of two
identical cameras
Message-ID: <176100d0-9db8-5c96-7854-754202c43...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Roger!
frame rate and? fps are both the same.? If it is unable to sustain the
framerate I would think that means that is not always able to get the
needed usb bandwidth. Maybe reduce both camera's framerate to lower
until both are able to keep the framerate.??? Anything set in the main
motion.conf file seems to be inherited by the thread*.conf files. The
thread*.conf files settings overrides for the specific camera from what
I can tell.
Thanks to the confirmation on both (framerate = fps and *.conf
overriding motion.conf, or conversely passing through). One (of many!)
things that confused me is I had set framerate to various values and
generally didn?t seem to get followed: I sort of expected it to be the
ten (currently five) value in the %fps variable in the camera name:
*text_left Front Yard CAMERA 1 - fps %fps-*
The recorded videos seem to have five ?steps? ? HH:MM:SS-qq In
motion.conf the command line is
/text_right %Y-%m-%d\n%T-%q/ ? the old version had a list of variables
built in, current ones doesn?t. The ones when set at framerate 10 would
?count to ten?.
Are you using mjpeg/x264 for the usb camera streams?
Yes: *v4l2_palette 8* is in the commands. The other day I was
experimenting with a few of the palette numbers (7, 9, 21, maybe a few
others) and ?oddly? (for me?!) they all gave a 4:3 output instead of
16:9. sudo service motion restart to upate.
FWIW: *v4l2-ctl -V -d /dev/video4* (same for /dev/video0, Camera 2 and
1, respectively)
Format Video Capture:
Width/Height : 1280/720
Pixel Format : 'MJPG' (Motion-JPEG)
Field : None
Bytes per Line : 0
Size Image : 1843789
Colorspace : Default
Transfer Function : Default (maps to Rec. 709)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Full Range)
Flags :
Just in case you or someone sees something.
Almost no computer is going to survive 120-130.
Heck, I?m almost not going to survive! Don?t treat your computer(s) to
stuff you wouldn?t like! <g> (Knew it got rather warm in there, didn?t
know it got_that_hot!)
As for the possibility of the cameras overheating, the working
temperature of the ELP camera I think is the equivalent of the SVPro
cameras I have is -10?70? (14? - 158?F). I?m not sure the SVPro camera
has the same specifications. Have measured 103?F at the window ? within
the ELP specs?..
...OK, started last night, continuing this morning. Woke up to no video
feed. <grumble> No idea when it quit. Both cameras have recordings
through 6:07 a.m.: Camera1 is a 0 byte mkv file, Camera2 was doing a
recording starting about a minute earlier. Get close to the end of 6:06
it starts to freeze-continue-freeze at early in 6:07. which is the time
Camera1 should have picked up the motion being tracked. It?s also 55?F
out there, so the cameras should be cool. Not saying heat isn?t an
issue, but should be an issue this instance.
I need to get get individual logging going. Tried yesterday and caused
the video feed to not occur: read as offline/incorrect, same as when I
need to restart Motion. I did try to place the log to my NAS, same as to
where the videos are recorded, if that?s a clue.
Most of my cams are POE cams, so I might just have to run a wire or 2
out to where I needed it.? I already ran one remote wire/power/water and
have a cam sitting on the end of about 400ft of 100mbit/POE and it is
working even though it is at least 70ft over officially supported
distance. ?? POE is nice since I can have a single much larger machine
sitting on a UPS someplace cool, with the UPS also powering the POE
cameras so all has battery backup.
The RPi itself is in a clothes closet which gets warm in Summer ? the
Storage Area is on the other side. Not recalling if I added the heat
sinks to it (probably) but it is in a case with a fan. vcgencmd
measure_temp was running 49-54?C yesterday ? seems the highest was just
after a loss of the video (several times I caught it black out and so
was able to check immediately). (Right now it?s 49.1?C. and appears to
be running normally. ...Hmmm: Rube Goldberg script: if temp >52 do
motion reset !!)
The RPi is on it?s own UPS ? not the HAT type, regular standalone.
The pte would seem to be related to memory mapping for the video card,
and seems to limit the video resolution that the 32bit version can do.
OK ? semi-understand that. The setting of GPU Memory in the RPI4?s seems
to be opposite of what was done with the RPi3?s. In the 3?s more memory
allocated for the GPU just mean less (so slower) for the CPU. In the
RPi4 too much gpu_mem and the system won?t boot (!). A while back I
happily upped it to 1024 (so one-quarter of the total memory) ? wouldn?t
boot. Read where people have used 512 and their Pi wouldn?t boot.
...Mine?s at 512 (wonder if maybe I should cut that).
Barry
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Thu, 27 May 2021 09:47:56 -0500
From: Roger Heflin <roger.hef...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Gray glitching but only one of of two
identical cameras
Message-ID:
<CAAMCDedMeNuZLHrgX2FBQAY=o8DPTJcHK=jrcumcfynw9qt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, May 27, 2021 at 7:42 AM Barry Martin <barry3mar...@gmail.com> wrote:
>
> Hi Roger!
>
>
> frame rate and fps are both the same. If it is unable to sustain the
> framerate I would think that means that is not always able to get the
> needed usb bandwidth. Maybe reduce both camera's framerate to lower until
> both are able to keep the framerate. Anything set in the main
> motion.conf file seems to be inherited by the thread*.conf files. The
> thread*.conf files settings overrides for the specific camera from what I
> can tell.
>
>
> Thanks to the confirmation on both (framerate = fps and *.conf overriding
> motion.conf, or conversely passing through). One (of many!) things that
> confused me is I had set framerate to various values and generally didn?t
> seem to get followed: I sort of expected it to be the ten (currently five)
> value in the %fps variable in the camera name: *text_left Front Yard
> CAMERA 1 - fps %fps-*
>
>
> The recorded videos seem to have five ?steps? ? HH:MM:SS-qq In motion.conf
> the command line is
>
> *text_right %Y-%m-%d\n%T-%q* ? the old version had a list of variables
> built in, current ones doesn?t. The ones when set at framerate 10 would
> ?count to ten?.
>
>
>
> Are you using mjpeg/x264 for the usb camera streams?
>
>
> Yes: *v4l2_palette 8* is in the commands. The other day I was
> experimenting with a few of the palette numbers (7, 9, 21, maybe a few
> others) and ?oddly? (for me?!) they all gave a 4:3 output instead of 16:9.
> sudo service motion restart to upate.
>
>
> FWIW: *v4l2-ctl -V -d /dev/video4* (same for /dev/video0, Camera 2 and 1,
> respectively)
>
> Format Video Capture:
>
> Width/Height : 1280/720
>
> Pixel Format : 'MJPG' (Motion-JPEG)
>
> Field : None
>
> Bytes per Line : 0
>
> Size Image : 1843789
>
> Colorspace : Default
>
> Transfer Function : Default (maps to Rec. 709)
>
> YCbCr/HSV Encoding: Default (maps to ITU-R 601)
>
> Quantization : Default (maps to Full Range)
>
> Flags :
>
I don't see an equivalent command from v4l2-ctl, for webcam's I always use
this tool:
uvcdynctrl -f -d /dev/video3
-f will list out all of the resolutions, palettes, and framerates
combinations that the camera claims it supports.
> Just in case you or someone sees something.
>
>
> Almost no computer is going to survive 120-130.
>
> Heck, I?m almost not going to survive! Don?t treat your computer(s) to
> stuff you wouldn?t like! <g> (Knew it got rather warm in there, didn?t know
> it got *that* hot!)
>
>
> As for the possibility of the cameras overheating, the working
> temperature of the ELP camera I think is the equivalent of the SVPro
> cameras I have is -10?70? (14? - 158?F). I?m not sure the SVPro camera
> has the same specifications. Have measured 103?F at the window ? within the
> ELP specs?..
>
I would not count on the spec having actually been tested. They probably
needed a spec and as such guessed, and never actually did a test. I have
dealt with too many motherboard manufacturers where the "test" was simply
to install it and verify that it survived POST. They never ran a
functional test and/or verified that it worked perfectly 99.99% of the
time. The image sensor itself is rated to 75C (likey the die itself being
75C), I cannot believe that from the sensor inside that case to the
external case would only be a 5C higher.
>
> ...OK, started last night, continuing this morning. Woke up to no video
> feed. <grumble> No idea when it quit. Both cameras have recordings through
> 6:07 a.m.: Camera1 is a 0 byte mkv file, Camera2 was doing a recording
> starting about a minute earlier. Get close to the end of 6:06 it starts to
> freeze-continue-freeze at early in 6:07. which is the time Camera1 should
> have picked up the motion being tracked. It?s also 55?F out there, so the
> cameras should be cool. Not saying heat isn?t an issue, but should be an
> issue this instance.
>
>
> I need to get get individual logging going. Tried yesterday and caused the
> video feed to not occur: read as offline/incorrect, same as when I need to
> restart Motion. I did try to place the log to my NAS, same as to where the
> videos are recorded, if that?s a clue.
>
>
>
> Most of my cams are POE cams, so I might just have to run a wire or 2 out
> to where I needed it. I already ran one remote wire/power/water and have a
> cam sitting on the end of about 400ft of 100mbit/POE and it is working even
> though it is at least 70ft over officially supported distance. POE is
> nice since I can have a single much larger machine sitting on a UPS
> someplace cool, with the UPS also powering the POE cameras so all has
> battery backup.
>
>
> The RPi itself is in a clothes closet which gets warm in Summer ? the
> Storage Area is on the other side. Not recalling if I added the heat sinks
> to it (probably) but it is in a case with a fan. vcgencmd measure_temp was
> running 49-54?C yesterday ? seems the highest was just after a loss of the
> video (several times I caught it black out and so was able to check
> immediately). (Right now it?s 49.1?C. and appears to be running normally.
> ...Hmmm: Rube Goldberg script: if temp >52 do motion reset !!)
>
That could be. Note that I have had 2 separate laptops were the USB chips
got flakey and stopped working. Given it is a laptop I suspected that the
heat design around the usb was less than great. It might be that other
chips on the PI need heatsinks. If it was just the usb chip overheating
that would probably not crash the PI since the usb hardware seems to get
random bad data all of the time and the usb driver/software stack reports
it and does not crash. Does dmesg show weird USB messages? It may be
simply it quits getting anything. I had some poorly designed motherboards
that would randomly report no link on the network without the cable or
switch doing anything odd. When we were trying to duplicate it in our our
and could not I finally guessed heat and the guy doing the testing used
something to limit its ability to remove heat and it did it. Once we
found this, it also explained why on this motherboard we kept having the
network port simply die permanently. The heat was causing the link loss
and was also causing the chips to die really fast Note the chip itself
was an intel, but the motherboard maker did not put a heat sink on it (the
other mb's we checked all had heat sinks). Do not count on anyone doing
board manufacturer on the low end doing a complete function test across the
temps. The chip makers will have done that and the major vendors will
have, but once you get down to the low end no one does much testing.
Often the MB sensor do not have the offset set right (ie +5 is more or less
+5 but the base of 49 maybe 40 or may be 59). I would probably heat sink
everything you can and see where the airflow is. The network chipset that
overheated tended to be in a 2u and/or 4u machines...the tiny 1u's were
just find because the airflow was well constrained and flowing over the
heatsinkless chip enough to cool it. On the 4u/2u's the cases had greater
airflow than the 1u cases but the airflow was not where it needed to be.
This would probably be a good usage for one of those thermal cameras. You
might just see what all you can put on a heat sink, and you might see if
there are any air holes/inlets in the case that would provide airflow
across the USB chip.
>
> The RPi is on it?s own UPS ? not the HAT type, regular standalone.
>
>
>
>
> The pte would seem to be related to memory mapping for the video card, and
> seems to limit the video resolution that the 32bit version can do.
>
>
> OK ? semi-understand that. The setting of GPU Memory in the RPI4?s seems
> to be opposite of what was done with the RPi3?s. In the 3?s more memory
> allocated for the GPU just mean less (so slower) for the CPU. In the RPi4
> too much gpu_mem and the system won?t boot (!). A while back I happily
> upped it to 1024 (so one-quarter of the total memory) ? wouldn?t boot. Read
> where people have used 512 and their Pi wouldn?t boot. ...Mine?s at 512
> (wonder if maybe I should cut that).
>
>
>
5-10 years ago I had to move to 64bit (recompiled kernel 64bit with the
same 32bit user space I was using before) because the mdraid functions in
the kernel needed memory from a special allocation type and the address
space for that allocation type was very limited with the 32-bit kernel
(regardless of free ram).
-------------- 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 179, Issue 32
********************************************
