5.5.8.2 Update and H/A decoding

kferrero

Getting the hang of it
Apr 4, 2022
26
25
TN
Figured I'd post this in case anyone else has a similar issue.

After updating to 5.5.8.1 I started having issues with FPS drops when live viewing cameras in UI3, also affected recordings. Motion recordings when played back would be extremely jerky, video would freeze, then speed up a few seconds to catch up, like rubber banding. Recordings would also get ghosting where motion was happening in the video.

Recordings recorded prior to updating to 5.5.8.1 play back no problem, it's just recordings saved while running 5.5.8.1 or 5.5.8.2.

My set up has been working perfectly with BI5, DeepStack GPU, Intel H/A, etc for a few months and this issue just started with 5.5.8.1 and then continued with 5.5.8.2. I am using direct-to-disk recording, and sub-streams.

Tried troubleshooting as best as I can, the only thing that appeared to stop the problem was disabling H/A entirely which I'd prefer to not do when I have CPU capable of reducing CPU usage by offloading decoding. I even went so far as to delete all of my cameras and set them all back up as brand new, issue persisted. It appears to happen the worst when deepstack is receiving motion images from BI and churning through them on my nvidia T400. When theres no motion, live view is smooth and normal but gets choppy, rubberbandy, and unusable as soon as motion begins and BI starts sending data to DeepStack. In UI3 you can see the FPS bar drop and fluctuate wildly when motion starts happening in live view. I'm curious if it's something to do with the new SenseAI code added to the 5.5.8.1 and 5.5.8.2 update that's interfering with DeepStack. Or maybe I'm just an idiot and missed a changelog message where I'm not supposed to install 5.5.8.1 unless I'm using SenseAI.

Either way, rolling back to 5.5.7.11 solved the issue. Hope it helps
 
Last edited:
  • Like
Reactions: fenderman
Ever since Deepstack was introduced, we have seen some people experience problems with HA.

Keep in mind that in many cases, the CPU% needed to offload the video to the GPU is higher than the CPU% saved.

With the substrates feature, HA is not needed anymore. It doesn't even show up in the optimization wiki anymore.

It is recommended not to use HA as it will make the system unstable at some point.
 
I am certainly not an expert but for my edification, logically I don't understand how that is possible. If an Intel i-series CPU has a purpose built sub-processor for decoding of h.264, how would that use more CPU% or not be more efficient than using the general processing unit?

I also run a Plex server and QuickSync is orders of magnitude faster at re-encoding movies I download to h.264 than just CPU conversion.

I do believe you that HA does introduce instability, I've noticed it. My post here is not argumentative, purely for my own learning.
 
Last edited:
It doesn't simply offload the video to the GPU without some CPU processing needed.

Before substreams were introduced, HA was needed because it was using mainstream video and would choke a CPU, so it needed to be offloaded and the CPU savings to do so was tremendous, but not as great as going to substreams can do.

Substreams use so little CPU% that the CPU uses more CPU% to send the video to the GPU and let it process it and then CPU% to bring it back so it takes more CPU% to offload it than the savings it produces.

Try it and see. Most of us have since turned off HA and see no difference or slight decrease in CPU with HA turned off if you are using substreams. Once you are above about 14 cameras, the CPU usage will be lower without it.

I have well over 14 cameras and my video actually got better not offloading it. I would occasionally see a jitter and not now. Pushing too much bandwidth to the internal GPU was causing problems.

And like I said, we have posts like yours all the time where someone updates and now the system is unstable and turning off HA fixes it.

Some still don't have a problem, but eventually it will result in a problem.
 
Here is a sampling of recent threads that turning off HA fixed....




 
Keep in mind that in many cases, the CPU% needed to offload the video to the GPU is higher than the CPU% saved.


My live view cpu usage is 70%+ with HA disabled, which is odd because I thought only the "webserver" streaming profile would matter in this situation. With HA enabled, I'm down to 35-40%cpu @ 1080p 2048bitrate 10fps
 
My live view cpu usage is 70%+ with HA disabled, which is odd because I thought only the "webserver" streaming profile would matter in this situation. With HA enabled, I'm down to 35-40%cpu @ 1080p 2048bitrate 10fps
Are you using subsreams?


Do everything in this: Optimizing Blue Iris's CPU Usage
 
  • Like
Reactions: sebastiantombs
Are you using subsreams?


Do everything in this: Optimizing Blue Iris's CPU Usage

It's not an issue -- I'm just saying cpu usage with live view is much higher when HA is disabled. It has nothing to do with substreams, as they aren't used during live viewing. Otherwise, cpu chugs along fine at 4-9% if no one is viewing the cams from the TV or phone
 
Substreams are used during live view of multi cameras.

But something still isn't right. Mine does not jump that drastic if I solo a single cam for mainstream
 
Substreams are used during live view of multi cameras.

But something still isn't right. Mine does not jump that drastic if I solo a single cam for mainstream

Not in my use case. Tinycam streams all cams at full res while in preview mode. Like I said -- it's not an issue :)
 
I get that, but your use case adds tinycam to the mix that most do not use with BI and instead use UI3 or the BI app and we do not experience the spikes you have.

Hopefully in your use case BI doesn't get wonky at some point that would require HA be turned off.
 
I get that, but your use case adds tinycam to the mix that most do not use with BI and instead use UI3 or the BI app and we do not experience the spikes you have.

Hopefully in your use case BI doesn't get wonky at some point that would require HA be turned off.
I hope so, too, but the CPU spike applies to pretty much any client (aside from ui3 or the official mobile app) that pulls the live BI stream. I'd wager to say A LOT of people are using these streams for home automation or remote view -- most especially on wall mounted tablets and TV viewing.

Ain't complainin', but just sayin'...