Feature request: Continuous Capture - additional capture rate option
  • I'm doing a lot of work to utilize the Continuous Capture > Image Capture feature the way I need it - which is all good, but...

    If I could lower the frame rate on Continuous Capture > Movie Capture to less than 1 frame per second that would be very helpful and perhaps a lot less work.

    As I mentioned before, my cameras are generally configured to capture continuous image 1 frame every 5 seconds, while motion capture is around 60-120 seconds with 60-240 seconds pre/post roll. This is a nice balance for me in terms of data management vs continuous monitor vs motion capture.

    If I could capture a continuous MOVIE at 1 frame per 5 seconds (or 'n' seconds) that would be a lot less hassle than managing image sequences.

    You could change the pref like this:

    Preferences > Continuous Capture:
    Capture Rate: ____ frames per ____ second(s) (adding a text field for the seconds value)

    I realize this could result in users specifying some non-integer results, ie 3 frames per 5 seconds, but that would actually be ok, wouldn't it? If your timer is perhaps working out the capture time in the nearest millisecond or something like that, then it would simply capture every 600 milliseconds, etc... ? Which should be fine, because you allow for a separate playback rate specified in the resulting movie so the capture rate is mutually exclusive and arbitrary.

    Please consider, and thank you!
  • Does your camera have 2 export modes to it? for example, my Amcrest ones have a primary and secondary stream option. I have the secondary stream export set to 720p/5fps and I record that continuously. When I do motion detection, I have it trigger a 10s clip from the camera's primary stream at 2k/15fps.
  • They do have that feature but that's not how I want to operate. I prefer a long interval frame capture like 1 frame per 5 seconds when no motion is present. That makes the video easy to quickly review like a timelapse for general activity inside/outside the building, etc.
  • You can actually do this in SecuritySpy: simply enter a capture frame rate of 0.5 for 1 frame every 2 seconds, or 0.2 for 1 frame every 5 seconds etc.

    Note that (assuming this is an IP camera that is supplying H.264 or H.265 video data) in order to alter the frame rate of the incoming video stream, you must enable the "Recompress video data" option for the camera under the Device tab. This isn't generally recommended, as it uses more CPU time and reduces quality a tiny bit, but it's the only way to adjust the frame rate of the stream for capture.
  • >in order to alter the frame rate of the incoming video stream, you must enable the "Recompress video data" option for the camera under the Device tab.

    I don't understand this limitation. If SecSpy can capture a frame buffer via the Image Capture/Frequency settings in order to save a JPG image file at any arbitrary time, then why does it matter what the camera frame rate is and re-compress required in order to capture the same buffer and instead write it to a movie file, regardless of the rate of capture? Why can't SecSpy just grab a buffer every 1/0.2=5 seconds and write it to a mov/mp4 using the same JPEG codec?
  • I edited above post - I didn't realize while testing that each time I armed the camera for continuous capture, SecSpy was appending to the same m4v file. Once I deleted it and captured again, I realized the 1/0.2 setting was actually working.

    That said, having to re-compress is not optimal per above comment. I would prefer it if SecSpy could just write a frame buffer to a mov file at the specified rate, essentially identical to what it's already doing with JPG image sequences (without having to re-compress)
  • I see that SecSpy has ProRes422HQ under the re-compress settings. That's nice - I hadn't noticed that before.

    How about adding some of the other ProRes codec options? HQ is great, but overkill in many cases. Regular ProRes 422 would be enough for any security camera (I'm not aware of any security cameras streaming 10 bit video which is about the only time HQ makes sense). ProRes LT is a very high quality codec, and even ProRes Proxy would probably be useful for many people.

    Is SecSpy just using ffmpeg under the hood for all the video re-compression/writing? If so, all the ProRes codecs are definitely available, at least in relatively recent versions of ffmpeg.
  • I think SSpy uses this https://en.wikipedia.org/wiki/Quartz_Composer - I would also love to see less CPU used to write time lapsed videos like this.
  • If the "Recompress video data" option is off (as it is by default), then SecuritySpy writes the video data supplied by the camera directly to the recorded files. If this option is on, then SecuritySpy decodes this incoming data, and then encodes it to the format specified under Preferences -> Compression.

    If the camera is supplying JPEG video, then SecuritySpy can drop frames from the incoming stream in order to satisfy any frame rate requirement for recording, however this is not possible for temporally-compressed streams such as H.264 or H.265. In this case, SecuritySpy has to decode all incoming frames, and then encode just the ones it needs for the captured files. This is the only way to change the frame rate of an H.264/H.265 stream.

    Still images are always written in JPEG format. If the incoming video from the camera is JPEG, then SecuritySpy can use the source data as-is for this. But if this incoming video is anything else (e.g. H.264/H.265), then again SecuritySpy has to decode every incoming frame, and then encode and save the right frame(s) as JPEG.

    As for ProRes - yes this option has just been added, but it's not useful for CCTV purposes as the file sizes will be far too large. We have many customers using SecuritySpy for non-CCTV purposes (e.g. scientific experiments, interviews, film sets), where they need to capture very high quality video from sources such as Blackmagic devices, and this option is to make SecuritySpy even more useful for this set of customers.

    SecuritySpy uses Apple's VideoToolbox API for video encoding/decoding, not ffmpeg.
  • >Still images are always written in JPEG format. If the incoming video from the camera is JPEG, then SecuritySpy can use the source data as-is for this. But if this incoming video is anything else (e.g. H.264/H.265), then again SecuritySpy has to decode every incoming frame, and then encode and save the right frame(s) as JPEG.

    My cameras are Amcrest h264. I don't have the recompress option checked, but I have been using the capture image/continuous @ 1 JPG frame every 5 seconds for a long time. How is that working? Are you saying that by enabling the continuous image capture option, that is causing SecSpy to recompress every frame of the incoming stream, even though I don't have the recompress checkbox enabled?

    >As for ProRes - yes this option has just been added, but it's not useful for CCTV purposes as the file sizes will be far too large.

    I appreciate that you are supporting some high-end scenarios with 422HQ (I work in post-production and understand all the requirements of various workflows), but ProRes Proxy or LT (for my 4K cameras) actually would be a perfect codec for my motion capture and timelapse/image capture purposes, as it's very fast to encode and decode, it has smooth playback that allows fast review of footage, and just generally works much better than any long-GOP codec. The codec is applicable to the source. If the source is an 8 bit 4:2:0 video stream, then even for high end video work, 422 (not HQ) or LT are perfect choices.

    It would be great if you would add the other ProRes options. I would think it trivial to expose them if you are using Apple's API.
  • The "Recompress video data" option only applies to movie capture. For image capture, if the source video is not JPEG, then the incoming video data always has to be recompressed to produce the JPEG images. This is done by decoding every incoming frame, and then encoding the required frames to JPEG to save them to image file (i.e. not every frame is being encoded to JPEG - just the ones required to satisfy the image capture requirements).

    As for ProRes: yes, it would be trivial to expose the other variants, but I'm hesitant to clutter the UI, especially with stuff that isn't going to be useful to most users. If you have incoming H.264 video data, and want to recompress and encode this to timelapse movies with very high quality, then I suggest that ProRes is overkill, and using JPEG compression at 100% quality is going to be the best option. JPEG is 4.2.0 (matching the sampling of the incoming H.264), it's not temporally compressed (i.e. only I-frames, like ProRes), and at 100% quality you will barely get any image degradation. What do you think?
  • >I'm hesitant to clutter the UI, especially with stuff that isn't going to be useful to most users.

    Hmm.. How do you know it won't be useful for them if they option isn't available? ;-)

    I love ProRes ;-) I am a big fan of ProRes Proxy and LT for mezzanine quality video streams and I honestly think other people would find it very useful as well, this being a Mac app.

    I'm looking at a JPG image capture sequence right now from Security Spy. 30 frames of 1080p JPG images is just shy of 15 MBs, which equates to about 120 Mbps @ 30fps. Now check the ProRes white paper specs:

    ProRes data rates:
    https://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf

    ProRes LT is 102Mbps and ProRes Proxy is 45Mbps. Frame for frame, ProRes LT and Proxy are lighter weight than JPG, and they probably encode with less CPU usage, and I know ProRes decodes faster than JPG (for any necessary playback and editing), so, respectfully, I think you should reconsider.

    On the topic of recompress:
    >This is done by decoding every incoming frame, and then encoding the required frames to JPEG to save them to image file (i.e. not every frame is being encoded to JPEG - just the ones required to satisfy the image capture requirements).

    Understood. Enabling JPG image capture fires up constant decoding and there's no way around it. I get it.
  • Thanks for your input. I would like to add these extra options as I want the software to be as flexible as possible, but a clean UI is also high priority (and I know that most users don't want this as this has been requested so rarely!). I'll see if I can do this in such a way that doesn't clutter the UI too much (e.g. a submenu to choose the ProRes variant perhaps). I'll consider this further and get back to you.
  • Thank you! I understand what you're saying about the UI - a submenu is a great idea.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!