Boost quality / swap streams on motion

[pops106]

Is it or would it be possible do have 24/7 recording setup on a lower res stream say 640x480 5fps but once motion is detected it automatically switches to the better 1920x1080 15fps stream.

I used to work with a CCTV system that had this option called boost on motion.

It would significantly reduce storage requirements and still allow 24x7 recording in case anything is missed.

[NickM-27]

It could be done today in an indirect way by adding the same camera twice and setting one to record the high quality stream on motion and another to record the substream 24/7 but there would be redundancy in that the substream would be recording during the motion as well.

As far as a seamless solution, I think it would be "possible" but there are a lot of implementation details that could cause issues:

1. Typically camera streams are not in perfect sync so switching to another stream would likely cause some and could cause a decent amount of lost footage.
2. There's also the part that the switching itself would cause latency unless there was a constant ffmpeg connection to both stream for recording at the same time which would be extra CPU usage / memory usage all the time.
3. Probably some others I'm not thinking of.

On the other hand, it could be just as well to just compress the segments without motion to a lower resolution as that would have the same effect 🤔

Overall, there have been variations of this requested, not sure where this fits in the current roadmap. Here is a pinned issue with this idea: #2652

[pops106]

What if we simplify it. Record the 1080p stream at say 2fps saving on storage but up the fps on the same stream during motion to 15fps.

…

On Mon, 28 Mar 2022, 19:20 Nicolas Mowen, ***@***.***> wrote: It could be done today in an indirect way by adding the same camera twice and setting one to record the high quality stream on motion and another to record the substream 24/7 but there would be redundancy in that the substream would be recording during the motion as well. As far as a seamless solution, I think it would be "possible" but there are a lot of implementation details that could cause issues: 1. Typically camera streams are not in perfect sync so switching to another stream would likely cause some and could cause a decent amount of lost footage. 2. There's also the part that the switching itself would cause latency unless there was a constant ffmpeg connection to both stream for recording at the same time which would be extra CPU usage / memory usage all the time. 3. Probably some others I'm not thinking of. On the other hand, it could be just as well to just compress the segments without motion to a lower resolution as that would have the same effect 🤔 Overall, there have been variations of this requested, not sure where / if this fits in the current roadmap. — Reply to this email directly, view it on GitHub <#3026 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOJUORGCVO5IYASHFUFWNTVCHZ5HANCNFSM5R36QUEA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[NickM-27]

Would still either require a second ffmpeg session or post-processing re-encoding to reduce framerate. It's pinned so on the todo list, just depends when it hits on the roadmap. If you have any ideas / ways to implement then I would recommend leaving it on that issue since that's the base discussion for the feature.

[johnmarksilly]

This should be really easy as a post processor. Basically just need to stitch the higher-resolution event clips with the 24 hour 1hour segments.

[johnmarksilly]

Really good idea actually.

[pops106]

Yes of course it would, I was thinking of detect fps but we are just pulling a stream from the camera without touching it for the recording. Thinking back to the CCTV system I used, I believe it used to pull both streams from the camera and it was recording in it's own proprietary format so I guess they could do this but it used a boat load of CPU. Will have a look for that discussion you mentioned. Cheers

…

On Mon, 28 Mar 2022 at 22:10, Nicolas Mowen ***@***.***> wrote: Would still either require a second ffmpeg session or post-processing re-encoding to reduce framerate. It's pinned so on the todo list, just depends when it hits on the roadmap. If you have any ideas / ways to implement then I would recommend leaving it on that issue since that's the base discussion for the feature. — Reply to this email directly, view it on GitHub <#3026 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOJUOVLKMXLVY3Q4SLYC23VCIN5LANCNFSM5R36QUEA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[NickM-27]

It's here, should be showing as a hyperlink: #2652

and yeah, I believe there are a considerable amount of users on the R Pi so the main goal is trying to keep CPU usage down.