Hello all. Just landed in this forum and I'm on the cusp of not knowing what I'm doing.

[Mike A.]

It's not only the aspect re alert processing, Think about the main console screen or UI3. Instead of N x full resolution/data rate for all of those cameras as it did prior to substreams, it's only having to handle N x the substreams. That's probably the biggest savings overall for CPU in a base-state system. Then you have alert processing and all of the rest happening in the background across multiple cams at lesser vs full resolution whether being viewed at the time or not.

 

[Steve.L]

While nobody directly responded to my "is it not?" question about two streams (a sub and a main) having the same effect on the system as actually having TWO camera feeds, I can deduce by the replies that, even if it is, that the savings (or "benefits") vastly outweigh that effect purely because of what and how the system does-with and utilizes each stream to save CPU, and that, I find amazing. Then again, since I have extremely limited knowledge about signal/data processing and most things related, it shouldn't be surprising

 

[Mike A.]

Yes. Maybe the better way to think of it is that prior to using substreams, the only stream available for ALL purposes was the full stream. So where and when the substream can be used more efficiently instead, there's a substantial benefit.

The second stream is made available by the camera and only used by BI as required. So there's not per se a second additive load for BI for all purposes at all times. In most all cases where it is used it's in place of the full stream. Thus, a substantial savings. In some cases where both are involved like dual-stream recording, the incremental difference is relatively small and the availability of that second recorded stream for other purposes makes up for that difference in better performance on the use side where that applies.

 

[sebastiantombs]

It all comes down to, basically, simple mathematics. It takes more processing power, CPU cycles, to examine a full resolution video stream, say 4MP which can translate to 1.2 megabits per second, versus a 1MP stream at say 250 kilobits per second. The math shows a six to one reduction in bits per second, the information being processed. The CPU then will be loaded less, by at least a factor of six or so, in this example. It is more nuanced than this, certainly, but the exact how and why isn't all that critical. The overall result is what counts.

Recording the full stream is not a particularly CPU intensive operation. In essence the video stream is basically just passed through to the hard disk as it comes in with very little processing that adds very little load to the CPU. It's processing the video for motion, examining every pixel for differences, that takes processing power and CPU cycles. If there are less pixels to process, the load is correspondingly lower.

With the upgrade to sub streams in Blue Iris, which is about a year and a half old at this point, being able to select exactly how the recording and processing is done has been the most valuable improvement I've seen in Blue Iris as a four or five year user of Blue Iris.

 

[Steve.L]

This is all very helpful, all your responses help build a composite and I'm able to paint a picture in my head how it all ties together and works.

 

[DanDenver]

+1 for BI
My hardware NVR had so many false alerts, that could not be tuned out, my wife opted out of notifications within the first month.
But with BI and AI, false alerts have been reduced about 95%. Took some tuning, but not a time sink and totally worth it!