thomas2013
Young grasshopper
I have the same problem. My Stats for nerds shows Video Bit Rate in the low Kbps. Any word from BI support?
Blue Iris UI3
- Thread starter bp2008
- Start date
Nope, I haven't heard from BI support on anything in several days. He'll get to it eventually, I imagine 
Sybertiger
Known around here
@bp2008 I checked the BVR settings on all the cams and they are unchecked which I also assume to be the default setting. I also checked if other cams were exhibiting this issue and the several I check do in fact sometimes snap the pic 1/2 second off of actual displayed image. The problem doesn't not reveal itself 100% of the time but it's not 1% of the time either. If a video playback is paused whatever gizmo software that handles taking a snapshot is not in sync with what is being displayed in UI3. Maybe this is a BI issue not UI3?
@Sybertiger I really don't know. Some other things to look at would be whether you used the "Combine or cut" feature, and if you are viewing the Alerts tab or the Clips tab in UI3. The format of your recordings could also have an effect -- I know Blue Iris has had a lot of trouble with the MP4 format.
I know it is a crappy workaround, but if you use one of the Jpeg streaming methods, then your downloaded snapshots should be correct 100% of the time because they both use the same timing mechanisms. A jpeg stream is literally just a sequence of snapshots being individually requested and displayed in the video player. UI3 has complete control over the timing and playback rate of a jpeg streaming method.
I know it is a crappy workaround, but if you use one of the Jpeg streaming methods, then your downloaded snapshots should be correct 100% of the time because they both use the same timing mechanisms. A jpeg stream is literally just a sequence of snapshots being individually requested and displayed in the video player. UI3 has complete control over the timing and playback rate of a jpeg streaming method.
Last edited:
I've tested some more and I can indeed get it to be a frame or two different between the paused H.264 stream and the snapshot, sometimes. It isn't wrong by nearly a whole second though. It does affect both the HTML5 player and the JavaScript player.
It might be explained by a little quirk I've always been aware of when using H.264 clip playback in Blue Iris. When you are watching a clip and you pause and play again, and you are using H.264 streaming, Blue Iris tends to start actual playback a little bit before the timestamp that UI3 requested. There's also the issue that Blue Iris prefers to handle H.264 seeking and timestamps by using a percentage with precision to 2 decimal places. But jpeg seeking is always done with milliseconds. So UI3 needs to convert between these and rounding error can be a concern especially with long clips. It is hard to get things like this exactly right when I can only see UI3's side of the puzzle.
It might be explained by a little quirk I've always been aware of when using H.264 clip playback in Blue Iris. When you are watching a clip and you pause and play again, and you are using H.264 streaming, Blue Iris tends to start actual playback a little bit before the timestamp that UI3 requested. There's also the issue that Blue Iris prefers to handle H.264 seeking and timestamps by using a percentage with precision to 2 decimal places. But jpeg seeking is always done with milliseconds. So UI3 needs to convert between these and rounding error can be a concern especially with long clips. It is hard to get things like this exactly right when I can only see UI3's side of the puzzle.
Sybertiger
Known around here
@bp2008 any chance you can interface with Ken to see if there's any chance for a solution? When you are talking still shots as "evidence" of an event it forces us to review the still shot immediately and not trust that the "take snapshot" button is taking a picture of what we're seeing on the computer screen. I've taken several shots then exited UI3 then attached the pics to an email I was writting only to find out they aren't what I intended to email. Hopefully, Ken will allow you access to the magic inside of BI.
Sorry, I don't have the time right now to get my mind deep into the video processing and timing code again, and it is always a bit painful coordinating things with Ken because he is in a constant state of overwhelming email support. He hasn't responded to any of my emails about the latest BI patches this week.
Sybertiger
Known around here
@bp2008 Appreciate your time and acknowledge I haven't given you a dime for your time. Might we document this a a bug...maybe it'll get on his radar. And, how would it get described?
I'll add it to the todo list that exists within the UI3 source code
I'll need to devote quite a bit of time on my end before I even bring it up to Ken.
I'll need to devote quite a bit of time on my end before I even bring it up to Ken.
Sybertiger
Known around here
I'll add it to the todo list that exists within the UI3 source code
I'll need to devote quite a bit of time on my end before I even bring it up to Ken.
I'm sorry to be making work for you. I do appreciate your time and help.
Just for funnies...this one is way off by a lot of time. Interesting that the timestamp of the file is correct but doesn't match the snapshot time in the lower right corner... by a mile....maybe litterally...23 seconds later all we see are tire tracks in the grass.
Sybertiger
Known around here
Yes, that is correct. I pause the video shown in the first pic. I click the "snap shot" button and the image save is the second pic but the timestamp on the saved file is 2020-04-16 04.24.02.780 PM but the saved image shows 04:24:25 PM in the image.
That is quite a time difference. Is that a continuous recording or motion triggered? What is your "combine or cut" set to for that cam?
Sybertiger
Known around here
Yes, continuous recording. My observation is that maybe half the time the image snapped might be 1/2 to 1 second off while the rest of the time it appears spot on...and this is the one weirdest anomaly I've observed.
Can you consistently reproduce this failure at that spot in the video?
Note that internal behavior can be different depending on whether or not any H.264 video has played since the last time you seeked. Seeking actually loads jpeg frames, not H.264, and only an H.264 stream provides a timestamp with each frame. It is complicated stuff ... anyway it matters.
Note that internal behavior can be different depending on whether or not any H.264 video has played since the last time you seeked. Seeking actually loads jpeg frames, not H.264, and only an H.264 stream provides a timestamp with each frame. It is complicated stuff ... anyway it matters.
Just a thought, perhaps when downloading a frame I could separately request a thumbnail of the exact same jpeg frame and briefly show it on-screen. Maybe in a toast message. So you could see exactly which frame it was. Of course it would be better to figure out why it is wrong in the first place and fix that.
Sybertiger
Known around here
I can reproduce it. In fact, I just did the same thing but several seconds earlier in the video and the result is a whopping 2 minutes off...MINUTES not seconds. So weird. I simply hit the pause button on UI3 then click the snap-shot button. I'm not doing a freeze/unfreeze or rewind/fast forward....a straight pause while the video is playing.
At least that tells me there's more to it than just a few frames maybe getting dropped when pausing.
The timestamps Blue Iris provides with each H.264 frame only provide precision of about 0.36 seconds for a 1 hour clip (because the timestamps are integers from 0 to 10000, and 1 hour divided by 10000 is 0.36 seconds). So rounding error can't account for that much difference either.
Well it is a shame Blue Iris does not have a decent way to ingest someone else's clip for web server streaming because I might be able to figure something out with that one. Big errors like 20 seconds or 2 minutes are a lot easier to hunt down than tiny ones like a half second.
If you PM me login details for your server (It doesn't need to be an admin account, and you can limit me to just that one camera, that would be fine), I can log in and debug and try to play / snapshot that clip through UI3 myself and see if I can identify a problem. If this sounds like a good idea to you, then I suggest you flag and protect that clip so it doesn't get cleared out automatically.
The timestamps Blue Iris provides with each H.264 frame only provide precision of about 0.36 seconds for a 1 hour clip (because the timestamps are integers from 0 to 10000, and 1 hour divided by 10000 is 0.36 seconds). So rounding error can't account for that much difference either.
Well it is a shame Blue Iris does not have a decent way to ingest someone else's clip for web server streaming because I might be able to figure something out with that one. Big errors like 20 seconds or 2 minutes are a lot easier to hunt down than tiny ones like a half second.
If you PM me login details for your server (It doesn't need to be an admin account, and you can limit me to just that one camera, that would be fine), I can log in and debug and try to play / snapshot that clip through UI3 myself and see if I can identify a problem. If this sounds like a good idea to you, then I suggest you flag and protect that clip so it doesn't get cleared out automatically.
Sybertiger
Known around here
If your router supports forwarding a port only for a specific source IP address, I could give you my public IP and you could set it up that way.
Hey Sybertiger, last night as I was going to bed I had another realization. If you are trying to download from a clip that is still actively recording, then the continuously changing length could be what causes the drastic differences of multiple seconds and longer. (because UI3 doesn't know the length is changing, so its position calculation gets increasingly less accurate)