5.4.9 - June 25, 2021

[wittaj]

My post pulled from the Reolinks discussion to discuss how BI determines motion and the importance of the FPS/iframe ratio:

Blue Iris and Reolinks do not work well together, but the same principles applies for almost any low end consumer grade camera. It is just Reolinks is one of the more consumer end cameras people buy and come to this site as to why it is pointed out often about. I have a cheapo camera for overview purposes so it doesn't matter, but it exhibits this same behavior even though in the settings I can set an iframe...

This was a screenshot of a member here where they had set these cameras to 15FPS within the cameras (I suspect you will be missing motion that you do not know you are missing....):

Now look at they key - that is the iframes ratio. Blue Iris works best when the FPS and the iframes match. Now this is a ratio, so it should be a 1.00 if it matches the FPS. The iframes not matching (that you cannot fix or change with a reolink) is why they miss motion in Blue Iris and why people have problems. This is mainly why people are having issues with these cameras and there are many threads showing the issues people have with this manufacturer and Blue Iris. It is these same games that make the camera look great as a still image or video but turn to crap once motion is introduced.

The Blue Iris developer has indicated that for best reliability, sub stream frame rate should be equal to the main stream frame rate and these cameras cannot do that and there is nothing you can do about that with these cameras... The iframe rates (something these cameras do not allow you to set) should equal the FPS, but at worse case be no more than double. This example shows the cameras going down to a keyrate of 0.25 means that the iframe rates are over 4 times the FPS and that is why motion detection is a disaster with these cameras and Blue Iris...A value of 0.5 or less is considered insufficient to trust for motion triggers reliably...try to do DeepStack with those lower ratios and it will be useless...

Compounding the matter even worse...motion detection is based on the substream and look at the substream FPS - they dropped down to below 6 FPS with an iframe/key rate of 0.25 - you will miss motion most of the time with that issue...DeepStack probably won't work at all...

Now compare above to mine and cameras that follow industry standards that allow you to actually set parameters and they don't manipulate them. You will see that my FPS match what I set in the camera, and the 1.00 key means the iframe matches:

So the real question is why they would now say to go to a KEY of 0.5 - I suspect the reason is to not overwhelm DS because a KEY of 0.5 will send a picture once every two seconds instead of one per second.

And in doing that, it will make some field of views problematic. Some field of views the object can be in and out within two seconds.

 

[IAmATeaf]

A KEY of 0.5 means it sends a frame every 2 seconds instead of 1 second, so FPS/iframe of 20/40 or 10/20 is both a KEY of 0.5, just as FPS of 30 and iframe of 60 is.

Yes I know what it means but was simply wondering if Ken may have somehow meant to double the iframe rate.

 

[sebastiantombs]

Here's a copy and paste of the key frame comment in that email. I interpret it as a minimum key frame of .5 which surprised the hell out of me, too.

"Check on status/cameras you have at least 0.5 key frames/second"

 

[beepsilver]

Here's a copy and paste of the key frame comment in that email. I interpret it as a minimum key frame of .5 which surprised the hell out of me, too.

"Check on status/cameras you have at least 0.5 key frames/second"

That's also the recommended 'minimum' for direct-to-disc recording.

 

[Dave Lonsdale]

Hello guys. So far as I know, it was established that BI does not wait to send the next iframe to DS for analysis. And, we can now send images at a rate of 0.25 seconds. And, BI's triggered images look pretty good to me. So why does it matter what the iframe rate is? Infinitesimal artefacts? I don't think DS cares about them. So wittaj, is your statement condemning an iframe interval of several seconds valid. My memory isn't what it used to be but I thought that when I tried 10 seconds it made diddly squat difference. Assuming you're using 'continuous + triggered', could I encourage you to try that out too please?

My DS is working well nearly all the time but cancels a few that I want confirmed. But, I mentioned that my memory is crap. Could someone remind me please why these were these cancelled:-





Both use 'T+0' image when the object was centre screen. The objects were not stationary and there is not a confirmed trigger close to the blue occupied rectangle.

By the way, I use 720p and 2048kbit/s for all of my camera substreams. My view is that this is delivers a better result. With a total of 17500kB/s, 180MP/s and quiescent CPU of 6%, I still get 9 days storage.

 

[beepsilver]

Dave, for the bicycle trigger two frames were analyzed. It looks like DS got a good look at the bicycle, but needed another frame to confirm. But when the second frame was analyzed both the person and the bicycle did not overlap the active motion within your motion zone....or at least, that's what the analysis appears to indicate. Do you have one zone out there on the street or multiple zones with a obj detection rule, i.e. A-B? If not, I suspect you'd benefit from .25 frame intervals for fast movers.

The car analysis is more challenging because according to the second frame, DS treated the car as a static object. Speculation, but since you have a fast mover out there, the odds are there wasn't enough information for analysis...rubbish of course, but it seems to me this wasn't an operator error, more likely software needing some tweaks.

It's worth noting that if there is any motion within your motion zone prior to valid triggers entering the zone (such as shimmering light through the trees, moving shadows, moving leaves, swaying branches, bugs in front of the lens, etc.) BI will sense a trigger, activate DS analysis and cancel the invalid alert. Depending on your break time, if a valid trigger passes through your motion zone after the cancelled alert but before the break time ends, it'll be missed. Best we all keep this in mind for our motion setups. The best chance of capturing every valid alert on the street in front of your drive would likely be with a single zone, with a somewhat low contrast, no distance travel or size thresholds, short break time and frame analysis beginning with the leading edge and additional frames set at .25 or .5 second intervals. This sets you up for the fastest objects like cars/bicycles. Slower traffic will also be captured with this setup, but you'll need to add several more frames for analysis--otherwise analysis could complete and not capture a slow moving trigger. I'd still expect some missed alerts on the road in this confined space with fast traffic (especially at night), but you shouldn't miss anything entering your driveway.

Break times for most of my cameras used to be set at 30 seconds so triggers wouldn't time out and cause missed video, but at this point with DS timing, I've had to shorten my break times to get a second or third chance at capturing valid triggers.

 

[Dave Lonsdale]

Brilliant feedback beepsilver - thank you. I have tried a great many different settings but on different versions of the software. It’s a little late here in the UK now, I’ll try and make sense of where I am tomorrow.

I have tried both single and multiple motion zones and 5x 0.25s frames for analysis but tend to fall into the trap of changing several things at the same time to get quicker results. My search for a ”one size fits all” settings combination hasn’t quite worked out so far but you’re pointing me in the right direction. Thanks.

 

[kklee]

I find it interesting that people are experiencing wildly different results with DS.

As an experiment, I disabled custom models (I was using the dark model). I changed the DS trigger configuration to 500ms and 3 images. Running 5.4.9.4.

In addition, I reconfigured my deck camera (which was throwing most of the Deepstack errors and occasionally identifying my covered barbeque as people), I also removed the confirmation requirement, ie, any DS object detected would trigger an alert.

I'm getting fewer Deepstack errors for this camera now. DS seems to be really confused by the barbeque, it's also been identified as an umbrella and a train. Not sure why it's not being ignored since it's a static object, I confirmed that Detect/ignore static object is enabled. Maybe shadows as play here, I might try masking out part of it to see if I can get BI to ignore it.

 

[sebastiantombs]

I think the iframe thing is because of the wayBI works and is not, necessarily, directly related to DS. This is only speculative, but I would say that the motion detection on BI is based off the iframes, the actual trigger event.

If we've got to disable the features that make DS worth running, like models, DS confirmed alerts. there is no real gain from running DS. I can easily differentiate between a car, truck person, bicycle, horse, dog, cat, train and barbeque without running DS. I'll also speculate that you're seeing those "trains" and "people" when you run "tuning, @kklee .

 

[kklee]

In my case, I have BI/DS configured so that specific cameras generate a push alert to my phone when DS reports a person. The dark model helped to improve people detection for people dressed in dark clothing or at night.

Being an IT nerd, I like playing with BI/DS object detection on cameras where I don't have push alerts configured, such as a high traffic alley next to my house.

@sebastiontombs, yes, the tuning playback does indeed show all kinds of objects being detected. I got a chuckle when my wife was detected as both a cat and a dog, and I was detected as a bear once!

Overall, DS has been more reliable than Sentry AI, and free! So I can't really complain.

 

[beepsilver]

DS has been fantastic for eliminating false alerts, but the major problem I have with it are missed alerts when something else is going on in the FOV. Here in Nebraska all manner of fireworks are legal in residential neighborhoods prior to, during and after the Independence day holiday, with the majority of big bangs on Friday and Saturday nights. Last night was no exception, bright, colorful aerial blasts continued non-stop until around midnight when fireworks are no longer permitted to be set off. During this time, I'd challenge just about any BI/DS-configured camera to capture and record an actual alert. Triggers were non-stop on all outdoor cameras and while BI/DS processed each one, most if not all actual alerts were missed.

 

[Dave Lonsdale]

Dave, for the bicycle trigger two frames were analyzed. It looks like DS got a good look at the bicycle, but needed another frame to confirm. But when the second frame was analyzed both the person and the bicycle did not overlap the active motion within your motion zone....or at least, that's what the analysis appears to indicate. Do you have one zone out there on the street or multiple zones with a obj detection rule, i.e. A-B? If not, I suspect you'd benefit from .25 frame intervals for fast movers.

The car analysis is more challenging because according to the second frame, DS treated the car as a static object. Speculation, but since you have a fast mover out there, the odds are there wasn't enough information for analysis...rubbish of course, but it seems to me this wasn't an operator error, more likely software needing some tweaks.

It's worth noting that if there is any motion within your motion zone prior to valid triggers entering the zone (such as shimmering light through the trees, moving shadows, moving leaves, swaying branches, bugs in front of the lens, etc.) BI will sense a trigger, activate DS analysis and cancel the invalid alert. Depending on your break time, if a valid trigger passes through your motion zone after the cancelled alert but before the break time ends, it'll be missed. Best we all keep this in mind for our motion setups. The best chance of capturing every valid alert on the street in front of your drive would likely be with a single zone, with a somewhat low contrast, no distance travel or size thresholds, short break time and frame analysis beginning with the leading edge and additional frames set at .25 or .5 second intervals. This sets you up for the fastest objects like cars/bicycles. Slower traffic will also be captured with this setup, but you'll need to add several more frames for analysis--otherwise analysis could complete and not capture a slow moving trigger. I'd still expect some missed alerts on the road in this confined space with fast traffic (especially at night), but you shouldn't miss anything entering your driveway.

Break times for most of my cameras used to be set at 30 seconds so triggers wouldn't time out and cause missed video, but at this point with DS timing, I've had to shorten my break times to get a second or third chance at capturing valid triggers.

I discovered one or two things that maybe you guys already knew but perhaps not:
1. If you uncheck the Pre-trigger video buffer, the first image that BI sends to DS for analysis is at T+0 instead of T-xxx
2. DS always chooses the image with the highest confidence percentage, even when they have clocks or blue/yellow icons and ignore those with green ticks
3. If the second and subsequent images sent to DS includes other motion (eg moving trees), it appears that the alert is cancelled, even when the wanted moving object has the highest confidence percentage. BI also identifies this spurious motion with yellow rectangles, even when it's only in zone A (full field of view) and not in the multiple motion trigger zones B-C, C-D etc.

Today (drive camera), 146 correctly confirmed, 6 cancelled (occupied valid moving objects), 5 cancelled (no valid object)
I used the settings 0s video buffer and 5 x 0.25s analysis intervals. Maybe only 2 x 0.25s would be even better.

It looks like I didn't persuade wittaj to try a 10s iframe interval to break his love affair with key frames. I'll do this again tomorrow to finally decide if a) sebastiontombs belief that BI triggers only start on a key frame is correct and b) wittaj is correct that it kills valid triggers. With a 1 second interval, I don't think anything is completely missed. At the moment nearly all are correctly confirmed and the rest correctly cancelled (see previous para).

 

[sebastiantombs]

My belief regarding the key frame being the start of the capture is based on a post I read that quoted Ken saying that very thing. Don't ask me which thread because that I can't remember. Maybe @fenderman can shed a little light on that aspect, IE trigger staring on a key frame.

 

[105437]

Testing 5.4.9.4 and I'm noticing a very slow, steady memory creep by BI. When I first launch, it's using ~1,400 MB. After an hour or so, it's up to ~2,000 MB and keeps climbing each hour. I'm running local DS without custom models. Anyone else seeing this? Thanks!

 

[beepsilver]

Testing 5.4.9.4 and I'm noticing a very slow, steady memory creep by BI. When I first launch, it's using ~1,400 MB. After an hour or so, it's up to ~2,000 MB and keeps climbing each hour. I'm running local DS without custom models. Anyone else seeing this? Thanks!

I'm on 5494 and not seeing any increases in memory over time. If you're using Windows 10, read up on display drivers and memory leaks here: Memory Leak: Quick Sync (Hardware Acceleration)

 

[105437]

I'm on 5494 and not seeing any increases in memory over time. If you're using Windows 10, read up on display drivers and memory leaks here: Memory Leak: Quick Sync (Hardware Acceleration)

I'm currently running 10.18.10.5059. I downloaded the known good version from the link you provided but I don't have the option to install the .cab file when I right-click on it.

EDIT: I found the driver elsewhere and was able to get it installed. I'll see how memory does moving forward. I appreciate the link to the driver discussion.

 

[105437]

I'm currently running 10.18.10.5059. I downloaded the known good version from the link you provided but I don't have the option to install the .cab file when I right-click on it.

EDIT: I found the driver elsewhere and was able to get it installed. I'll see how memory does moving forward. I appreciate the link to the driver discussion.

So far, so good. BI is holding steady right at 1.4 GB.

 

[Dave Lonsdale]

My belief regarding the key frame being the start of the capture is based on a post I read that quoted Ken saying that very thing. Don't ask me which thread because that I can't remember. Maybe @fenderman can shed a little light on that aspect, IE trigger staring on a key frame.

OK, so after a day with an iframe interval of 10 seconds (150, frame rate 15fps), I had 108 correctly confirmed, 5 cancelled because they were occupied, 7correctly cancelled (wind and sun through the trees) and 1 false confirmation. The 108 + 5 moving objects correlates well with the IVS triggers stored on the camera's memory card but I didn't check every one. Nevertheless, it is unrealistic to believe that the start of capture was an iframe.

However, a few points to note:
1. Many of the DS analysis images I examined using the .dat files used the 720p substream and not the 4MP main stream. Why?
2. Turns out I'm wrong, DS selected some images with the asterisk that was not the highest percentage.
3. I can't make sense of why DS uses some images.
4. BI doesn't send highlighted images to DS does it? Example - one of today's cancellations - an early morning jogger's image ruined by the highlight. And, notice it's only 720p. But he didn't stop and at 88% why was it cancelled?

 

[beepsilver]

OK, so after a day with an iframe interval of 10 seconds (150, frame rate 15fps), I had 108 correctly confirmed, 5 cancelled because they were occupied, 7correctly cancelled (wind and sun through the trees) and 1 false confirmation. The 108 + 5 moving objects correlates well with the IVS triggers stored on the camera's memory card but I didn't check every one. Nevertheless, it is unrealistic to believe that the start of capture was an iframe.

However, a few points to note:
1. Many of the DS analysis images I examined using the .dat files used the 720p substream and not the 4MP main stream. Why?
2. Turns out I'm wrong, DS selected some images with the asterisk that was not the highest percentage.
3. I can't make sense of why DS uses some images.
4. BI doesn't send highlighted images to DS does it? Example - one of today's cancellations - an early morning jogger's image ruined by the highlight. And, notice it's only 720p. But he didn't stop and at 88% why was it cancelled?

Dave, You've made some excellent observations and posed some key questions I think. Will you be sending a summary to Ken?

 

[kc8tmv]

2. Turns out I'm wrong, DS selected some images with the asterisk that was not the highest percentage.

Can't speak for the other (GREAT) questions / observations, but this one I agree I have seen a lot.