feat: Add Support for Saving Motion Snapshots and Video Locally (rework #681)

[jsn-0]

This copies the current video buffer to a local directory when motion is detected. It copies both the current video buffer file and the following to ensure the motion is captured. Sadly openRTSP (what produces the video buffer files from the RTSP stream) doesn't produce mp4s that browsers will read. So currently, while the ability to view the videos in-browser is wired up, one must still click the download button to open the video files in something like vlc or mpv.

We could either patch openRTSP to produce valid mp4 files that modern browsers will play or post process with something like MP4Box which I believe is only around 500KB.

Currently the gallery page only links to the first of the two videos that was captured for an event. If we post processed with MP4Box, we could combine the two into one to address it.

I'm currently running this on one of my cameras (a d1) and it's working great so far.

[themactep]

let's rename is to save2mount because we are not going to save it into the flash chip. both sd card and network share are mounts on the camera. i think timelapse plugin already implements mount checking for saving images, borrow it from there.

sidenote. please do not use extensive comments and especially decoration in scripts. these will be packed into the firmware and we are very tight on space, so any explanation goes to the wiki, only code stays in the script.

tabulation for indents for the very same reason.

[jsn-0]

let's rename is to save2mount because we are not going to save it into the flash chip. both sd card and network share are mounts on the camera. i think timelapse plugin already implements mount checking for saving images, borrow it from there.

Will do.

sidenote. please do not use extensive comments and especially decoration in scripts. these will be packed into the firmware and we are very tight on space, so any explanation goes to the wiki, only code stays in the script.
tabulation for indents for the very same reason.

Ah, of course, thanks.

Given space constraints and the fact that openRTSP produces mp4 files that can't be played directly by chrome or firefox, I'm going to refactor the gallery page to simply download the mp4 files rather then attempt to play them directly. I will take a quick look at the openRTSP code base and see what sort of effort it would take to address the issue with invalid mp4 files.

[rothn]

Tested, works for me other than a few unrelated build errors.

[jsn-0]

Refactor is complete. Still need to rename local -> mount and add mount check.

[ashimokawa]

@jsn-0
Works but it seems that we still have to set ftp_sendvideo="true", else it seems, the video buffer wont exist in /tmp/

[jsn-0]

@jsn-0 Works but it seems that we still have to set ftp_sendvideo="true", else it seems, the video buffer wont exist in /tmp/

I think this is a race condition when enabling "Enable motion guard".

What I believe is happening: flip the “Enable motion guard” switch which is sent to the streamer through a websocket call and written to prudynt.json asynchronously. Then tick the “Save to mount” checkbox which calls /x/json-motion.cgi?target=mount&state=true. json-motion.cgi appends motion_send2mount="true" to /etc/thingino.config and then does

        service restart prudynt
        service restart vbuffer

Because the websocket write in step 1 has not finished yet, motion.enabled is still “false” when vbuffer is restarted, so the service quits after its own check and no /tmp/vbuffer.mp4 is produced.

[jsn-0]

Split target path into separate mount-point (-m) and subdir (-d) options/vars and rebased on master. This is ready for review.