| Commit message (Collapse) | Author |
|---|
|
Modify pledge/unveil calls so LWP::UserAgent will work.
|
|
Now that multiple cameras are supported, keep going when one can't be
reached for some reason.
|
|
There's plenty of storage; may as well keep images around longer.
|
|
Since all we care about is whether the video-generating process is
still running, we can remove the SIGCHLD handling that updates the
list of child processes in favor of directly checking them when
decideding whether to generate a video or not.
|
|
* Pass along camera quality kludge flag to Snap.
* Print an error when waitpid finds a child not in the list
* More directly search for today's video
|
|
Make the previous change here more tidy.
|
|
Multiple cameras can now have snapshots taken and videos
generated. The cameras are hardcoded for now. Images and videos go
into a per-camera spool.
|
|
Derp error caused the local module not to be imported when --debug was
specified.
|
|
* debug => [0|1]
Enable/disable debug printing. Not much of this so far.
* image_quality_workaround => [0|1]
Newer Reolink firmware (unknown which versions or when it started)
generate JPEG images with empty or missing quantization
tables. This is probably fine, except a years-old bug in ffmpeg's
mjpeg module causes it to choke when this field is missing, so
timelapse videos can't be created. Setting this flag causes the
image data to get run through Image::Magick, setting a quality of
99, before saving.
|
|
Newer Reolink firmware supports HTTPS and ships with HTTP API access
disabled by default. Switch to LWP::UserAgent for HTTPS support and
redirect to HTTPS if needed.
|
|
All the things that prevented the previous commit from working. The
iDevice can now play video, as can Firefox.
|
|
The state of video in the browser is a hot mess. And not in a good
way.
Google and Mozilla support the fancy VP9 encoding. Apple does
not. Sadly, since the videos have reasonably good quality and small
size.
Apple supports H.265, also a fancy encoding. But neither Google nor
Mozilla support that.
What they all can agree on is H.264. Which isn't bad, but isn't great
either. But since those dorks can't get their act together, then H.264
it is for the rest of us. The "front end" people do stupid tricks like
encode each video in several different formats and let the browser
choose, but come on, really?
|
|
The value is used to set the NTP server for the cameras, so may as
call call it by a name that corresponds.
|
|
The output web page now has slideshow and video tabs. The video tab
lets you select from and play existing videos.
N.b. videos that are still being generated will show up.
|
|
Full size takes forever to generate (which will eat into the power
budget once remote) and is larger than needed for what it is. Switch
to generate the small size only.
|
|
When the spool was different from default, the process child found no
screenshots as it wasn't loading the config file. Fix that. Also add
a `"timelapse"` command to trigger generation (primarily for
debugging), and save off a "keyframe" for each video generated.
|
|
Static page with simple slideshow, generated after each snapshot and
respool.
|
|
|
|
Enable config file creation and exec (for video creation).
|
|
Turns out support for reload was present since the beginning, so
enable the rc "reload" action.
|
|
Default now is to keep images in spool only for 24 hours. This can be
changed via a client command or the config file.
|
|
|
|
|
|
|
|
Prepare for use by Client.
|
|
|
|
|
|
|
|
Add `spool_dir` to `%default_config` and `%debug_config` so as not to
store snapshots in `/`.
|
|
|
|
|
|
|
|
|
