On 14 May 2018 23:12:41 GMT, A. Dumas 
declaimed the following:

>
>One jpeg will *easily* fit in system RAM. Also it’s in the filesystem.
>Write to RAM at /run/shm/ and avoid all sd card writes. (Unless there’s
>heavy swapping.)

 A true JPEG would... But closer look at the provided code indicates it
is not a JPEG, but a variant of h.264 VIDEO... That's likely to get a bit
larger ... Depends upon resolution and frame rate (which aren't
specified in the code -- the V2 Pi Camera module is 8MP as stills, and
supports 1080p30 video. I've not found a good source for estimating file
size -- Wikipedia seems to show around 20-50kbps for those resolutions...
Which should still hold 10 seconds worth of video (but note that the
original code does not seem to ever delete anything, it just creates new
time-stamped 10-second files with 25-second skips as long as motion
continues to be detected).

 However, given the OP's statement of trying to put the files on a NAS
device -- it should be possible to directly address the NAS storage and
touch neither the SD card nor RAM; and that avoids the complication of
having to delete the file(s) after transfer. I don't know how much overhead
the NAS access would inflict upon the camera capture... 50kbps shouldn't
have much of a hit on WiFi or 100Mbps Ethernet. If it does, using RAM for
the capture, and using the 25 second gap to do a transfer/delete may be
viable.

 I'd probably also change the OP's delay logic by capturing the start
time after motion is detected and then, after capture (~10 seconds) and
post-processing (assuming RAM to NAS/delete RAM), using initial capture
time + (say 30 seconds) - current time to determine the sleep time before
checking for motion again. This would result in evenly spaced clips as long
as there is motion... OP's code, if there were not post-capture processing,
is resulting in ~35 second spacing...


--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05