PiKrellCam: motion vector detect + OSD web interface

[billw]

On a couple of cameras that generate a lot of the sparkles during twilight I get
a number of spurious burst detects so I've put up an upgrade that reduces the
burst detect sensitivity as sparkle count goes up. I'll be looking more into it.

[boomlikethat]

Hey all,

Hope everyone had a great holiday, and an even better new year coming.

FYI, I have 2 RPi2's running PiKrellCam. In recent weeks, I've had some HUGE files created (1-2G), and I'm not sure what settings I've changed (or not changed) to make this happen. Any ideas?

Also, having some issues with both RPI's freezing every few days. Takes a few reboots to get it going again. I regularly update the Pi's, and currently running 2.2.1 of the PiKrellCam software.

Thanks!

[jbeale]

Does the log file give any clues? Do you have low motion thresholds, or long timeouts? I got frequent captures when I had an outdoor setup where there was water dripping off a roof right in front of the lens, but apart from that I have not seen huge files here. I have several PiKrellCam systems running 24/7 but they are on versions 2.1.3 and 2.1.1

I occasionally see a system freeze here as well, but it might be due to power glitches because other systems running from a battery-backed UPS do not lock up.

[boomlikethat]

Does the log file give any clues? Do you have low motion thresholds, or long timeouts? I got frequent captures when I had an outdoor setup where there was water dripping off a roof right in front of the lens, but apart from that I have not seen huge files here. I have several PiKrellCam systems running 24/7 but they are on versions 2.1.3 and 2.1.1

I occasionally see a system freeze here as well, but it might be due to power glitches because other systems running from a battery-backed UPS do not lock up.

@jbeale;

thanks for the quick response. Here's the log on one big file:

15:39:45 : Video record: /home/pi/pikrellcam/media/videos/2015-12-28_15.39.45_12.mp4.h264 ...
15:39:45 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/2015-12-28_15.39.45_12.jpg
15:40:01 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/2015-12-28_15.39.45_12.jpg
15:40:17 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/2015-12-28_15.39.45_12.jpg
15:40:17 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/2015-12-28_15.39.45_12.jpg
15:40:17 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/2015-12-28_15.39.45_12.jpg
15:45:26 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/2015-12-28_15.39.45_12.jpg
16:10:16 : event preview save: copy /run/pikrellcam/mjpeg.jpg -> /run/pikrellcam/2015-12-28_15.39.45_12.jpg
16:28:28 : Video motion record stopped. Header size: 29 h264 file size: -2118109383
16:28:28 : first detect: direction totals - direction: 664 burst: 33 max burst count: 784
16:28:28 : execl:[(MP4Box -quiet -tmp /tmp -fps 24 -add /home/pi/pikrellcam/media/videos/2015-12-28_15.39.45_12.mp4.h264 /home/pi/pikrellcam/media/videos/2015-12-28_15.39.45_12.mp4 2> /dev/null && rm /home/pi/pikrellcam/media/videos/2015-12-28_15.39.45_12.mp4.h264)]
16:28:28 : execl:[/home/pi/pikrellcam/scripts-dist/_thumb /run/pikrellcam/2015-12-28_15.39.45_12.jpg /home/pi/pikrellcam/media /home/pi/pikrellcam/www/FIFO /tmp/pikrellcam.log 288 198 495 198]
convert /run/pikrellcam/2015-12-28_15.39.45_12.jpg -crop 288x288+351+54 -resize 150x150\! /home/pi/pikrellcam/media/thumbs/2015-12-28_15.39.45_12.th.jpg
16:28:28 : execl:[/home/pi/pikrellcam/scripts/preview-save /run/pikrellcam/2015-12-28_15.39.45_12.jpg /home/pi/pikrellcam/media /home/pi/pikrellcam/www/FIFO /tmp/pikrellcam.log 288 198 495 198]
cp /run/pikrellcam/2015-12-28_15.39.45_12.jpg /home/pi/pikrellcam/media/stills
convert /run/pikrellcam/2015-12-28_15.39.45_12.jpg -crop 288x288+351+54 -resize 150x150\! /home/pi/pikrellcam/media/thumbs/2015-12-28_15.39.45_12.th.jpg
16:28:28 : event_preview_dispose(); removing /run/pikrellcam/2015-12-28_15.39.45_12.jpg

My thresholds are:
Vector Magnitude: 5
Vector Count: 5
Burst Count: 200
Burst Frames: 3

My times are:
Confirm Gap: 3
Pre Capture: 3
Event Gap: 30
Post Capture: 5

Don't want to miss anything (there have been some shady things and robberies in recent months around here), so I find this setup is really good, especially for the price.

During windy days (or rain, like you were saying), I see a uptick in recordings too.

As for the power glitches, are we talking about the main outlets, or the power supply that goes to the Pi? I did make sure I had good quality power supplies, and even have them hard-wired to the network for faster file transfer. If it's the outlet, what can I test on my end?

Thanks!

[billw]

Does the log file give any clues? Do you have low motion thresholds, or long timeouts? I got frequent captures when I had an outdoor setup where there was water dripping off a roof right in front of the lens, but apart from that I have not seen huge files here. I have several PiKrellCam systems running 24/7 but they are on versions 2.1.3 and 2.1.1

I occasionally see a system freeze here as well, but it might be due to power glitches because other systems running from a battery-backed UPS do not lock up.

@jbeale;

thanks for the quick response. Here's the log on one big file:

15:39:45 : Video record: /home/pi/pikrellcam/media/videos/2015-12-28_15.39.45_12.mp4.h264 ...
...
16:28:28 : Video motion record stopped. Header size: 29 h264 file size: -2118109383
16:28:28 : first detect: direction totals - direction: 664 burst: 33 max burst count: 784
...
My thresholds are:
Vector Magnitude: 5
Vector Count: 5
Burst Count: 200
Burst Frames: 3

My times are:
Confirm Gap: 3
Pre Capture: 3
Event Gap: 30
Post Capture: 5

Don't want to miss anything (there have been some shady things and robberies in recent months around here), so I find this setup is really good, especially for the price.

During windy days (or rain, like you were saying), I see a uptick in recordings too.

As for the power glitches, are we talking about the main outlets, or the power supply that goes to the Pi? I did make sure I had good quality power supplies, and even have them hard-wired to the network for faster file transfer. If it's the outlet, what can I test on my end?

Thanks!

If you have trouble rebooting after the freeze it could be other things also. I would
measure the voltage on the Pi board, maybe there's power wire resistance dropping some
voltage. Are you overclocking? If so, drop the frequency back down a bit. When you
have reboot failures how far does it get and are there error messages on the screen (if
you aren't headless).

The log from that long video averaged over 13 direction detects per minute for
40 minutes. If you have other videos around that one, what was being detected?
I like to run with low settings but on windy days sometimes I have to adjust the settings
higher. Or sometimes I get some weeds that have grown higher and I have to go trim
them to get back to good detection. Also as the seasons change different sun
angles cause different wind blown tree shadow problems on my driveway.
With low settings sometimes things have to be managed, maybe it could be a temporary
change in your motion regions or a change of settings. You could have a script
run by hand whenever needed that changes all the settings at once to lower
sensitivity and another script to restore them.

[boomlikethat]

If you have trouble rebooting after the freeze it could be other things also. I would
measure the voltage on the Pi board, maybe there's power wire resistance dropping some
voltage. Are you overclocking? If so, drop the frequency back down a bit. When you
have reboot failures how far does it get and are there error messages on the screen (if
you aren't headless).

The log from that long video averaged over 13 direction detects per minute for
40 minutes. If you have other videos around that one, what was being detected?
I like to run with low settings but on windy days sometimes I have to adjust the settings
higher. Or sometimes I get some weeds that have grown higher and I have to go trim
them to get back to good detection. Also as the seasons change different sun
angles cause different wind blown tree shadow problems on my driveway.
With low settings sometimes things have to be managed, maybe it could be a temporary
change in your motion regions or a change of settings. You could have a script
run by hand whenever needed that changes all the settings at once to lower
sensitivity and another script to restore them.

@billw:
Thanks for the response. I just checked, I was not overclocking, but reset it, just to be sure.

Usually what's being detected are cars going by, nothing unusual.

Yeah, I need to trim some roses out front...but that would only affect one of the two RPi's deployed. The other one has no obstructions, so I get far fewer huge files on that one. On occasion it might happen, but nothing I can point to.

As for the power supply, I need to check that, maybe even some kind of voltage regulator inline to help.

I do like the script idea. I can do Applescripting on my Mac, how do I do this for the RPi and PiKrellCam?

Thanks!

[billw]

Usually what's being detected are cars going by, nothing unusual.

Yeah, I need to trim some roses out front...but that would only affect one of the two RPi's deployed. The other one has no obstructions, so I get far fewer huge files on that one. On occasion it might happen, but nothing I can point to.

As for the power supply, I need to check that, maybe even some kind of voltage regulator inline to help.

I do like the script idea. I can do Applescripting on my Mac, how do I do this for the RPi and PiKrellCam?

Thanks!

Just keep an eye on the thumbs you get for each video. If you get a lot of what you
consider something in the background then probably the vector limit settings you have
are too low for the camera environment (or maybe the motion regions could be adjusted
better). But if the thumbs are what you want (cars, people) then I would adjust the
event gap lower so the videos will be more likely to be shorter and about individual
events. The other option will be something I still need to do and that is put in a way
to limit the video length.

For scripts, you need a bash script that writes pikrellcam settings to the FIFO and you
run it when needed. For example a script when it rains or winds are high could be:

Code: Select all

#!/bin/bash

echo motion limits 12 12 > ~/pikrellcam/www/FIFO
echo motion burst 500 4 > ~/pikrellcam/www/FIFO

#If you want to configure a custom motions regions also:
#echo motion load_regions windy > ~/pikrellcam/www/FIFO

And when the weather gets back to normal, run something like this:

Code: Select all

#!/bin/bash

echo motion limits 5 4 > ~/pikrellcam/www/FIFO
echo motion burst 200 3 > ~/pikrellcam/www/FIFO
#echo motion load_regions default > ~/pikrellcam/www/FIFO

Make the scripts executable and run them from a terminal.

I expect that eventually pikrellcam will have a preset system where
a bunch of settings can be saved and restored with a web page
button click, but that's for later.

[tomtgrp]

Hello,

I am on writing a setup.php and noticed this:

echo "video_bitrate 17000000" > FIFO
gives an error, here the part from the logfile:

18:30:46 : command_process: video_bitrate 17000000
18:30:46 : Bad command: [video_bitrate] [17000000]

should atoi instead of atol be the reason in config.c:516?

BR
Tom

[billw]

Hello,

I am on writing a setup.php and noticed this:

echo "video_bitrate 17000000" > FIFO
gives an error, here the part from the logfile:

18:30:46 : command_process: video_bitrate 17000000
18:30:46 : Bad command: [video_bitrate] [17000000]

should atoi instead of atol be the reason in config.c:516?

BR
Tom

Uh, no. It's an oversight on my part. Back when I was adding the commands
I was undecided on having a multi arg command vs separate fps, bitrate, quality
commands since all of them required a camera restart. Then later I put in the
video_fps but neglected the others.

But I just pushed an upgrade that adds in video_bitrate, so it's there now.
Also in this upgrade:

Add docs to help page for mjpeg tcp socket streaming from Brijesh Singh
which was merged a few days ago and I did not mention it here because I
didn't have it documented yet. But it's there now.

Updated architecture.jpg and link to forum for setting up h264 streaming.

Burst density testing now a function of any_count_expma
and burst pass testing uses any_count_expma instead of sparkle_expma.

Best motion cvec testing done on frame cvec instead of region cvecs.

Improved presentation of -vm debug output.

[boomlikethat]

Usually what's being detected are cars going by, nothing unusual.

Yeah, I need to trim some roses out front...but that would only affect one of the two RPi's deployed. The other one has no obstructions, so I get far fewer huge files on that one. On occasion it might happen, but nothing I can point to.

As for the power supply, I need to check that, maybe even some kind of voltage regulator inline to help.

I do like the script idea. I can do Applescripting on my Mac, how do I do this for the RPi and PiKrellCam?

Thanks!

Just keep an eye on the thumbs you get for each video. If you get a lot of what you
consider something in the background then probably the vector limit settings you have
are too low for the camera environment (or maybe the motion regions could be adjusted
better). But if the thumbs are what you want (cars, people) then I would adjust the
event gap lower so the videos will be more likely to be shorter and about individual
events. The other option will be something I still need to do and that is put in a way
to limit the video length.

For scripts, you need a bash script that writes pikrellcam settings to the FIFO and you
run it when needed. For example a script when it rains or winds are high could be:

Code: Select all

#!/bin/bash

echo motion limits 12 12 > ~/pikrellcam/www/FIFO
echo motion burst 500 4 > ~/pikrellcam/www/FIFO

#If you want to configure a custom motions regions also:
#echo motion load_regions windy > ~/pikrellcam/www/FIFO

And when the weather gets back to normal, run something like this:

Code: Select all

#!/bin/bash

echo motion limits 5 4 > ~/pikrellcam/www/FIFO
echo motion burst 200 3 > ~/pikrellcam/www/FIFO
#echo motion load_regions default > ~/pikrellcam/www/FIFO

Make the scripts executable and run them from a terminal.

I expect that eventually pikrellcam will have a preset system where
a bunch of settings can be saved and restored with a web page
button click, but that's for later.

@billw:

That's very helpful. Thanks to you and jbeale for your help!

[jbeale]

@billw : thanks for the continual improvements to PiKrellCam! It's great the project is so active.

There's one feature I've been thinking about, maybe it is already possible but I'm not sure. Say I wanted to record video based on an external trigger (let's say, an IR motion detector) instead of from video motion vectors. Is it possible? I understand I can use the FIFO 'record on' command, but does that include the several seconds of pre-event buffer also? Is the pre-event buffer process running all the time, or only when motion sensing is enabled? Ideally I'd want to record, for example, three seconds before a trigger and 3 seconds after it. So maybe it would be a FIFO command 'motion trigger' ?

[billw]

@billw : thanks for the continual improvements to PiKrellCam! It's great the project is so active.

There's one feature I've been thinking about, maybe it is already possible but I'm not sure. Say I wanted to record video based on an external trigger (let's say, an IR motion detector) instead of from video motion vectors. Is it possible? I understand I can use the FIFO 'record on' command, but does that include the several seconds of pre-event buffer also? Is the pre-event buffer process running all the time, or only when motion sensing is enabled? Ideally I'd want to record, for example, three seconds before a trigger and 3 seconds after it. So maybe it would be a FIFO command 'motion trigger' ?

It is something I've had on my list todo for a PIR or laser interrupted switch or whatever.
The circular buffer is always running set up for the configured pre capture, so that would
be easy to do even with separate enables for motion type (motion vector vs FIFO trigger).

But if you wanted a pre capture time specific to a FIFO "motion trigger"
(or a general GPIO trigger built in interface I've been thinking about) different from what's
configured for a motion vector detect, then it might be involved. Same deal
with event gap and post capture. That would be easy if using the same already configured
captures and gap values.

[jbeale]

Thanks, glad it's on the list! I do not need a specific or separate pre-event buffer time. I was thinking just a few seconds, the same as what I get with the normal motion trigger. I actually have tried using PiKrellCam this way with a process monitoring a sensor to generate the FIFO command for taking a still image. That works, but there is a bit of lag, so with faster moving things you may not get the best image. Without motion vectors there wouldn't necessarily be a defined "motion region" for the thumbnail, so I guess that would default to the full frame area. But it might be nice to specify the particular thumbnail frame as a certain time offset or maybe frame count offset from the trigger moment.

[billw]

There's one feature I've been thinking about, maybe it is already possible but I'm not sure. Say I wanted to record video based on an external trigger

There's a new upgrade. On the help page, see the record examples under "FIFO Commands"
and the new Time_Limit config option under Setup Panel->Times->Time_Limit

Basically, you can have an external motion trigger from a script. It uses all the motion configured
times.

Code: Select all

echo motion trigger > ~/pikrellcam/www/FIFO

and you can control through the FIFO one shot manual records with a variable pre
capture time and record length time independent of the motion times.
To record a 14 second video with 4 seconds of pre capture (but see the help page for limitations):

Code: Select all

echo  record on 4 10 > ~/pikrellcam/www/FIFO

[jbeale]

The new feature is great! I have a python program which monitors a sensor and then calls a shell script which does:

Code: Select all

#!/bin/bash
echo "still" > /home/pi/pikrellcam/www/FIFO
echo "record on 4 4" > /home/pi/pikrellcam/www/FIFO

so I get a still image as well as a video showing before and after the trigger. There is about a half-second gap in the video right at the trigger, as the camera changes modes for the full-res still frame, but I think that's a limitation of the GPU firmware and nothing to do with PiKrellCam.

[jbeale]

Observation: if I use the "motion trigger" command into the FIFO, with the below config settings, the resulting video shows 4 seconds pre-event as expected but only one single frame post-event. Maybe there is something else wrong with my settings?

Code: Select all

motion_pre_capture 4
motion_post_capture 4

The "record on 4 4" command works as expected, giving a video of 8 seconds total, but apparently does not trigger the motion-end and preview-save script actions(?)

my complete pikrellcam.conf file is below. I set the motion thresholds very high so I would only get sensor-triggered events, not motion-vector triggers.

Code: Select all

# ==================================================================
#               pikrellcam Program Configuration
#
# When editing this file, stop and then restart pikrellcam so your changes
# will be in effect.  Otherwise, pikrellcam may overwrite this file and your
# changes will be lost.
# Commands in this file should not be enclosed in quotes and commands may
# have substitution variables.
# See ~/.pikrellcam/at_commands.conf for a list of the substitution variables.
# The web interface can modify many settings here but caonnot modify any
# commands or filename templates.  If a setting is modified from the web
# interface, this file will be written.
#
# ----------------------------------------------------------
#
# The PiKrellCam installation directory.
# This must match where PiKrellCam is installed and it is checked by
# the install-pikrellcam.sh script.  This should not need to be edited.
#
install_dir /home/pi/pikrellcam

# Directory for the stream mjpeg file and info file. These files
# are frequently updated so this directory should be in a tmpfs.
# This could be a directory in /tmp if your /tmp is a tmpfs.
# Avoid putting this directory under /run/shm or /dev/shm because these
# directories are subject to automatic cleanups which could delete the
# tmpfs_dir out from under a running pikrellcam if running headless.
#
tmpfs_dir /run/pikrellcam

# If media_dir has no leading '/' it will be a sub directory in install_dir.
# Otherwise it is a full pathname to the media directory.
# So the default media dir is /home/pi/pikrellcam/media.
# An alternate choice could be /home/pi/media if you set the full path.
# Even /tmp/media with /tmp a tmpfs can be an option for a setup that
# will manage by hand or script the limited space available.
# A file system may be mounted on the media dir in the startup script.
#
media_dir media

# If archive_dir has no leading '/' it will be a sub directory under media_dir.
# Otherwise it is a full pathname to the archive directory.
# So the default archive dir is /home/pi/pikrellcam/media/archive.
# When media files are archived, they will be moved to sub directories:
#     archive_dir/year/month/day/[videos|thumbs|stills]
# A file system may be mounted on the archive dir in the startup script.
#
archive_dir archive

# Log file.
#
log_file /tmp/pikrellcam.log

# At startup and at each new day, trim the log file number of lines
# to log_lines.  If log_lines is 0 the log file is not trimmed.
#
log_lines 1000

# Command to run at PiKrellCam startup.  This is run after the config
# files are loaded but before the camera is started or directories
# are checked.  If you want a start command that runs after the camera
# is started, add a command to the file: ~/.pikrellcam/at-commands.conf.
# The default on_startup script can mount a drive on the media directory.
# Edit MOUNT_DISK in the startup script in $C (the scripts directory) to
# enable mounting.
#
on_startup $C/startup $I $m $G


# -------------------- Motion Detect Options -----------------------
#
# Enable pikrellcam motion detection at startup
#
motion_enable on

# Motion vectors must be at least this magnitude for a motion detect.
# Minimum is 3 for detecting the slowest moving objects possible.
#
motion_magnitude_limit 500

# The count of vectors required for a motion detect.
# Minimum is 2 for detecting the smallest objects possible.
#
motion_magnitude_limit_count 400

# Motion vector count minimum for a burst motion detect.
# For large/close object detection.
#
motion_burst_count 4000

# The number of sustained frames for a burst motion detect.
#
motion_burst_frames 30

# Time length limit of motion video record excluding pre_capture time.
# If zero, there is no time limit or else the minimum is 10 seconds.
#
motion_record_time_limit 10

# Percent to dim image when drawing motion vectors.  Range 30 - 60
#
motion_vectors_dimming 45

# Require a second motion detect within this period of seconds before
# triggering a real motion detect event.  Set to zero to not require a
# second confirming motion detect.
#
motion_confirm_gap 0

# event_gap seconds since the last motion detect event must pass
# before a motion video record can end.  Each motion detect within
# an event_gap resets a new full event_gap period.  When an event gap period
# does expire without a new motion event occurring, the video will end with
# an end time of the last motion detect time plus the post_capture time.
#
motion_event_gap 0

# Seconds of video that will be recorded in a motion video before the
# time of the first motion event.
#
motion_pre_capture 4

# Seconds of video that will be recorded after the last motion event.
#
motion_post_capture 4

# Command/script to run when a motion detect event begins.
#
on_motion_begin $C/motion-begin $v $P $G

# Command/script to run when a motion detect event ends.
# The motion_end script uses scp to immediately archive motion detect
# videos to a different computer.
# To enable this, add your machine information to the motion-end script
# and make this the on_motion_end command:
#   on_motion_end $C/motion-end $v $P $G
#
#on_motion_end 
on_motion_end $C/motion-end $v $P $G

# When to save the motion preview file.
#     first  - when motion is first detected.
#              The on_motion_preview_save command runs immediately.
#     best   - best motion based on vector count and position.
#              The on_motion_preview_save command runs at motion end.
#
motion_preview_save_mode first

# Command to run on the motion preview jpeg file.
# Specify the preview jpeg file name with $F.
# A jpeg thumb of the motion area is automatically extracted from the
# preview jpeg and saved to the thumbs directory.  However, if you
# want to do something else with the motion area, the motion detect
# area in the jpeg can be passed to this command with these substitution
# variables
#     $i  width of the area
#     $J  height of the area
#     $K  x coordinate of the area center
#     $Y  y coordinate of the area center
# Example command to email the motion detect preview jpeg:
#     on_motion_preview_save mpack -s [email protected]$H $F [email protected]
# Or, example command to run the default preview-save script which you
# can edit to enable emailing or copying the jpeg.
#     on_motion_preview_save $C/preview-save  $F $m $P $G
#
#on_motion_preview_save 
on_motion_preview_save $C/preview-save  $F $m $P $G $i $J $K $Y

# Set to off if you want jpeg preview files to show the OSD overlay text
# or graphics.  This can be considered a debug or instructional option.
# Normally it is nicer to have clean preview jpegs and thumbs.
#
motion_preview_clean on

# Minimum width and height in pixels for the substitution width and height
# variables for motion detect areas in the preview jpeg.
# This minimum helps with possible frame skew for smaller relatively
# faster moving objects.
#
motion_area_min_side 60

# Enable writing a motion statistics .csv file for each motion video.
# For users who have a need for advanced video post processing.
#
motion_stats off


# --------------------- Video Record Options -----------------------
#
# Motion and manual record video filename format.
# NOTE: PHP code on the web page tries to extract a video time from
#     the video name so there is restricted flexibility for changing
#     this format.  In particular, the PHP code expects at least:
#       xxx_xxx_%H.%M.%S_xxx.mp4
#     where the '_' chars are required and '.mp4' may be '.h264'
# You can use strftime() % time specifiers.
#     Note: only a recent gpac release can handle ':' in the filename.
#     So, the time format may not be able to use %T specifier.
#         %F is %Y-%m-%d   %T is %H:%M:%S
# A video_filename may use these pikrellcam substitution vvariables:
#     $M - The video_manual_tag or video_motion_tag string
#     $N - The video_manual_sequence  or video_motion_sequence number
# If the name has a .mp4 suffix, the video file will be boxed into a
# mp4 container using the MP4Box program.  Otherwise you should give the
# name a .h264 suffix since that is the format of the Pi camera video
# output.  Note that omxplayer can play a raw h264 video, but that other
# programs like vlc and mplayer will need a mp4 video.
#
video_filename $M_%F_%H.%M.%S_$N.mp4

# The string to substitute into a video_filename for the $M variable
# when there is a manually initiated video record.
#
video_manual_tag manual

# The string to substitute into a video_filename for the $M variable
# when there is a motion detect initiated video record.
#
video_motion_tag motion

# Pixel width of videos recorded.
#
video_width 1920

# Pixel height of videos recorded.
#
video_height 1080

# Video frames per second.  The processing required to implement the
# multiple video paths in PiKrellCam limits this fps to about 24.
# Above that may cause web page mjpeg frames to be dropped.  But if
# you are overclocking the GPU you may be able to set higher.
#
video_fps 24

# MP4Box output frames per second if video filename is a .mp4
# If this is different from video_fps, the final mp4 will be a
# slow or fast motion video.
#
video_mp4box_fps 24

# Video bitrate affects the quality and size of a video recording.
# Along with pre_capture and event_gap times, it also determines the
# PiKrellCam video circular buffer memory usage.
# Set the bitrate lower or higher as you wish to trade off video size
# and memory usage with video quality.  The Pi camera lens and sensor
# pixel size combination also can be a limiting factor on video quality
# and may limit the benefit of the highest bitrate settings.
#
video_bitrate 6000000

# Pixel width of the stream jpeg file. Aspect ratio is determined by the video.
#
mjpeg_width 640

# Quality factor (up to 100) affects the quality and size of the stream jpeg.
# Set this lower if you need to reduce the stream bandwidth.
#
mjpeg_quality 20

# Divide the video_fps by this to get the stream jpeg file update rate.
# This will also be the motion frame check rate for motion detection.
# For example if video_fps is 24 and this divider is 4, the stream jpeg file
# is updated and motion is checked 6 times/sec.
#
mjpeg_divider 4


# ------------------ Still Capture Options -----------------------
#
# Still filename format.  See comments about strftime() above.
# NOTE: PHP code on the web page tries to extract a still time from
#     the still name so there is restricted flexibility for changing
#     this format.  In particular, the PHP code expects at least:
#       xxx_xxx_%H.%M.%S_xxx.jpg
#     where the '_' chars are required.
# A still_filename may use this pikrellcam substitution variable:
#     $N - The still capture sequence number
#
still_filename Simage_%F_%H.%M.%S_$N.jpg

# Width of a still capture in pixels.  Max value 2592
#
still_width 1944

# Height of a still capture in pixels.  Max value 1944
#
still_height 2592

# This quality factor affects the size and quality of still captures.
#
still_quality 95

# Command to run after a still capture.
# email the still somewhere with:
#   on_still_capture mpack -s [email protected]$H $s [email protected]
# Or do an email and/or something like copy or move the still somewhere
# with a script you write ($s is the still file pathname):
#   on_still_capture $C/still-capture $s $P $G
#
#on_still_capture 

# Timelapse video name format.  See comments about strftime() above.
# A timelapse_video_name may use this pikrellcam substitution variable:
#     $n - The timelapse capture series number (printed as %05d)
# This video name is used in $T in the on_timelapse_end command.
#
timelapse_video_name tl_%F_%H.%M_$n.mp4

# Command to run when a time lapse series is ended.
# The default on_timelapse_end command converts captures in the
# media_dir/timelapse directory to a video which is saved in
# the media_dir/videos directory.
# See the timelapse-end script in the scripts directory.
# NOTE: $l embeds a '%' qualifier in the command string so it
# can only be used as the last $X variable.
#
on_timelapse_end $C/timelapse-end $L $T $n $G $P $l


# ------------------- Miscellaneous Options  -----------------------
#
# How long in seconds a notify string should stay on the stream jpeg file.
#
notify_duration 4

# Your latitude used to calculate sun rise, set, dawn, and dusk times.
#
latitude 30.12N

# Your longitude used to calculate sun rise, set, dawn, and dusk times.
#
longitude 97.88W

# Do not edit.  Used internally to force startup config write if needed.
#
config_sequence 13


# ------------------- Annotate Text Options  -----------------------
#
# Format for a date string that can be superimposed on videos and stills.
#
annotate_format_string %a %b %e, %l:%M.%S %p

# Enables drawing the annotate date string.
#
annotate_enable on

# Extra information drawn on the video.
#
annotate_show_motion off

# Extra information drawn on the video.
#
annotate_show_frame off

# Draw text characters with black background.
#
annotate_black_bg on

# ==================================================================
#               Raspberry Pi Initial Camera Parameters
#
sharpness 0
contrast 0
brightness 50
saturation 0
iso 0
shutter_speed 0
exposure_compensation -7
video_stabilisation false
raw_capture false
rotation 270
exposure_mode sports
image_effect none
hflip off
vflip off
crop 0 0 65536 65536
metering_mode average
white_balance auto
color_effect false 128 128

[billw]

The "record on 4 4" command works as expected, giving a video of 8 seconds total, but apparently does not trigger the motion-end and preview-save script actions(?)

I thought I might get another version out tonight, but now maybe not.
So, tomorrow, I'll put up a new version with:
1) record on precapture timelimit won't change since it is a record function.
2) I'll enhance the "motion trigger" command so it will take a pre capture and
time limit arg and it will run the modition end/ preview save.
Additionally it will have a motion enable override so if motion is disabled from the
web page, you can override turn it on just for the current FIFO motion trigger.
Example:

Code: Select all

echo motion trigger 1 4 4 > FIFO

will override the web enable, but this will not

Code: Select all

echo motion trigger 0 4 4 > FIFO

[jbeale]

Great! I will look forward to the new version; thanks again! -john

[guestye]

Avdshare Video Converter is proved as the best MP4 trimmer for both Windows and Mac platform.

[billw]

Observation: if I use the "motion trigger" command into the FIFO, with the below config settings, the resulting video shows 4 seconds pre-event as expected but only one single frame post-event.

post caputure must be >= event gap time because expiring event gap forces a video stop.
There can only be a post capture that has been accumulated while waiting in the event
gap. But this now does not apply if you use the new motion trigger + custom times because
custom times will override the event gap.

I thought I might get another version out tonight, but now maybe not.
So, tomorrow, I'll put up a new version with:
1) record on precapture timelimit won't change since it is a record function.
2) I'll enhance the "motion trigger" command so it will take a pre capture and
time limit arg and it will run the modition end/ preview save.
Additionally it will have a motion enable override so if motion is disabled from the
web page, you can override turn it on just for the current FIFO motion trigger.
Example:

Code: Select all

echo motion trigger 1 4 4 > FIFO

will override the web enable, but this will not

Code: Select all

echo motion trigger 0 4 4 > FIFO

Ok, there's an upgrade you can try. The help page is updated to describe
the improved motion trigger FIFO command.

[jbeale]

post capture must be >= event gap time because expiring event gap forces a video stop.
There can only be a post capture that has been accumulated while waiting in the event
gap. But this now does not apply if you use the new motion trigger + custom times because
custom times will override the event gap.

Thanks! Yes indeed the previous version works as I had hoped when I increase the motion_event_gap to be longer than the motion_post_capture time. I just hadn't realized that requirement until now.
I can also confirm that the new command

Code: Select all

echo "motion trigger 1 4 4 " > /home/pi/pikrellcam/www/FIFO

works perfectly as well, saving 4 seconds of video pre-trigger and 4 seconds post-trigger even with the normal motion detection off.

All in all, an excellent finish to 2015! -cheers, John

[boomlikethat]

First off, thanks for all your help in recent weeks. I was having issues on large files, and cutting down the event_gap helps a lot. Still get big files on windy days, but that's to be expected. I'll be looking at the recent upgrade you made today.

Been thinking about this for a bit, and that's a request to have a "select all" button for the thumbs area. The reason I ask is this. Because I live on a busy street, I get a lot of hits each day (cars, etc). That's to be expected on my end.

However, after manually scanning the videos, archiving the ones I need for further review, I would use the "delete all". What I was not aware of is that I think it also deletes any recordings that are still in process. In the previous app I used, I could select all, and then de-select ones I wanted to further review.

I think with a "select all" button, it would only select those completed in the thumbs area.

Please correct me if I'm wrong on this, or whatever. Thanks!

[billw]

Been thinking about this for a bit, and that's a request to have a "select all" button for the thumbs area. The reason I ask is this. Because I live on a busy street, I get a lot of hits each day (cars, etc). That's to be expected on my end.

However, after manually scanning the videos, archiving the ones I need for further review, I would use the "delete all". What I was not aware of is that I think it also deletes any recordings that are still in process. In the previous app I used, I could select all, and then de-select ones I wanted to further review.

I think with a "select all" button, it would only select those completed in the thumbs area.

Please correct me if I'm wrong on this, or whatever. Thanks!

Upgrade available - thumbs page can select by days or all.

Delete Day can delete a recording in progress and that is a problem. And deleting by selection
will only delete videos you can see on the thumbs page, so as you are saying, that seems to
me a better way to do it.

So I've removed the "Delete Day" and "Archive Day" buttons from the thumbs page and now
all deleting/archiving is done by selections. The delete day from the videos page can still
be a problem and I'll be looking at that.

One thing I'm wondering, is anybody using the videos page preferentially over the thumbs page?
For my part, I find since I added selections to the thumbs page I rarely manage videos from
the videos page anymore, and once I get to adding thumbs for manual and timelapse
recordings, I expect I'll never be using the videos page. So if nobody speaks up I may end up
getting rid of the videos page.

[boomlikethat]

Been thinking about this for a bit, and that's a request to have a "select all" button for the thumbs area. The reason I ask is this. Because I live on a busy street, I get a lot of hits each day (cars, etc). That's to be expected on my end.

However, after manually scanning the videos, archiving the ones I need for further review, I would use the "delete all". What I was not aware of is that I think it also deletes any recordings that are still in process. In the previous app I used, I could select all, and then de-select ones I wanted to further review.

I think with a "select all" button, it would only select those completed in the thumbs area.

Please correct me if I'm wrong on this, or whatever. Thanks!

Upgrade available - thumbs page can select by days or all.

Delete Day can delete a recording in progress and that is a problem. And deleting by selection
will only delete videos you can see on the thumbs page, so as you are saying, that seems to
me a better way to do it.

So I've removed the "Delete Day" and "Archive Day" buttons from the thumbs page and now
all deleting/archiving is done by selections. The delete day from the videos page can still
be a problem and I'll be looking at that.

One thing I'm wondering, is anybody using the videos page preferentially over the thumbs page?
For my part, I find since I added selections to the thumbs page I rarely manage videos from
the videos page anymore, and once I get to adding thumbs for manual and timelapse
recordings, I expect I'll never be using the videos page. So if nobody speaks up I may end up
getting rid of the videos page.

Wow, thanks for doing that! I'll be testing it, but it's exactly what I was looking for.

As for the videos page, I only use the thumbs page for my reviews, and just click it to review the actual recorded video.

[billw]

Upgrade ready:

Manual and timelapse videos now generate thumbnails so they can be
managed from the thumbs page.
timelapse video names now embed the period instead of the sequence number
so the period can be displayed on the thumbs view. Existing timelapse
names don't have the period and will show "---"

If you have existing manual/timelapse videos, a fix_thumbs can fill in
thumbs for those. First do a test run and you can see what will be done
by looking at the log.

Code: Select all

echo fix_thumbs test > ~/pikrellcam/www/FIFO

If any are found and it looks OK, do the thumb generation with:

Code: Select all

echo fix_thumbs fix > ~/pikrellcam/www/FIFO

This can take a while to complete even on a Pi 2, so reload the log
page until you see "Done".

It's possible the fix_thumbs will find missing thumbs for existing
videos because a few weeks ago I briefly had a version out that
had a bug where deleting a video from the thumbs page would delete the
thumb and not the video. For these, a thumb will be recovered which will
have "Recovered" annotated on it and it won't be a motion area.
it's probably a video you will have to delete again.

pikrellcam.conf now has a more definitive description of
motion/manual/timelapse file name format restrictions. A
new feature is you can now embed the hostname in the file names.

The script timelapse-end is now obsolete and is not executed.
There's a new _timelapse-convert in scripts-dist that is run by default
and it generates the timelapse thumbs. But if you have a customized
timelapse-end script, to continue using it edit pikrellcam.conf and set
timelapse_convert in pikrellcam.conf to use it. Otherwise, you can delete
~/pikrellcam/scripts/timelapse-end.