Hell Yeah! Direct Deepstack Integration - 5.4.0 - March 31, 2021

Nope. Test it with a Hik or Dahua and see what happens... When the FPS and iframes match, the Key is 1.00

I just did mine right now:

When I make mine 15FPS and 15 iframes, the Key in Blue Iris is 1.00, so it reads 15/1.00
When I make mine 15 FPS and 30 iframes, the Key in Blue Iris is 0.50, so it reads 15/0.50
When I make mine 15 FPS and 60 iframes, the Key in Blue Iris is 0.25, so it reads 15/0.25

And then if I set a prebuffer time to 0 seconds - with 60iframes I miss the motion altogether....
wittaj, in this instance, I'm afraid your mind is closed to the facts. As you say, understanding the key frame interval is important so let me prove it in two simple ways:

1. Read the Blue Iris help file
key frames.png

2. A practical method.
Set one of your cameras once again to 15 fps and an iframe interval of 60. Then set the bitrate to the slowest possible such that there are not enough bits in a key frame to render a useable image. You will notice key frames occur every 4 seconds (every 60 frames).

With regard to missing motion, I'm assuming you're right. Logically, I would think this is for one of two reasons. Either (a) you are not recording continuously or (b) it's imperfections in the cameras' encoding capabilities. Surely, using all the available data to capture pixel changes per frame should be more secure than wasting them on static parts of the image? Here I may be wrong and I'm hoping that learned members of the forum will educate me with other specific technical factors that either I haven't considered or are simply beyond my knowledge. I'll do a test on one of my cameras.
 
  • Like
Reactions: beandip
wittaj, in this instance, I'm afraid your mind is closed to the facts. As you say, understanding the key frame interval is important so let me prove it in two simple ways:

1. Read the Blue Iris help file
View attachment 86070

2. A practical method.
Set one of your cameras once again to 15 fps and an iframe interval of 60. Then set the bitrate to the slowest possible such that there are not enough bits in a key frame to render a useable image. You will notice key frames occur every 4 seconds (every 60 frames).

With regard to missing motion, I'm assuming you're right. Logically, I would think this is for one of two reasons. Either (a) you are not recording continuously or (b) it's imperfections in the cameras' encoding capabilities. Surely, using all the available data to capture pixel changes per frame should be more secure than wasting them on static parts of the image? Here I may be wrong and I'm hoping that learned members of the forum will educate me with other specific technical factors that either I haven't considered or are simply beyond my knowledge. I'll do a test on one of my cameras.

Isn’t the what @wittaj did and say when he tested?

As far as I understand it what BI shows is the ratio of frames per second to iframes, so 15/0.25 would mean a key frame every 4 seconds which in itself is the issue due to the extended time between iframes. So in a situation like this motion would need to start and continue for at least the next 4 or even 8 seconds to be detected hence why events can be missed.
 
  • Like
Reactions: sebastiantombs
@Dave Lonsdale - you are now putting words in my mouth.....and you are not understanding how the KEY is calculated (although I think you understand the concept but approaching it in a different way)....

I am not disputing what the Blue Iris help file says in regards to the Key, nor have I ever said what the definition of an iframe is - I simply said that one should ideally have the KEY be a 1.00 and in my experiences (and the experiences of many here), the only way for that to happen is to have the FPS match the iframes in the camera settings...and this is confirmed in the help file in many different locations....and thus the higher the iframe number is from the FPS, the lower the Key number gets.

The Key is a ratio, so a camera set to 15FPS and 15 iframes is 15/15=1.00. And 15FPS and 30 iframes is 15/30=0.50 and 15FPS and 60 iframes is 15/60=0.25, etc....

I just tried your experiment and set my camera to 15FPS and iframes of 60, guess what ii showed a KEY of 0.25 regardless of whether I used the lowest 1536 bitrate or highest 20,480 bitrate....but like you said that is a key frame every 4 seconds (the invert of 0.25 is 4) - so in some camera views, the motion could completely gone in 4 seconds and thus Blue Iris doesn't pick it up as a motion....

Regarding missing motion - I am not missing motion because I am set to continuous and the few that I record on trigger I have my iframes match my FPS with a decent pre-buffer record. Prior to Deepstack Integration, those not recording continuously could still pick up most of the motion with a a larger pre-buffer record time regardless of the KEY number....

My example and intent was pointing out to folks with cameras where you cannot set iframes or the camera ignores it to give a nice static image, that motion will be missed if the KEY is below 0.5 and now with Deepstack integrated into Blue Iris, not even a larger pre-buffer will correct that....and I wanted to have this information in this thread as folks now trying the Deepstack integration with these types of cameras will not be reading all the issues folks had in the AI Tools thread or any of those other 3rd party add-ons...

From various pages of the help file:

The FPS is the number of Frames per Second on average currently being received from the
camera. The value that follows is the number of key frames per second. A key frame is a
complete frame—one that may be displayed without reference or dependence upon another
frame. These are sometimes called I-frames and define a GOP (group of pictures).
The key frame rate is an important consideration for multiple software functions. A key
frame rate of approximately 1.00 is desirable for optimal use of the direct-to-disc recording
option as well as the limit-decoding unless required functionality. Adjust this rate within the
camera’s web browser interface.

Direct-to-disc recording can only begin on a key frame boundary—if the rate is too low, this
means that video frames between a trigger event and the next key frame rate may be lost.

One way to compensate for this is to use pre-trigger time on the Record page.
When limit-decoding is being used, only key frames are decoded unless all video is required
for display or analysis. This means that only key frames are fed to the motion detector when
the camera is not triggered or selected for streaming or viewing. If the key frame rate is
much lower than 1.00, the motion detector may not operate effectively and events may be
missed.

A keyframe is a complete frame—one
that may be displayed without reference or dependence upon another frame. These are
sometimes called I-frames.

On the Cameras page in Status, you
should see a key frame rate of about 1.00 (this is the number after the FPS, like 15.0/1.00).
Anything lower than 0.50 is undesirable and should be remedied via settings in the camera’s
internal web interface.

It is recommended to have about 1 key frame/second coming from
the camera. This is a setting in the camera’s browser-based settings, usually under a “video
encoding” section. It may be labeled as “key frame rate” or “i-frame interval” for example.
You can view the actual rate on either the General page in camera settings, or on the
Cameras page in Status. It is shown after the overall frame rate—for example 15.0/1.0
indicates 15 fps with 1 key frame/second. A value of 0.5 or less is considered insufficient to
use this feature.
 
Last edited:
I'm still getting 100% cancellation rate on all 3 cams. The deepstack console seems to show it getting hits, so it looks like BI is communicating with it. I also tried letting BI run deepstack itself, but the same issue persists.
 

Attachments

  • Screenshot_20210404-112643_Microsoft Remote Desktop~2.jpg
    Screenshot_20210404-112643_Microsoft Remote Desktop~2.jpg
    271.8 KB · Views: 117
  • Screenshot_20210404-113252_Microsoft Remote Desktop.jpg
    Screenshot_20210404-113252_Microsoft Remote Desktop.jpg
    109.1 KB · Views: 125
  • Screenshot_20210404-113312_Microsoft Remote Desktop.jpg
    Screenshot_20210404-113312_Microsoft Remote Desktop.jpg
    85 KB · Views: 113
  • Screenshot_20210404-113320_Microsoft Remote Desktop.jpg
    Screenshot_20210404-113320_Microsoft Remote Desktop.jpg
    87.4 KB · Views: 105
  • Screenshot_20210404-113332_Microsoft Remote Desktop.jpg
    Screenshot_20210404-113332_Microsoft Remote Desktop.jpg
    102.6 KB · Views: 103
  • Like
Reactions: beandip
I'm still getting 100% cancellation rate on all 3 cams. The deepstack console seems to show it getting hits, so it looks like BI is communicating with it. I also tried letting BI run deepstack itself, but the same issue persists.
My settings are the same except for the "Additional real-time images to analyze (1 sec interval). I have it set to 1 and it's yet to miss an object (in the daytime that is...)
 
I had it set to 1 originally, but in the help file it was set higher, so I gave it a try.

My settings are the same except for the "Additional real-time images to analyze (1 sec interval). I have it set to 1 and it's yet to miss an object (in the daytime that is...)
 
Keep in mind those images happen at a one second interval. That can be self defeating if the motion is of short duration. I'm using 1 or 2 depending on the camera location and what I want detected. This is another case of how important it can be to have the iframe rate set the same as the frame rate since that insures a full frame every second and motion detection starts on an iframe.
 
  • Like
Reactions: tech101
Keep in mind those images happen at a one second interval. That can be self defeating if the motion is of short duration. I'm using 1 or 2 depending on the camera location and what I want detected. This is another case of how important it can be to have the iframe rate set the same as the frame rate since that insures a full frame every second and motion detection starts on an iframe.

My keyframe settings seem ok. 15 and 15

The duration of the motion is pretty long and clear since this is a city sidewalk. A lot of people walking by and they must pass the entire length of the house. Even people stopping in front of my doorbell don't get properly classified by deepstack.

I'm puzzled.
 

Attachments

  • Screenshot_20210404-120558_Microsoft Remote Desktop.jpg
    Screenshot_20210404-120558_Microsoft Remote Desktop.jpg
    125.2 KB · Views: 75
I had it set to 1 originally, but in the help file it was set higher, so I gave it a try.
You might also check your zone coverage. If you have it at the edges, it might not catch the object. I also have the min object size at 250 and contrast at 25 and min duration at .3

EDIT: Just saw you are on a sidewalk, I am too and this works for me.
 
  • Like
Reactions: tofu
You might also check your zone coverage. If you have it at the edges, it might not catch the object. I also have the min object size at 250 and contrast at 25 and min duration at .3

Worth a shot! I'll duplicate a cam and play with some zone settings
 
Uncheck the box in the camera AI that suppresses "unidentified" clips as well. Really easy to see what is detecting what rather than relying on the log.
 
Last edited:
  • Like
Reactions: Bosty
Bosty's troubleshooting did the trick.

I was unaware that it only analyzes the highlighted zone area. Since I only highlighted the sidewalk, and not the street, it was only catching legs and animal shapes distorted by my fence rails (which worked fine for pure motion detection). I unchecked "use zones and hotspots" and now I'm getting hits!

Thanks! That made my day.
 
@Dave Lonsdale - you are now putting words in my mouth.....and you are not understanding how the KEY is calculated (although I think you understand the concept but approaching it in a different way)....

I am not disputing what the Blue Iris help file says in regards to the Key, nor have I ever said what the definition of an iframe is - I simply said that one should ideally have the KEY be a 1.00 and in my experiences (and the experiences of many here), the only way for that to happen is to have the FPS match the iframes in the camera settings...and this is confirmed in the help file in many different locations....and thus the higher the iframe number is from the FPS, the lower the Key number gets.

The Key is a ratio, so a camera set to 15FPS and 15 iframes is 15/15=1.00. And 15FPS and 30 iframes is 15/30=0.50 and 15FPS and 60 iframes is 15/60=0.25, etc....

I just tried your experiment and set my camera to 15FPS and iframes of 60, guess what ii showed a KEY of 0.25 regardless of whether I used the lowest 1536 bitrate or highest 20,480 bitrate....but like you said that is a key frame every 4 seconds (the invert of 0.25 is 4) - so in some camera views, the motion could completely gone in 4 seconds and thus Blue Iris doesn't pick it up as a motion....

Regarding missing motion - I am not missing motion because I am set to continuous and the few that I record on trigger I have my iframes match my FPS with a decent pre-buffer record. Prior to Deepstack Integration, those not recording continuously could still pick up most of the motion with a a larger pre-buffer record time regardless of the KEY number....

My example and intent was pointing out to folks with cameras where you cannot set iframes or the camera ignores it to give a nice static image, that motion will be missed if the KEY is below 0.5 and now with Deepstack integrated into Blue Iris, not even a larger pre-buffer will correct that....and I wanted to have this information in this thread as folks now trying the Deepstack integration with these types of cameras will not be reading all the issues folks had in the AI Tools thread or any of those other 3rd party add-ons...

From various pages of the help file:

The FPS is the number of Frames per Second on average currently being received from the
camera. The value that follows is the number of key frames per second. A key frame is a
complete frame—one that may be displayed without reference or dependence upon another
frame. These are sometimes called I-frames and define a GOP (group of pictures).
The key frame rate is an important consideration for multiple software functions. A key
frame rate of approximately 1.00 is desirable for optimal use of the direct-to-disc recording
option as well as the limit-decoding unless required functionality. Adjust this rate within the
camera’s web browser interface.

Direct-to-disc recording can only begin on a key frame boundary—if the rate is too low, this
means that video frames between a trigger event and the next key frame rate may be lost.

One way to compensate for this is to use pre-trigger time on the Record page.
When limit-decoding is being used, only key frames are decoded unless all video is required
for display or analysis. This means that only key frames are fed to the motion detector when
the camera is not triggered or selected for streaming or viewing. If the key frame rate is
much lower than 1.00, the motion detector may not operate effectively and events may be
missed.

A keyframe is a complete frame—one
that may be displayed without reference or dependence upon another frame. These are
sometimes called I-frames.

On the Cameras page in Status, you
should see a key frame rate of about 1.00 (this is the number after the FPS, like 15.0/1.00).
Anything lower than 0.50 is undesirable and should be remedied via settings in the camera’s
internal web interface.

It is recommended to have about 1 key frame/second coming from
the camera. This is a setting in the camera’s browser-based settings, usually under a “video
encoding” section. It may be labeled as “key frame rate” or “i-frame interval” for example.
You can view the actual rate on either the General page in camera settings, or on the
Cameras page in Status. It is shown after the overall frame rate—for example 15.0/1.0
indicates 15 fps with 1 key frame/second. A value of 0.5 or less is considered insufficient to
use this feature.
Goodness gracious wittaj, I’m sorry to have prompted you into verbal diarrhoea! I see only now that our conversation on this point began because of my interpretation of you saying that fps and iframes should match. To me that’s ambiguous and I thought you meant that there should be as many iframes as p frames - expressing it, for example, “When I make mine 15FPS and 15 iframes...”. Couldn’t you see that when I clarified the definition and you still said “nope”? Anyway, I’m very pleased that we have a common understanding and, of course, I say again that I’m sorry for the misinterpretation.
 
@Dave Lonsdale - no problem LOL - at the end of the day you and I want people to understand what this means and the implications that some cameras will have by not being able to set these parameters.

It was a good discussion and I am sure others get easily confused about many of these settings, so this will hopefully add some clarity that we can point people to that come here and say their XYZ camera isn't working!
 
I've noticed alert actions fire noticeably slower, even with "fire 'on alert' actions only when confirmed" disabled. Used to be near instantaneous, but now takes several seconds
 
What's the red line for?
haha , Sorry for confusion it was to point out that the object was detected correctly within DeepStack as motorcycle after adding some more labels. It was an electric bike though but pretty close.
 
haha , Sorry for confusion it was to point out that the object was detected correctly within DeepStack as motorcycle after adding some more labels. It was an electric bike though but pretty close.
No confusion just curious if BI and deepstack did that line auto. I am doing lots of search on cameras now . Torn between which camera to go with. So many kinds and brands. What cameras you using? I also read edge solutions are more accurate due to the camera built with Ai analyzes the live video feed unlike deepstack it's anyalizisng a snap shot. Is this correct? I have tried very expensive ones already and it still has false alarms.