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.

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.

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

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 ?

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


Sent from my iPhone using Tapatalk

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

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?

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

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.

Interesting.
I have 15 cameras 4mp to 5mp running on an i5-8400 using IGPU at around 40%-45%. H264 not h265
I would try not to use the nvidia gpu and use the integrated one. Doing so you will have to also run H264 as i don't think the IGPU in your CPU supports h265 hw decode etc.
The Intel HD graphics have alot of power for video encode/decode and for 35 cameras you should be fine. Then when you buy 8mp you can use ur nvidia for those. I found that the IGPU did better than the nvidia one did even with a 1080ti and given i save the power by not needing a power GPU in there it adds up over time.
I would like to know what your setup does if you changed each camera to h264 on the cam. Change your blueiris to intelhd in the main config, also if you have changed it in each camera setting and no nvidia and rebooted. It should run around 60% CPU use.
Also Check in each camera setting you have it set to blue iris DVR format and direct to disk. under Record under file container format.
Turn off substream.
Test
Now if it works well let me know, Setting the wrong h264/h265/nvidia settings can cause things to work but go very very slow.

Heres another tick for you
if you want to save disk space and save some CPU time. For each of your cameras copy them. So you have two of each, for the second one call that camera1SD and on those record, the substream "lower res feed from camera" set that to record 24/7 and go back into your first set of cameras and change those to record on motion/trigger only. You can also add them to two groups one called SD and one called HD. Your HD group only recorded the HD feed on motion and your SD group records all cameras 24/7 so you don't miss anything. You can choose to only show one group so you don't end up having 40 cams on one screen lol. You save alot of disk space and CPU power.

mikecam wrote: ↑Wed Oct 21, 2020 11:13 am Heres another trick for you
if you want to save disk space and save some CPU time. For each of your cameras copy them. So you have two of each, for the second one call that camera1SD and on those record, the substream "lower res feed from camera" set that to record 24/7 and go back into your first set of cameras and change those to record on motion/trigger only. You can also add them to two groups one called SD and one called HD. Your HD group only recorded the HD feed on motion and your SD group records all cameras 24/7 so you don't miss anything. You can choose to only show one group so you don't end up having 40 cams on one screen lol. You save alot of disk space and CPU power.

I like this and will try it out. I hope the user interface isn't too cumbersome with this technique. It might be an excellent to reco this to Ken as a feature request as a recording mode.

On VBR, I have never been able to scientifically approach the proper settings. By its very nature, scene content will dictate what the final product looks like for any given setting. I am left with trial and error focusing on scene clips where motion is present. A front yard with a tree on a calm day? A front yard with a tree on a windy day? A windy day with someone walking across the yard? Arghhhh getting the right setting isn't easy.