CPU overload

User avatar
TimG
Posts: 655
Joined: Tue Jun 18, 2019 10:45 am
Location: Nottinghamshire, UK.

Re: CPU overload

Post by TimG » Sat Sep 12, 2020 8:53 am

Hi miles267,
How did you get it to work? I went from 8 1080P cameras with CPU at 30%; after enabling sub streams my CPU jumped over 80%.
The first thing is to do one camera at a time and watch what happens in BI5 and watch the cpu loading.

What resolution did you set the sub streams to in the actual camera web server settings (Not the BI5 camera settings) ? What we are doing here is giving BI5 a much lower resolution image to do motion detection on, so it makes sense that the cpu load for motion detection is reduced; the main stream should be direct to disk for H264.

For example, looking at the actual camera web server page, the main stream for my Dahua camera is 1920x1080, and the sub stream is 704x576(D1). When I look at the BI5 settings for this camera, in the General tab, I can see:

Main stream 2.1MP, 11.99/1.00 fps, 263.3 kB/s.
Sub stream 0.4MP, 11.00/1.00 fps, 64.4 kB/s.

So even though I have increased the overall network traffic, BI5 can do motion detection on a 0.4MP image instead of the 2.1MP image. My cpu loading went down from around 18% to 8% by doing this to three cameras.

Historically, the internet was full of people asking"Why does Blue iris use so much cpu ?". The answer was that other software was doing motion detection on the sub streams.
Blue Iris v5.3.2.8 | Win10 x64 version 2004 | Dahua IPC-HDW5231R-ZE, Foscam R2, Ertech 4MP, 2 analogue cameras on Euresys Picolo Pro 2 | Intel i5-3330 CPU, 16GB Ram, Multiple SSD and HD | TVMosaic.
miles267
Posts: 20
Joined: Mon May 04, 2020 3:38 pm

Re: CPU overload

Post by miles267 » Sat Sep 12, 2020 3:18 pm

Thank you for the guidance. I finally got it to work. Turns out, it was actually an issue where I had selected the incorrect Amcrest camera type/profile in a specific set of camera(s) and that was resulting in high CPU because it was using the wrong profile to make those camera connections. Oddly enough, it was still displaying the images from those cameras fine with the main stream (and has always been, although setup incorrectly). But it wasn't until I attempted to use the sub stream feature for these cameras that the issue surfaced. As a result, there's a good chance my CPU usage had been higher than it should've even when using the main streams all along.

Anyway, now that that's been addressed, it's working like a charm. 8 IP cameras at about 6% max CPU on the BI5 server.

Quick question -- in the cameras settings (camera itself, not BI5 camera setting), for the substream, what bitrate do you suggest for a 1080P camera whose substream runs at 640x480 (VGA)? I have the option of 96 Kbps all the way up to 2048 kbps... and am currently set at 256 kbps.

Thanks again.
User avatar
TimG
Posts: 655
Joined: Tue Jun 18, 2019 10:45 am
Location: Nottinghamshire, UK.

Re: CPU overload

Post by TimG » Sat Sep 12, 2020 3:45 pm

With the cpu % reductions that you now have, I think you should leave it as it is and back up all of the settings immediately :o

My D1 sub stream is set at 512 Kb/S, but it is VBR rather than CBR. In my previous post, you can see that it was actually running at 64.4 Kb/S.

Can anybody tell us the techie answer to the required bitrate for the sub stream ?
Blue Iris v5.3.2.8 | Win10 x64 version 2004 | Dahua IPC-HDW5231R-ZE, Foscam R2, Ertech 4MP, 2 analogue cameras on Euresys Picolo Pro 2 | Intel i5-3330 CPU, 16GB Ram, Multiple SSD and HD | TVMosaic.
miles267
Posts: 20
Joined: Mon May 04, 2020 3:38 pm

Re: CPU overload

Post by miles267 » Sun Sep 13, 2020 11:40 pm

Thanks. Also what causes the cameras in BI5 to periodically flash as green screens for a few seconds?


Sent from my iPhone using Tapatalk
Matts1984
Posts: 199
Joined: Fri Apr 10, 2020 1:12 pm
Location: Maryland, USA

Re: CPU overload

Post by Matts1984 » Mon Sep 14, 2020 1:03 pm

TimG wrote:
Sat Sep 12, 2020 3:45 pm
With the cpu % reductions that you now have, I think you should leave it as it is and back up all of the settings immediately :o

My D1 sub stream is set at 512 Kb/S, but it is VBR rather than CBR. In my previous post, you can see that it was actually running at 64.4 Kb/S.

Can anybody tell us the techie answer to the required bitrate for the sub stream ?
I've always set the bitrate options to VBR and a limit as high as possible. As you said, the camera is going to use what it uses and at a whopping 64.4 Kb/s you could have 100 simultaneous substreams and only get to 6.5Mbps (on what I'd assume is a gigabit network). Since the numbers are so small, I'd hate to find one day that a paranoid unnecessary setting was impacting alerting. If you DID want to tweak that much - and trust me, I like to tweak but just not that setting - I'd recommend simply observing a daytime mode actual bitrate (nighttime b/w can easily halve the bitrate) and maybe double it. So in the above example, you could probably safely set to 128 Kb/s - but again, what is the real gain from this limitation vs the possible risk?
miles267
Posts: 20
Joined: Mon May 04, 2020 3:38 pm

Re: CPU overload

Post by miles267 » Mon Sep 14, 2020 3:59 pm

Matts1984 wrote:
Mon Sep 14, 2020 1:03 pm
TimG wrote:
Sat Sep 12, 2020 3:45 pm
With the cpu % reductions that you now have, I think you should leave it as it is and back up all of the settings immediately :o

My D1 sub stream is set at 512 Kb/S, but it is VBR rather than CBR. In my previous post, you can see that it was actually running at 64.4 Kb/S.

Can anybody tell us the techie answer to the required bitrate for the sub stream ?
I've always set the bitrate options to VBR and a limit as high as possible. As you said, the camera is going to use what it uses and at a whopping 64.4 Kb/s you could have 100 simultaneous substreams and only get to 6.5Mbps (on what I'd assume is a gigabit network). Since the numbers are so small, I'd hate to find one day that a paranoid unnecessary setting was impacting alerting. If you DID want to tweak that much - and trust me, I like to tweak but just not that setting - I'd recommend simply observing a daytime mode actual bitrate (nighttime b/w can easily halve the bitrate) and maybe double it. So in the above example, you could probably safely set to 128 Kb/s - but again, what is the real gain from this limitation vs the possible risk?
As a result, I've since switched my setup from CBR to VBR on both my main and sub streams for all cameras. Have set the VBR quality to 6 (highest) for both the main and sub streams as well. The bitrate is still set at 4096 kbps for my main streams and now 128 kbps for the sub streams on all cameras. They are 1080p cameras.
Post Reply