OK, I will try the CPU benchmark test, the CPU on this machine is cooled by a triple fan of asus water cooler. I will pull the block off the CPU and check the thermal paste.
Also, I use some lorex cameras with my blue iris system. I have logged into each of these cameras and set the substream and mainstream to H265 and put both of the substream and mainstream frame rates at 15. Unfortunately, lorex cameras do not have an option to change the i frame interval. A couple of the PTZ cameras I do set it to 30 frames per second so I could get very smooth video out of it.
Is there any advantage or disadvantage of using H265 or H265+ instead of H264?
BI works best with H264.
The TL : DR version is H265 is not a consistent codec standard and every manufacturer does it different, which can be problematic with some VMS systems. H264 tends to be the consistent codec. Plus H265 uses more camera processor resources, which can then be problematic with other options on the camera. UI3 uses H264, so if you are using H265 then it has to be re-processed which can cause issues.
Now for the long version:
SmartCodec (+ variants) can create lots of problems with playback / search - many have seen it jumps and skips over time, plus it is proprietary to the manufacturer and can be problematic with other VMS systems.
Most of us have found H265 in these cameras suck.
H265 in theory provides more storage as it compresses differently, but part of that compression means it "macro blocks" (technically coding tree units) big areas of the image that it thinks isn't moving. That can be problematic for digital zooming with H265.
However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera in other areas like FPS and then it stutters.
Further some cameras can handle H265 better than others, even if the camera "claims" to support it, it may actually do a very poor job with it.
In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My savings were less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.
The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution in those larger blocks yet increases the camera CPU demand to develop these larger blocks. For some cameras that then becomes problematic to do other functions as the little processor is now maxed out.
In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is essentially zero.
In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.
In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.
Digital zooming is never really good and not something we recommend, but you stand a better chance of some digital zoom with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.
H265 is one of those theory things that sounds good, but reality use is much different.
Some people have a field of view or goals that allow H265 to be sufficient for their needs.
Third party VMS systems do better with H264. That is the tried and true standard. H264H is ok as well.
As always, YMMV.
The TL : DR version is H265 is not a consistent codec standard and every manufacturer does it different, which can be problematic with some VMS systems. H264 tends to be the consistent codec. Plus H265 uses more camera processor resources, which can then be problematic with other options on the camera. UI3 uses H264, so if you are using H265 then it has to be re-processed which can cause issues.
Now for the long version:
SmartCodec (+ variants) can create lots of problems with playback / search - many have seen it jumps and skips over time, plus it is proprietary to the manufacturer and can be problematic with other VMS systems.
Most of us have found H265 in these cameras suck.
H265 in theory provides more storage as it compresses differently, but part of that compression means it "macro blocks" (technically coding tree units) big areas of the image that it thinks isn't moving. That can be problematic for digital zooming with H265.
However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera in other areas like FPS and then it stutters.
Further some cameras can handle H265 better than others, even if the camera "claims" to support it, it may actually do a very poor job with it.
In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My savings were less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.
The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution in those larger blocks yet increases the camera CPU demand to develop these larger blocks. For some cameras that then becomes problematic to do other functions as the little processor is now maxed out.
In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is essentially zero.
In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.
In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.
Digital zooming is never really good and not something we recommend, but you stand a better chance of some digital zoom with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.
H265 is one of those theory things that sounds good, but reality use is much different.
Some people have a field of view or goals that allow H265 to be sufficient for their needs.
Third party VMS systems do better with H264. That is the tried and true standard. H264H is ok as well.
As always, YMMV.
H.265 is a newer, more advanced encoding method than H.264, and H.265 is typically a bit more CPU intensive to decode (not nearly enough to explain your problem though).
Also some people have done comparisons of H.264 vs H.265 and found that with all else being equal (e.g. bit rate, resolution, etc) they like the picture produced by H.264 better. Performance will vary by camera and by firmware version and with different encoder settings. At a high enough bit rate, if everything is working properly the visual differences are negligible. It is mostly a matter of personal choice and either of them should work fine.
H265+ or any codec with a "+" or "Smart Codec" in it, use manufacturer-specific encoding optimizations that MAY or MAY NOT have compatibility problems when using a third party recorder. (Blue Iris is a third-party recorder). In theory you'll get better quality or lower bit rate (or both) if you use it. But like I said it can introduce compatibility problems. In particular one of the tricks it will likely use it to create fewer and less predictable i-frames. So it is generally advisable to not use the "+" or "smart" codecs offered by cameras unless you also use an NVR of the same brand as the camera. But there's nothing stopping you from trying it though and deciding for yourself.
Last edited:
All temps remained around 23c-26c so the CPU heat is not an issue.
Results look very good
23-26c means you've got basically no load on the CPU.
Benchmark scores look great though.
So I dunno what is going on.
Benchmark scores look great though.
So I dunno what is going on.
Its fluctuating around 70-95% cpu usage!
I tried changing all cameras to H264 and still CPU usage is high.
All decoding is off.
I have 5 Drives for storage that are each its own drive letter. I couldn't imagine that being the problem. I checked the usage on the drives and they are very low 1-5%
I just can't understand why its spiking so high...
I tried changing all cameras to H264 and still CPU usage is high.
All decoding is off.
I have 5 Drives for storage that are each its own drive letter. I couldn't imagine that being the problem. I checked the usage on the drives and they are very low 1-5%
I just can't understand why its spiking so high...
I have split the cameras up to record to different drives. For example first 10 cameras record to d:\Storage, next 10 record to e:\storage, and so on. I don't move any files around
Its staying around 90% which is crazy. I use this system for my business, just paid for the 2 year support and upgrades so I could upgrade to think that would help.. but did not make a difference! I hate to keep this PC running all the time when the CPU is being pegged at 100% sometimes.
We're missing some crucial detail. Something like "oh yeah, I have 10 UI3 clients connected" or "I'm using Blue Iris's RTSP server to serve all my camera streams to someone else 24/7".
Besides the CPU usage being crazy, everything else about this looks healthy. There's lots of network traffic (240 Mbps) and disk usage (29.6 MB/s). Memory usage is very reasonable. The CPU temperature in that Core Temp screenshot is frankly great for the load it is showing.
Your disk setup is very good for a large scale setup, distributing the load nicely with no I/O wasted on moving files.
This should be running great.
I hate to tell you to delete the BI configuration and start over from scratch with 53 cameras... what a lot of work.
The fact you had BI using a lot of CPU with all the cameras disabled is really a sign there is something unusual going on and that is probably the first thing I'd try to figure out. What could be making it use so much CPU for nothing?
Besides the CPU usage being crazy, everything else about this looks healthy. There's lots of network traffic (240 Mbps) and disk usage (29.6 MB/s). Memory usage is very reasonable. The CPU temperature in that Core Temp screenshot is frankly great for the load it is showing.
Your disk setup is very good for a large scale setup, distributing the load nicely with no I/O wasted on moving files.
This should be running great.
I hate to tell you to delete the BI configuration and start over from scratch with 53 cameras... what a lot of work.
The fact you had BI using a lot of CPU with all the cameras disabled is really a sign there is something unusual going on and that is probably the first thing I'd try to figure out. What could be making it use so much CPU for nothing?
Can you revisit the request from @wittaj?
The picture you actually posted in response to this was missing the totals, which makes it hard for us to judge whether sub streams were actually working or not.
The picture you actually posted in response to this was missing the totals, which makes it hard for us to judge whether sub streams were actually working or not.
We have about 5 clients connected to this, I just did a test and closed down all web clients and the cpu went to 5%-10%!!
What would cause the webserver clients to make the server cpu spike up? How can I reduce this?
Several things.
First, look at your BI Settings > Web server > Advanced, click the Configure button next to Streaming 0, and share a screenshot of that panel so I can make sure you didn't do anything weird in the encoder configuration. You wouldn't believe the things people do in there sometimes
Then to reduce the CPU usage, it depends on what specific activities are causing the high usage.
If it is mostly single camera live viewing (which would surprise me honestly) then you can reduce the CPU cost by using H.264 (not H.265) on the cameras and enabling direct-to-wire in the Streaming 0 configuration.
If people are viewing camera groups and that is the main cause of the high CPU, then it is very important that you have sub streams working correctly so the rescaling is cheaper. (see the earlier requests for the camera status screenshot showing the totals). The more cameras you have, the more it costs to encode group video streams, and you have a lot of cameras.
Make sure your recording settings are recording the sub stream along with the main stream, otherwise Timeline playback is crazy CPU intensive.
To reduce CPU cost associated with creating group video streams:
1. Limit the frame rate of the groups.
This is in the group configuration panel in Blue Iris's local console. Select a group and click the gear icon next to it:
Do this for each group. The lower the frame rate you can get away with here, the better. 5 FPS looks kind of crappy but it is 1/6th the CPU usage compared to 30 FPS.
2. Limit the group resolution in UI3
Right click the group video in UI3 and choose Group Settings. Inside is a slider for the max resolution of dynamic groups. Higher values here STRONGLY affect server CPU usage. I don't get a lot of concurrent remote viewers on my system so I can get away with 9 MP and 30 FPS. You probably can't.
(UI3's settings are stored locally in the browser where you edit them; make the same change on all UI3 clients as needed)
If your groups have a fixed aspect ratio assigned in Blue Iris's layout editor, then you can also limit the max resolution of those groups in Blue Iris's layout editor.
Several things.
First, look at your BI Settings > Web server > Advanced, click the Configure button next to Streaming 0, and share a screenshot of that panel so I can make sure you didn't do anything weird in the encoder configuration. You wouldn't believe the things people do in there sometimes
Then to reduce the CPU usage, it depends on what specific activities are causing the high usage.
If it is mostly single camera live viewing (which would surprise me honestly) then you can reduce the CPU cost by using H.264 (not H.265) on the cameras and enabling direct-to-wire in the Streaming 0 configuration.
If people are viewing camera groups and that is the main cause of the high CPU, then it is very important that you have sub streams working correctly so the rescaling is cheaper. (see the earlier requests for the camera status screenshot showing the totals). The more cameras you have, the more it costs to encode group video streams, and you have a lot of cameras.
Make sure your recording settings are recording the sub stream along with the main stream, otherwise Timeline playback is crazy CPU intensive.
To reduce CPU cost associated with creating group video streams:
1. Limit the frame rate of the groups.
This is in the group configuration panel in Blue Iris's local console. Select a group and click the gear icon next to it:
View attachment 232454
View attachment 232455
Do this for each group. The lower the frame rate you can get away with here, the better. 5 FPS looks kind of crappy but it is 1/6th the CPU usage compared to 30 FPS.
2. Limit the group resolution in UI3
Right click the group video in UI3 and choose Group Settings. Inside is a slider for the max resolution of dynamic groups. Higher values here STRONGLY affect server CPU usage. I don't get a lot of concurrent remote viewers on my system so I can get away with 9 MP and 30 FPS. You probably can't.
(UI3's settings are stored locally in the browser where you edit them; make the same change on all UI3 clients as needed)
View attachment 232456
If your groups have a fixed aspect ratio assigned in Blue Iris's layout editor, then you can also limit the max resolution of those groups in Blue Iris's layout editor.
So in video record settings for each camera, I need to make sure the "Record dual-streams if available" is ON?
Yes. it is the default setting so if you never changed it, it should still be on.
The 120 FPS max assigned to group streams is probably a HUGE part of your CPU problem. Holy cow. Fix that for sure. You have basically no reason to set it higher than your highest camera. I'd never set it higher than 30. Consider even 15 FPS if 30 does not yield enough CPU savings.
Don't forget to set max FPS for all of your camera groups, not just the All cameras group.
Also, yes, your Streaming 0 configuration has all kinds of bad settings.
The max kbps of 50 is very, very low and will result in bad image quality in Blue Iris's mobile apps (which don't override the bit rate the way UI3 does).
Keyframe interval should be set to 1000 for optimal performance. 15 means BI has to send a LOT more i-frames and this is really bad for encoder efficiency.
The threads setting can also be left at its default value of 1. I don't think it has ever actually worked.
Same with Intel QSV hardware encoding. I don't think that has ever worked either. It might work now after Blue Iris's recent refactoring, but I seriously doubt it. Fortunately BI just silently falls back to software encoding when hardware encoding doesn't work.
Here are my recommended Streaming 0 encoder settings for comparison:
(the Resize output frame option is largely meaningless for UI3 so I just leave it at default for consistency; UI3 always specifies the resolution it wants in each video request)
Most of your cameras are only producing 15 FPS so a 15 FPS max group frame rate would be most appropriate here, not 30 FPS.
I tried 120 FPS just now on my own system and BI only managed to hit 45 FPS anyway, so I don't think it cost you 8x higher CPU having it set to 120 FPS but it definitely was a waste of resources.
I tried 120 FPS just now on my own system and BI only managed to hit 45 FPS anyway, so I don't think it cost you 8x higher CPU having it set to 120 FPS but it definitely was a waste of resources.
I just changed it to those settings and it seems like the cpu is now running 50-60%. but still kind of high tho..
Also all my camera record settings have sub stream recording turned off, would this hurt the cpu also?
Having no sub stream hurts CPU when you use the Timeline or when you scrub in a clip because the sub stream is not available to make the rendering cheaper.
Set group max FPS to 15, not 30. Consider 5 or 10 FPS if necessary as this should significantly reduce the CPU usage even further and anyone can still click into individual cameras to get their full frame rate.
Set group max FPS to 15, not 30. Consider 5 or 10 FPS if necessary as this should significantly reduce the CPU usage even further and anyone can still click into individual cameras to get their full frame rate.