Video Clip Options + Product Enhancement

[Jmtyra]

(Part of this was already emailed to support, however I'm documenting it here for public discussion)

My feature request is the ability to specify the FPS recorded by SH upon object detection. While I understand that SH only needs (and thus records at) 10 FPS for object detection, it would be nice to record at higher FPS speeds. While 10 FPS is OK for people, quickly moving objects such as vehicles appear choppy at that speed and would appear smoother at 25 or 30 FPS.

How could this be accomplished? Currently SH uses a single stream (per camera) to both analyze the video and record the video when an object is detected. This is why SH only records at a maximum of 10 FPS even if the camera is providing more than 10 FPS.

My idea is for SH to split the "analyze" stream from the "recording" stream. Most IP cameras allow for two (or more) streams to be displayed at different FPS/resolutions/codecs. I propose that SH leverage two streams per camera instead of one; a primary "recording" stream at 30 FPS/high resolution and a secondary "analyze" stream at 10 FPS/lower resolution. When SH's computer vision detects an object/person/etc within the "analyze" stream it will then begin recording a video clip via the "recording" stream.

This would allow for lower CPU utilization while providing higher FPS/resolution video clips. Granted, each camera would need to be configured for two streams, however this is easily accomplished assuming the camera in question supports multiple streams or sub-streams. For cameras that don't support this feature (such as webcams or older IP cameras) SH could simply leverage the single stream as it does today.

Just a thought! I hope this suggestion makes it to your programming team.

Split stream high level overview.jpg

(31.48 KiB) Downloaded 191 times

[Semper Vaporo]

I think that is a neat idea, but as a retired computer programmer (who has done 'some' video processing software, eons ago) I am immediately drawn to the software gotcha's that crop up. I do not know how SH handles things internally so I am just surmising some possibles here.

It may be analyzing the lower rate/resolution video stream but at some point the area and time (frame number?) of detected motion has to be translated from the "analysis stream" to the "record stream" and that might require a re-thinking of how the information is stored internally. I assume the 'bounding box' that is drawn around the detected motion is based on the pixel count of the upper and left sides and the height and width are also in pixel counts. Have to change that to percentages possibly; not sure what that might do to accuracy of the location of the bounding box in the presented video, not that extreme accuracy there is important. The time of the event would also have to be translated to fit any different frame rate.

None of that is a game killer, but is something that may have to be taken into account and propagated to all portions of the program where ever that information is used.