On 12 November 2015 at 11:56, Mark Rogers mark@more-solutions.co.uk wrote:
My thinking was that movie compression works by storing deltas between images rather than keeping each frame in full so should be "smaller".
I have done some experiments (see below) using cvlc to capture the RTSP stream from the camera.
An hour's worth of data in .ts (MPEG) video format comes in at 312MB. An hour's worth of photos (captured at a rate of 1 every 4 sec by zoneminder) comes in at 640MB.
That's not necessarily a fair comparison as I don't know what frame rate the video is at (how do I find out?) but it's a good saving so far.
So, for reference, what I did was create the following script:
#!/bin/sh d=$(date +"%Y/%m/%d") f=$(date +"%Y%m%d-%H%M%S") d="/home/mark/IPCam/$d" for ip in 128 129 ; do ip=192.168.1.$ip mkdir -p $d/$ip cvlc -q --no-audio rtsp://$ip:554/11 --sout=file/ts:$d/$ip/$f.ts -I dummy --stop-time=905 vlc://quit 2>/dev/null & done
I'd by lying if I claimed to fully understand it, as it's mostly cobbled together from commandlines I found online, but the gist of it is that it captures a 905s stream (just over 15 mins) on each of two cameras (192.168.1.128 / 129) and stores it as (eg) ~/IPCam/2015/11/12/192.168.1.128/20151112-234501.ts. I run this script cron crontab every 15 mins, thus capturing video in 15min chunks.
However, reviewing the results from last night, out of 23 15 min captures from one camera, 7 have zero byte file length; from the other camera it's 5 out of 23, and there's no obvious overlap between the two cameras as to which failed to indicate a network issue.
So, does anyone have any idea what I can do to make it more robust?
Mark