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. Problem with (both camera's and motion's) auto-brightness
adjustment (Jay Sekora)
2. Re: Problem with (both camera's and motion's) auto-brightness
adjustment (Barry Martin)
3. Re: Problem with (both camera's and motion's) auto-brightness
adjustment (Jay Sekora)
----------------------------------------------------------------------
Message: 1
Date: Mon, 31 May 2021 12:29:03 -0400
From: Jay Sekora <j...@aq.org>
To: motion-user@lists.sourceforge.net
Subject: [Motion-user] Problem with (both camera's and motion's)
auto-brightness adjustment
Message-ID: <11935.1622478...@aq.org>
Content-Type: text/plain; charset="us-ascii"
(My apologies for not doing a very thorough search of the list archives;
the search interface is _really_ cumbersome! I did check recent hits,
though.)
I have a Raspberry Pi 4 with a couple of cheap outdoor USB security
cameras (this model: https://smile.amazon.com/gp/product/B07C2RL8PB/)
connected to it (with active USB repeater cables because of the
distance) so we can watch the wildlife and outdoor cats in our yard.
Out of the box, the cameras did their own adequate brightnesss control,
and I got reasonable (if not great) pictures in all lighting conditions.
At some point, they both simultaneously lost that ability -- they both
just stayed at constant gain and brightness, resulting in illegible
images most of the time. This happened to be right after a power
outage, but I don't see how that could have been the cause, given that
I'd been randomly plugging and unplugging them from time to time to
reroute cables with no ill effects, and that both had the same thing
happen at once. I *had* been experimenting a bit with v4l2-ctl, so
it's possible I somehow got the cameras in a state I didn't know how
to get them out of, but I'd been avoiding anything about automatic
brightness adjustment (since it was working) and I didn't notice the
change in behavior until after the power outage.
Once I noticed the cameras were no longer doing their own brightness
adjustment, I experimented more with manually adjusting their
settings, and discovered I could get much better quality images by
tweaking settings manually. But of course for best quality I had
to do that more or less constantly in real time as lighting
conditions changed. (I also tried without success to get the cameras
to do their own automatic brightness adjustment again.)
One oddity I noticed was that the image brightness did not increase
monotonically with increases in "exposure_absolute". (I *think*
the same thing was true of increases in "brightness", but I don't
remember for sure. Most of the time, increasing the value of
"exposure_absolute" by 1 would result in a slight increase in the
brightness of the image, but here and there there were places where
increasing the value of "exposure_absolute" by 1 would noticeably
*decrease* the brightness of the image. (And those seemed to be
consistent spots along the range.)
I tried turning auto_brightness on in the Motion config (and tried
the various methods of adjusting it), and what happened would be that
I would get videos that would start to brighten or dim and then
very quickly would start flashing dramatically from way overexposed
to super-dim. It seems like what would happen if both Motion and the
camera itself were trying to adjust brightness automatically, but if
so that's the only way in months I've gotten the cameras to do that,
and it's not helpful. :-) If Motion were trying to slowly increase
or decrease the brightness and got to one of those discontinuous spots,
I'd expect to see flickering, but not nearly so dramatic changes in
exposure.
For now I've sort-of worked around the problem by setting up cron
jobs to set good-enough-for-most-days parameters in the morning and
the evening, but of course that's crummy on overcast or very bright days
and the times should really be adjusted by season. (If I remember to
check, I tweak things manually.) Also, the cameras turn on their IR
illumination based on their own idea of lighting conditions, not based
on time, so I can't reliably set appropriate parameters for whether the
IR LEDs are on or not.
(I've thought about having a cron job check the average brightness
of the last few periodic snapshots and try to adjust camera settings
as appropriate, but before I put that much effort in for uncertain
results, I thought I'd see if I could get some advice about getting
the camera or Motion to do it for me.)
Anyway, I guess what I'm asking for is:
* Does anybody have an idea what's going on here, and why the
cameras stopped doing their own automatic exposure adjustment?
* Can somebody explain in detail how auto_brightness is supposed to
work and how it interacts with vid_control_params? (The documentation
is a bit sketchy.)
* Is there a good overview of how various configuration settings
(especially exposure_auto and the settings it interacts with or
conflicts with) work on common USB cameras and how to use them
effectively that I could be pointed at?
I'm running Motion 4.3.2 on Raspbian Buster. While both cameras
are USB 2 devices, I've got one of them in a USB 3 port so they
don't compete on the same bus.
I'm including below the current settings for one of the cameras,
and in case it's of any interest to anybody I'm including the cron
job I'm currently using. I'm using v4l2_palette 8 (V4L2_PIX_FMT_MJPEG
-- took me a while to figure out the default wasn't working) and a
framerate of 9.
Ideas appreciated!
Thanks,
Jay
$ v4l2-ctl -d /dev/video0 -l
brightness 0x00980900 (int) : min=-64 max=64 step=1
default=0 value=0
contrast 0x00980901 (int) : min=0 max=64 step=1
default=32 value=32
saturation 0x00980902 (int) : min=0 max=128 step=1
default=60 value=64
hue 0x00980903 (int) : min=-40 max=40 step=1
default=0 value=0
white_balance_temperature_auto 0x0098090c (bool) : default=1 value=0
gamma 0x00980910 (int) : min=72 max=500 step=1
default=100 value=100
gain 0x00980913 (int) : min=0 max=100 step=1
default=0 value=0
power_line_frequency 0x00980918 (menu) : min=0 max=2 default=1
value=1
white_balance_temperature 0x0098091a (int) : min=2800 max=6500 step=1
default=4600 value=4600
sharpness 0x0098091b (int) : min=0 max=6 step=1
default=2 value=2
backlight_compensation 0x0098091c (int) : min=0 max=2 step=1
default=1 value=1
exposure_auto 0x009a0901 (menu) : min=0 max=3 default=3
value=1
exposure_absolute 0x009a0902 (int) : min=1 max=5000 step=1
default=157 value=20
exposure_auto_priority 0x009a0903 (bool) : default=0 value=0
$ cat /etc/cron.d/motiongain
# at 07:15 each morning:
# gain=0
# exposure_absolute=15
# saturation=64
15 7 * * * root v4l2-ctl -d /dev/video0 -c gain=0
15 7 * * * root v4l2-ctl -d /dev/video0 -c exposure_absolute=15
15 7 * * * root v4l2-ctl -d /dev/video0 -c saturation=64
15 7 * * * root v4l2-ctl -d /dev/video2 -c gain=0
15 7 * * * root v4l2-ctl -d /dev/video2 -c exposure_absolute=15
15 7 * * * root v4l2-ctl -d /dev/video2 -c saturation=64
# at 19:31 each evening (front) or 19:01 (back)
# gain=100
# exposure_absolute=300 (back) or 415 (front; LEDs are further from ground)
# saturation=0
01 19 * * * root v4l2-ctl -d /dev/video0 -c gain=100
01 19 * * * root v4l2-ctl -d /dev/video0 -c exposure_absolute=300
01 19 * * * root v4l2-ctl -d /dev/video0 -c saturation=0
31 19 * * * root v4l2-ctl -d /dev/video2 -c gain=100
31 19 * * * root v4l2-ctl -d /dev/video2 -c exposure_absolute=350
31 19 * * * root v4l2-ctl -d /dev/video2 -c saturation=0
------------------------------
Message: 2
Date: Mon, 31 May 2021 15:39:54 -0500
From: Barry Martin <barry3mar...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Problem with (both camera's and motion's)
auto-brightness adjustment
Message-ID: <e4ddfd25-c8c4-7293-0143-ac6a5829b...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Jay!
I?m not an expert but currently at the tail end (hopefully!) of
correcting a problem I had with my RPi4 (4GB) with two USB cameras
glitching (usually a partial gray overlay) so a sort-of similar issue.
Your ?cheap? SVPro cameras might not be too bad: I?m using an indoor
version and have a note it is similar to ELP, which is supposed to be
decent. Have you tested your cameras are working properly ? adjusting to
brightness ? plugged in to a different computer? Assign the test
computer a different IP and view on your browser. (Test RPi on power
pack, use something like Cheese, view on your phone/tablet.)
As you indicated the problem occurred after a power failure, perhaps the
SD card is a little corrupted; have you tried swapping in your backup
card (and making another backup copy before playing too much)? Why it
would only corrupt the brightness section I have no idea ? years ago I
had a communications software which would corrupt one of its files only
when I did a specific option. Ended up moving it to a different part of
the hard drive and it worked fine. (Renamed the file to hold the place,
reinstalled the one file that was being corrupted.)
My guess is as it worked fine before the power outage and it would seem
a bit odd for both cameras to fail simultaneously, the repeater cables
to both fail simultaneously, then that leaves the Pi or its SD card. The
card seems the most logical candidate. Wall warts can fail over time
(see my thread ?Gray glitching but only one of of two identical
cameras?: Mark?s reply to me on/about May 23^rd. ? I?m thinking with
your numerous power failures maybe the power supply is now iffy. (I run
my most of my Pi?s on UPSs or the HAT UPS.)
The RPi4 gpu_mem doesn?t work the same as previous versions: less is
better. I?m currently using 128 MB, which gives 896 for the CPU
(vcgencmd get_mem gpu, vcgencmd get_mem arm commands, respectively).
Assigning too much memory to graphics will ?starve? the processor.
...Thought of something: a command option in motion.conf will be
overwritten by the same command in your camera configurations.
auto_brightness in the camera?s configuration will be used, but only by
that specific camera. Default is 0 with a range of 0-3.
There?s another one called vid_control_params which is generally left
blank. As we both have SVPro cameras I?m thinking you want (in
motion.conf) *auto_brightness 0* and *vid_control_params* commented out
or better yet deleted. (See
https://motion-project.github.io/motion_config.html#picture_quality
which will get you to the right webpage but wrong section ? use your
browser?s ?find/search? option for ?bright? to get to the sections I
mentioned.)
Good Luck!
Barry
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Mon, 31 May 2021 19:07:08 -0400
From: Jay Sekora <j...@aq.org>
To: Barry Martin <barry3mar...@gmail.com>
Cc: motion-user@lists.sourceforge.net, j...@aq.org
Subject: Re: [Motion-user] Problem with (both camera's and motion's)
auto-brightness adjustment
Message-ID: <16692.1622502...@aq.org>
Content-Type: text/plain; charset="UTF-8"
(There's a lot of detail here but I'm not providing much additional
information, so feel free to skim or skip. :-) )
Barry Martin <barry3mar...@gmail.com> writes:
> Your ?cheap? SVPro cameras might not be too bad: I?m using an indoor
> version and have a note it is similar to ELP, which is supposed to be
> decent.
Yeah, I'm pretty happy with the picture quality!
> Have you tested your cameras are working properly ? adjusting to
> brightness ? plugged in to a different computer? Assign the test
> computer a different IP and view on your browser. (Test RPi on power
> pack, use something like Cheese, view on your phone/tablet.)
I tested them (and Motion, in fact, but also with Cheese and briefly
with Zoom) on my desktop before connecting them to the RPi. (I'm not
using them permanently connected to my desktop because I occasionally
have to move my desk and I don't have an easy way to run cables
outside from there.
> As you indicated the problem occurred after a power failure, perhaps the
> SD card is a little corrupted; have you tried swapping in your backup
> card (and making another backup copy before playing too much)? Why it
> would only corrupt the brightness section I have no idea ? years ago I
> had a communications software which would corrupt one of its files only
> when I did a specific option. Ended up moving it to a different part of
> the hard drive and it worked fine. (Renamed the file to hold the place,
> reinstalled the one file that was being corrupted.)
I'm booted from a 1TB USB thumbdrive, since Motion is saving a *lot* of
video. Hard to imagine filesystem corruption would affect the *camera's*
auto-brightness adjustment, but I'll try fscking the thumbdrive the next
time I have time to take the Pi down and fsck a (currently) ~460GB
fileysystem.
> My guess is as it worked fine before the power outage and it would seem
> a bit odd for both cameras to fail simultaneously, the repeater cables
> to both fail simultaneously, then that leaves the Pi or its SD card. The
> card seems the most logical candidate. Wall warts can fail over time
> (see my thread ?Gray glitching but only one of of two identical
> cameras?: Mark?s reply to me on/about May 23^rd. ? I?m thinking with
> your numerous power failures maybe the power supply is now iffy. (I run
> my most of my Pi?s on UPSs or the HAT UPS.)
There haven't been numerous failures, only the one. (When I said
I'd unplugged things, I meant the USB cables to the cameras, among
other things to try plugging them into my desktop and make sure they
were working properly. I saw the same behavior of automatic exposure
adjustment not working but manual adjustment succeeding on my desktop,
by the way.) So the *cameras* have lost power on a fairly regular basis,
which I mentioned only in case there were settings that weren't preserved
across a power cycle. (They don't have a power switch, so clearly you
just have to unplug them.) I think all their settings are nonvolatile,
though.
I added the USB extension cables since this behavior showed up, so they
don't affect it, and I've also switched power supplies as part of moving
the RPi to a different corner in the basement.
I only *noticed* the problem after that power failure, but I don't know
how long before or after that it happened. I think it's likelier that
a software upgrade (kernel, video or USB libraries, or Motion itself)
or me messing around with camera settings with v4l2-ctl caused the
problem and the power failure was coincidental.
> The RPi4 gpu_mem doesn?t work the same as previous versions: less is
> better. I?m currently using 128 MB, which gives 896 for the CPU
> (vcgencmd get_mem gpu, vcgencmd get_mem arm commands, respectively).
> Assigning too much memory to graphics will ?starve? the processor.
I bumped mine up to 256MB, a comment in /boot/config.txt tells me that
was in response to actual problems with Motion and ffmpeg although I
don't remmber what they were. (I'm not piping to ffmpeg for Motion's
normal output, although I had experimented with that at one point,
but I have some cron jobs that convert the timelapse mpegs to mp4 after
they're complete.)
> ...Thought of something: a command option in motion.conf will be
> overwritten by the same command in your camera configurations.
> auto_brightness in the camera?s configuration will be used, but only by
> that specific camera. Default is 0 with a range of 0-3.
Yup, I currently just have auto_brightness 0 in motion.conf and nothing
in the camera?.conf files.
> There?s another one called vid_control_params which is generally left
> blank. As we both have SVPro cameras I?m thinking you want (in
> motion.conf) *auto_brightness 0* and *vid_control_params* commented out
> or better yet deleted.
That's my current state. (I *had* experimented with vid_control_params
a bit, which is part of why I wonder whether I've accidentally gotten
the cameras in some state I don't know how to get them out of.)
Thanks,
Jay
------------------------------
------------------------------
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 35
********************************************
