CPU usage went from 65-70% to 95-100% after upgrade to 4.09.12

[stephenspann27]

I am running 18 camera's from a beefy IBM server with 12 cores. I tried direct to disk recording but I was getting bad ghosting. What was working perfectly for me was using the blue iris container and re-encoding to xvid. That fixed the ghosting. Today, the only changes I made was applying the license and installing an update that brought me to 4.0.9.12. Since them the CPU has been pegged. I was on 4.0.5 prior to that. Is there a way I can roll back the update?

 

[fenderman]

I am running 18 camera's from a beefy IBM server with 12 cores. I tried direct to disk recording but I was getting bad ghosting. What was working perfectly for me was using the blue iris container and re-encoding to xvid. That fixed the ghosting. Today, the only changes I made was applying the license and installing an update that brought me to 4.0.9.12. Since them the CPU has been pegged. I was on 4.0.5 prior to that. Is there a way I can roll back the update?

Welcome to the forum...in the new updates the option for blue iris to reduce frame rates was removed from the video tab...first try and see if you can limit the frame rate in the camera itself. If not you can limit the frame rate in the record tab by choosing alternate frame rate...this is explained in the new release notes.
Finally, try direct to disc again, the new changes may have helped with the ghosting..

 

[ruppmeister]

Also, one more note is to try a simple reboot of your BI system. I know that helped me on some issues I had with the most recent build.

 

[fenderman]

Also, one more note is to try a simple reboot of your BI system. I know that helped me on some issues I had with the most recent build.

Sent via Taptalk

 

[ruppmeister]

LOL... "yea, but that's an important part of the process"

 

[fenderman]

Great show btw... It's available on Netflix.

Sent via Taptalk

 

[stephenspann27]

It looks like the update changed the frame rate on all my cameras from 10 to 30fps. That's probably the problem. Changing it now.

 

[stephenspann27]

If you guys aren't watching Silicon Valley on HBO I highly recommend it. Frame rate appears to have been the culprit, keeping an eye on it.

 

[bp2008]

When the camera was encoding 30 FPS and you had Blue Iris set to 10 FPS, you were only getting some of the CPU savings of using a lower frame rate. Once you set the lower frame rate in all the cameras web interfaces then you should see significantly lower CPU usage than you had in 4.0.5.

 

[stephenspann27]

Understood, I'm having trouble finding the FPS setting in the webUI of the camera.

 

[The_Penguin]

What kind of camera? Also tweaking the I frame setting can get rid of the ghosting with direct to disk.

 

[stephenspann27]

They are Vivotek cameras.

 

[The_Penguin]

Yeah, frame rate is hard to find on those. I think it's buried in the config somewhere in the stream settings.

 

[ruppmeister]

@The_Penguin is right I think for those cameras. Also, I think they call the I-Frame Intra Frame Period which should be the same thing as I-Frame.

 

[stephenspann27]

Finally found it! heh Advance mode/Media/Video, then set it per stream. I'm changing all the cameras now.

 

[stephenspann27]

I found that the camera's setting I set from 30 to 10 yesterday in Blue iris had reverted to 30. I guess Blue Iris is getting the setting from the camera now because of the update "fenderman" eluded to this above.

 

[stephenspann27]

CPU is down to 40% after reducing the frame rate on the camera side. Going to give D2D a second try as well.

 

[bp2008]

I guess Blue Iris is getting the setting from the camera now because of the update "fenderman" eluded to this above.

In a way, yes. The reasons for this are very technical and likely boring to you, but the takeaway point here is that Blue Iris never possessed the ability to change the frame rate of the h264 video encoded by a camera. Only the camera can control this. By setting a lower frame rate in Blue Iris, you were actually just telling Blue Iris to drop some of the frames. This resulted in partial CPU savings and for the most part had the intended effect. But it results in corruption in direct-to-disc recordings and BI still wastes CPU time because it has to decode all the frames it is sent regardless of what frame rate you told it to use.

I think it is a good thing that Ken is trying to fix this, I just think he could have done a better job of it. The frame rate setting should quite simply be hidden for camera types where it has no effect (h264 and mpeg4 cameras mostly) and it should stay for jpeg and mjpeg cameras and USB cameras where it has the intended effect.

 

[stephenspann27]

bp2008, excellent explanation, thank you

 

[stephenspann27]

Switched all cameras to D2D. Saved me another 5% CPU. I'm down to 35% CPU. I have 32 camera's total to eventually hook up. I'm running 18 right now on this single server. I should be able to get it done with two servers no problem.