5.4.4.8 Issue

Skispcs

Getting the hang of it
Joined
Jun 10, 2014
Messages
104
Reaction score
30
Updated to 5.4.4.8 hoping to get some Deepstack updates.

Blue Iris Service is going to 100% CPU and appears to hand then the service crashes with the following in event viewer.
Happens 3 to 4 times day

Faulting application name: BlueIris.exe, version: 5.4.4.8, time stamp: 0x6095a155
Faulting module name: VCRUNTIME140.dll, version: 14.22.27821.0, time stamp: 0x5d0c182d
Exception code: 0xc0000005

Yes, support has been emailed.
 

The Automation Guy

Known around here
Joined
Feb 7, 2019
Messages
1,376
Reaction score
2,736
Location
USA
Obviously we will see what support says, but I would suggest you start by uninstalling BI and then reinstalling the latest version. I suspect something went wrong during the update.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,005
Location
USA
I started getting CPU pegged at 100% after a while when using Intel hardware acceleration on an i7-8700K box. Not only would it be at 100% but a lot of cameras would be frozen. Disabling hardware acceleration sucks but it beats revering to a release from 6 months ago and never updating again.
 

Skispcs

Getting the hang of it
Joined
Jun 10, 2014
Messages
104
Reaction score
30
I started getting CPU pegged at 100% after a while when using Intel hardware acceleration on an i7-8700K box. Not only would it be at 100% but a lot of cameras would be frozen. Disabling hardware acceleration sucks but it beats revering to a release from 6 months ago and never updating again.
I am using Intel Hardware Acceleration, but I have only noticed this on the latest update.
I was on a 5.3 and it was good.
Noticed the Deepstack integration and I updated to a 5.4 and added an Nvidia card and setup Deepstack for GPU processing.
It appeared to be good at that point but I was changing a lot of stuff around and playing with the AI.
It appeared to be good for about a week on 5.4.3? or something close to that.
UPdated to 5.4.4.8 and I am getting the crashing and service restarts.

I can usually make it happen if I am in the GUI and I click on an alert to view the alert.
The GUI can lock up at that point and the CPU usage pegs and then after some time it just restarts the service
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,005
Location
USA
In my case, Intel hardware acceleration has been misbehaving since at least late January I think where Blue Iris would automatically turn off the hardware acceleration for no apparent reason on random cameras. The CPU 100% pegging was relatively recent. Maybe only after 5.4.x.

I do want to be able to run hardware acceleration because it helps with 4K 30 FPS playback but for now I just have it disabled.
 

gwminor48

Known around here
Joined
Jul 16, 2015
Messages
3,622
Reaction score
6,898
Location
Texas
^^
@bp2008 I never even noticed until I saw your post. I upgraded to 5.4.3.12 a couple of weeks ago. I checked after reading your post and saw all of my cameras had "No" for hardware decode. I changed them all after seeing your comment - thanks. I guess since I am using substreams I never even noticed since I wasn't having CPU issues. I've got a 2mp Dahua that doesn't show HA in the BI status, cameras tab so I'll work on that one but thanks for the heads up on HA and BI updates.
 

105437

BIT Beta Team
Joined
Jun 8, 2015
Messages
1,995
Reaction score
881
I've turned off HA since I'm running H265 on my cameras and my Dell OptiPlex 3010 doesn't seem to support it.
 

105437

BIT Beta Team
Joined
Jun 8, 2015
Messages
1,995
Reaction score
881
@wittaj... With 11 cameras, my CPU run around 25% at rest. Spikes a bit when cameras trigger.
 

wittaj

IPCT Contributor
Joined
Apr 28, 2019
Messages
24,430
Reaction score
47,552
Location
USA
I bounce back and forth LOL. My CPU also doesn't support H265. I found that H265 didn't result in much space savings (literally minutes over H264) and many of my cameras looked better with H264, so I am running a mix based on which one looked better. So HA on my H264s and not on H265s. Now the problem is when I start tinkering again and change an H264 to H265 and the camera blanks out in BI LOL.

Once BI is able to have it record substream until motion and then switch to mainstream with the prebuffer so we get mainstream before the motion, I will then move them all to H264.
 

looney2ns

IPCT Contributor
Joined
Sep 25, 2016
Messages
15,521
Reaction score
22,657
Location
Evansville, In. USA
I bounce back and forth LOL. My CPU also doesn't support H265. I found that H265 didn't result in much space savings (literally minutes over H264) and many of my cameras looked better with H264, so I am running a mix based on which one looked better. So HA on my H264s and not on H265s. Now the problem is when I start tinkering again and change an H264 to H265 and the camera blanks out in BI LOL.

Once BI is able to have it record substream until motion and then switch to mainstream with the prebuffer so we get mainstream before the motion, I will then move them all to H264.
Here going from h264, to h265, I went from 14 days storage to 19 days on a 4tb.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,005
Location
USA
I bounce back and forth LOL. My CPU also doesn't support H265. I found that H265 didn't result in much space savings (literally minutes over H264) and many of my cameras looked better with H264, so I am running a mix based on which one looked better. So HA on my H264s and not on H265s.
Video encoding is complex.

Ideally if you encoded the same exact scene using H.264 and H.265 both at the same bit rate, then H.265 would yield better quality. But if the H.265 encoder is poor quality (or just poorly tuned by the camera firmware), it could negate the difference or even give the advantage to H.264. It sounds like your cameras might have exactly this problem, which doesn't surprise me at all. I am not very impressed by the H.265 output from my Dahuas either. Unfortunately it is very difficult to objectively measure the quality lost by video compression when the source is an IP camera because you'll never have the raw input data to compare with compressed versions.

Storage requirements are literally just the video(+audio) bit rates multiplied by time. The video codec (H.264 or H.265) is only one piece of the puzzle that ultimately determines the bit rate and video quality.
 

spammenotinoz

Getting comfortable
Joined
Apr 4, 2019
Messages
345
Reaction score
274
Location
Sydney
Also whenever you change encoding on a cam you need to align both the main and sub-streams then either disable and re-enable the cam or restart the blue iris service(not GUI).
If you don’t disable/re-enable or restart then bi will have all sorts of issues.

Got to agree H.265 VBR is terrible on Dahua,
CBR is decent but makes no sense when you get far better quality for not much more space using H.264 VBR
 

105437

BIT Beta Team
Joined
Jun 8, 2015
Messages
1,995
Reaction score
881
Got to agree H.265 VBR is terrible on Dahua,
CBR is decent but makes no sense when you get far better quality for not much more space using H.264 VBR
I have 8 Dahua 5231s... I'm currently running them H.265 CBR. Sounds like I'd be better off running them H.264 VBR.
 

wittaj

IPCT Contributor
Joined
Apr 28, 2019
Messages
24,430
Reaction score
47,552
Location
USA
I have 8 Dahua 5231s... I'm currently running them H.265 CBR. Sounds like I'd be better off running them H.264 VBR.
I have found my Dahua's look better on H264. I would show two clips to several people (that wouldn't understand H264 and H265) and not tell them the differences and they all agreed the video that was H264 looked better.

Now with the ability to save substream and go to mainstream on trigger, this makes it even a more convincing reason to switch to H264 and CBR and maybe even up the bitrate.
 

105437

BIT Beta Team
Joined
Jun 8, 2015
Messages
1,995
Reaction score
881
I'm thinking about trying these settings on a couple of my cameras to see how it works out. I'm not sure about H.264H, is that a better option than regular H.264?

Screen Shot 2021-05-11 at 1.41.33 PM.png
 
Top