What's with the "Predator" image problem...?

[JMartin]

Recently several (not all) of my cameras recordings have been creating a Predator effect (like in the movie).
It has been since the BI upgrade that takes advantage of Hardware Acceleration (if that has any bearing).
I have turned all HA off in all cameras, yet it still exists (this is a print-screen capture while watching a playback of my daughter walking in from her car):



All cams recording direct-to-disc, DVR format. Recording Motion Only.
All cams main stream set to 15 FPS and iFrames set to match.
All cams secondary stream set to 10 FPS and iFrames set to match.
Cameras are pumping out between 400 and 500 kBps consistently.
CPU is at 27-30% usage typically, no spikes, no warnings.
5 of six cams are direct wired, one is wireless (the one from this capture; but another barrel cam is doing this also and it is hardwired).
Windows 10 and Blue Iris 4.3.3.2 x64

Any idea where to look to solve this?

Thanx in advance,
Jim

 

[JMartin]

Anyone?
Any thoughts?

 

[nayr]

Frames are begin dropped, and one of the frames is the iFrame, thats WiFi so its easy to guess why frames are being dropped.. your other one could be poor cabling, or simply configured poorly so its overloaded.

With HD encoding (h264/h265) it works like this, each frame is the DIFF of the frame before it.. the frame only contains what changed from the frame before, and they build like this.. the iframe is a complete picture/reset that includes the entire image.. then all the frames until the next iframe have to just build on that.

when frames get dropped, the diff wont be applied to the frame it was compared to, since that frame never arrived.. but it tries, and this corrupts the image until the next iFrame comes down the pipe and resets it.

 

[JMartin]

That is a perfect explanation, thank you.

I understand the "wireless" issue and the dropped frames, but the hardwired one doesn't make sense... it's configured the same as another identical hardwired camera at a much greater distance that never skips a beat. On top of that, I have two interior cams that are both wired with Powerline Adapters and I would expect to have issues there... but I don't.

Weird.

Sounds like I've got to string some more Cat5 next weekend.

 

[nayr]

try bringing the camera inside and plugging it right into the switch, removing the existing cabling from the equation and see if that fixes it.

if that run is running along any high power lines or got damaged durring install it can cause problems.. you might open a continuos ping to that device and see if you encounter any packet loss over a 24h period or so.

 

[JMartin]

OOOoooo... I like the ping idea. Hadn't thought of that.

To that hardwired camera, it's only about a 30' run through open attic space, straight to the router.
Shouldn't really have any interference. And it never did this before the latest BI update.
Would the use of Hardware Acceleration effect this in any way? I have since turned it off, just to rule it out.

 

[nayr]

yeah potentially, it could be anything between the two devices.. including the devices them selves.

Do your recordings direct2disk show this? that should just be saving the stream directly w/out modifying it.. that would make me suspect it was external to BI, but it could also be a hardware issue with the BI Server.

 

[JMartin]

I assume what I am watching when I play a "clip" in BI is the recording from "direct-to-disc," am I not? (since each camera is configured that way)

 

[nayr]

yeah, BI is just showing you what its getting more than likely.. and if its getting dropped frames it'll show that, your BI server does not seem to be overloaded so its hard to come up with a reason why its dropping frames when it has so much free overhead..

this is going to require a troubleshooting strategy to isolate the issue, continous ping is a good first start.. if your dropping packets you know its external on the network.. if that comes back okay, no packet loss at all then we'll turn our focus to BlueIris.. can also try moving the trouble camera onto a bench test, just run it on a bench with a good pre-fab cable and see if the issue follows it.. if it does you have ruled out the network/cabling and its either the camera or the nvr.. if the cameras run perfectly fine on the bench then cut the ends off your cable and remake them.. and if that dont fix it, replace the entire run.

 

[fenderman]

Try increasing the receive buffer to the max 20mb, also if the camera has several flavors of h.264 to choose from, try each..

 

[JMartin]

Re: What's with the "Predator" image problem...?

Great strategy... I'll work it one test at a time.
Ping test tonight when I get home. (Or... come to think of it... I can remote access from here and fire off a Ping window).

Thanx for your help nyar, you are a wealth of information and experience.

Jim

- - - Updated - - -

Try increasing the receive buffer to the max 20mb, also if the camera has several flavors of h.264 to choose from, try each..

I think I have them at 20, but I'll check.
Thanx.

 

[bp2008]

If your cameras offer rtsp streaming by UDP or TCP, set them to TCP. The TCP protocol includes error detection and correction, so if your problems are coming from data loss, that might help.

 

[pozzello]

also, what's your DNR set at in the cam(s)? Noise Reduction settings too high can cause that effect.

 

[JMartin]

Just for kicks, I logged into my BI Server remotely, opened a CMD window and fired off a non-stop Ping to the wired camera in question... let it go for a while, and it never missed a beat, less than one millisecond every time. No packet loss.

I'll check these other suggestions too.