The 'best' delay time is certainly gong to be specific to your camera recording settings, and your system.
The hard-coded
I've just experimented with using an even shorter delay of 5 seconds
The reason a delay is SOMETIMES needed is because when I asynchronously execute the HTTP commands to extract JPGs from the BVR associated with a just triggered new alert (examples shown below for a 10-frame GIF), sometimes the requested times are not yet available. When this happens, the command does not fail, but instead it seems to always return a JPG from the beginning of the BVR clip. I've found no obvious way to detect when this has happened so that I can re-request the 'bad' targeted JPG image. The resulting GIF will look 'jumpy' because some of the frames are from the beginning of the clip.
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3197430&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3198542&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3199654&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3200766&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3201878&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3202990&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3204102&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3205214&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3206326&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3207438&decode=-1&cache=1&h=320
I've just emailed Ken to once again request an HTTP command that can extract JPG images from the still-buffered video (before it’s written to the BVR file).
Ken previously said this was doable. Notably, Blue Iris already grabs JPGs from the buffer for AI processing (and, saves them to the DAT file, if configured). All of this apparently happens before the the alert is triggered, and the buffer is written to the BVR file. I'm pretty sure this is why using the DAT file always works.
Perhaps variations in the AI processing time are why the BVR-derived JPGs are sometime all available, and other times are not. Of course, this will not apply if the camera is not configured to use AI detection.
The hard-coded
2 * (pre-trigger record time) value is purely arbitrary. It seemed to work in my development testing for my camera settings, and was faster than my initial experiments using 1.1 * (alert duration time).I've just experimented with using an even shorter delay of 5 seconds
-BvrDelaMsec 5000) and results this time were identical to the default delay for my setup (2 * 5 seconds pre-trigger record time).The reason a delay is SOMETIMES needed is because when I asynchronously execute the HTTP commands to extract JPGs from the BVR associated with a just triggered new alert (examples shown below for a 10-frame GIF), sometimes the requested times are not yet available. When this happens, the command does not fail, but instead it seems to always return a JPG from the beginning of the BVR clip. I've found no obvious way to detect when this has happened so that I can re-request the 'bad' targeted JPG image. The resulting GIF will look 'jumpy' because some of the frames are from the beginning of the clip.
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3197430&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3198542&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3199654&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3200766&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3201878&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3202990&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3204102&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3205214&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3206326&decode=-1&cache=1&h=320
Initiated request for 192.168.1.3:8600/file/clips/@183592405.bvr?time=3207438&decode=-1&cache=1&h=320
I've just emailed Ken to once again request an HTTP command that can extract JPG images from the still-buffered video (before it’s written to the BVR file).
Ken previously said this was doable. Notably, Blue Iris already grabs JPGs from the buffer for AI processing (and, saves them to the DAT file, if configured). All of this apparently happens before the the alert is triggered, and the buffer is written to the BVR file. I'm pretty sure this is why using the DAT file always works.
Perhaps variations in the AI processing time are why the BVR-derived JPGs are sometime all available, and other times are not. Of course, this will not apply if the camera is not configured to use AI detection.
Last edited:
