Here’s the image processing workflow for Scootercam cameras.
Today’s task involves defining and executing changes in the Scootercam raspberry pi service and matching php processor script. The processor will handle images, as described below; it will also manage “live” mp4 clips once per hour, nightly sunset mp4 and poster images, and the ongoing build of the “day-so-far” timelapse. Those will be detailed later.
This document and today’s task is about images on the website. Scootercam supports one or more cameras which take periodic images – say one every ten minutes. We should be able to choose which minute so multiple cameras aren’t performing these operations at the same time. The controller is currently set up with one Reolink PTZ camera. We’re adding the Duo 3 wide-angle camera later.
Images
When an image is captured, the Raspberry Pi image processor resizes the images to a web-friendly 1440 x 788 pixels. The smaller file is converted to webp format; then both files are sent to the website’s pi_in/snapshots directory. The filename includes the camera name abbreviation (ptz, reo, amc), date/time stamp, and “1400” for the width of the image. This is the same filename that will be used for the large, desktop-version delivered to desktops and large screens. Now we need to resize images on the web – no more GD-library conversion, just resizing.
A Cron job runs a script (scootercam_processor.php) every 5 minutes (minutes 1,6,11,16, etc). It looks for new images in the pi_in/snapshots directory, where it should find a fresh jpg and a webp image. Each of the 2 is resized to 800 px and 400 px versions (filenames adapted with “800” or “400” as appropriate) and saved to the appropriate /home/scooterc/public_html/images subfolder (ptz, reo, amc). Filenames thus include the camera name abbreviation (ptz, reo, amc), date/time stamp, and image width. After the resized images are created, the original 1400 pixel versions (jpg and webp) are moved from pi_in to the appropriate /home/scooterc/public_html/images subfolder – leaving the /snapshots directory empty. Finally, the /home/scooterc/public_html/images subfolders are culled of all but the latest set of images – the older src set images are deleted.
Along the way, we will need a WordPress plugin to display the src set images. The filename of the latest image changes ever ten minutes, so the plugin’s responsiveness will be both screen-size and filename aware. So, we need to rewrite the controller and receiver, and hold off on the plugin until we’ve reworked the mp4-side of the receiver script.
Live Video
In addition to capturing jpg images six times per hour, cameras can be configured to capture and send a brief “live” segment to the website. Here’s the breakdown.
For the PTZ camera, live video clips default to ten-second captures made at one minute past the hour during daylight hours. The clips are captured and optimized (re-encoded if necessary for smooth web playback and mobile devices) and sent to the web server’s cameras/videos directory. Additional versions in WebM, MOV, and MKV formats are possible and could be sent as well.
On the server, Cron runs a php script at 3 minutes past the hour. If video files are present in the cameras/videos directory, they are mozed to the public_html/live directory. Two ffmpeg operations are made to update two files (multiplied by additional version formats if made). The “recent” mp4 consists of the 3 most-recent mp4 live segments concatenated in order (results in an appx :30 video). For the “day-so-far” mp4 video, the newly-received segment can be appended to a day-so-far compilation, rather than rebuilding all the day’s segments.
On the WordPress/webserver side, we will need shortcode to deliver both the recent and day-so-far mp4s. They should be timestamped to avoid cache issues, so the plugin will need to find the files whatever their names are. At midnight, the day-so-far mp4 is moved to an archive directory and deleted after 30 days.
Standard timelapse
The standard timelapse process is for the camera to take an image every 10 seconds for fifteen minutes. At that moment, the images are queued on the Raspberry Pi for ffmpeg to create a timelapse segment. The images are likely at higher resolution than necessary for web and small device delivery, so an effective optimization strategy needs to be determined. The timelapse segment will be about :03 and is sent to the webserver’s cameras/timelapse directory. The segment filename includes a camera identifier so if multiple cameras are online, the php script at the server can make the right concatenation list. The ptz camera online now will commence its segments at 00, 15, 30,45 minutes past the hour; when the Duo 3 is online, its segments will be offset 5-10 minutes.
Once received, the timelapse segment is moved to the appropriate timelapse/ directory (reo, ptz) and once there, appended via ffmpeg to a day-so-far mp4 (keep CPU usage as low as possible for this operation). The filename includes the camera prefix (ptz, reo) and a timestamp. The file should rotate three times a day, so a morning, afternoon, and night mp4 is created each day. They are kept for 30 days before deletion.