Blue Iris UI3

@bp2008 That's a good point. I'll have to recheck later to see if I was working with a cut that was still recording at the time because I may have. The other problems where I was getting a snapshot that was off by 1/2 to 1 second were definitely cut and saved recordings.
 
I still think at the end of the day that likely to make that snap shot button work the way people are thinking it works something would need to be done
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)

@bp2008 You may be right. I have not been able to reproduce the problem with that clip from two days ago...at least not with huge gaps in time. AND, I have been able to reproduce the problem with huge gaps on cuts that are actively being recorded. Based on this you should be able to reproduce it without accessing my system. I clearly don't know how that snapshot feature is implemented but it appears based on what you've described that UI3 has to query BI to get the snap-shot image. I would have thought that UI3 would get the image the same image showing in the browser. But, the image by then is probably local to the computer's frame buffer and UI3 cannot access it since UI3 isn't local on the computer.
 
I probably can actually get the snapshot directly from the video player, but it won't be as good of quality as requesting it separately from Blue Iris as is done now.

Sounds like you'll be talking to Ken about this. The problem now is there's kind of an asterisk next to the snapshot button...

* Snaps a picture close to the image being view unless it's from a clip that still being recorded. (I notice that usually the snapshot from my saved 1 hour clips are taken about 1/2 second before what is viewed).

Much appreciate your effort on this project...you deserve a lot of praise rather than complaints...hope you aren't taking this as a complaint from me but rather an observation.
 
hope you aren't taking this as a complaint from me but rather an observation.

Not at all. I get it and wish I could fix it properly.

But I just looked at the frame timing info I get with each video frame from Blue Iris and none of it is suitable. I get the seek bar position but that isn't precise enough, and I get a millisecond frame offset for timing the frame display, but that does not match timestamps of the source video for a number of reasons. I'm actually seeing BI repeat the first frame several times at the start of H.264 clip playback, which is pretty weird.

At minimum I'd need Ken to include the original frame offset from the source video with each frame. The problem is I asked for this years ago when I first implemented H.264 playback in UI3 and couldn't get it then so I probably won't get it now.
 
At minimum I'd need Ken to include the original frame offset from the source video with each frame. The problem is I asked for this years ago when I first implemented H.264 playback in UI3 and couldn't get it then so I probably won't get it now.

I hope he realizes that your UI3 effort is a big reason why BI is successful. Hopefully, he'll give you access to the secret sauce. I wouldn't not think it would take much effort at all on his part.
 
@Sybertiger

I did email BI support about this issue. But in the meantime I have uploaded UI3 version 110 which has implemented this:

I probably can actually get the snapshot directly from the video player, but it won't be as good of quality as requesting it separately from Blue Iris as is done now.

You can manually install version 110 here: bp2008/ui3

You'll need to enable locally-sourced snapshots in UI Settings > Video Player. Please let me know if it works for you :)
 
@Sybertiger

I did email BI support about this issue. But in the meantime I have uploaded UI3 version 110 which has implemented this:



You can manually install version 110 here: bp2008/ui3

You'll need to enable locally-sourced snapshots in UI Settings > Video Player. Please let me know if it works for you :)

I just started playing with it. So far so good. I need to wait until daylight to play with it with a unfinished clip still recording but for pre-recorded clips it's working great so far.

What are the negatives of using this method? Seems like I'm getting the resolution/quality I expect but maybe I haven't played with it enough to understand what the cons are versus getting it off the BI server.
 
The quality is lower with the new UI3 local capture ability because there is an extra layer of compression. The first compression is done in the camera so it can send the video to Blue Iris. The second compression is done by Blue Iris to send it to UI3 (the quality of this is determined by your streaming quality selection). Then UI3 must compress it a third time (into jpeg) when finally saving to disk.

The original (default) snapshot method has UI3 separately download the JPEG frame from Blue Iris, so the video frame only gets compressed a total of two times.
 
The quality is lower with the new UI3 local capture ability because there is an extra layer of compression. The first compression is done in the camera so it can send the video to Blue Iris. The second compression is done by Blue Iris to send it to UI3 (the quality of this is determined by your streaming quality selection). Then UI3 must compress it a third time (into jpeg) when finally saving to disk.

The original (default) snapshot method has UI3 separately download the JPEG frame from Blue Iris, so the video frame only gets compressed a total of two times.


I'll have to compare file sizes as best I can. If UI3 and BI are using the same compression/decompression algorithm then perhaps nothing is being lost as I'm using the highest streaming quality to view that matches or exceeds the camera.
 
File size is not necessarily a measure of quality, though it might actually be pretty close when comparing jpeg to jpeg at the same resolution, from the same frame. As long as you are streaming with the "4K" (not VBR) option in UI3 then the loss should indeed be hard to see even when zoomed in.

The way to get the very best snapshot quality is still going to be using the default server-sourced snapshot method, and if perfect frame selection accuracy is required, then select the frame while using any jpeg streaming method. As of the most recent UI3 release, you can even set the quality of server-sourced snapshots higher than UI3's default of 85%.

1587784508001.png

A server-sourced snapshot at 100% would be pretty close to a lossless frame capture from the original recording.
 
File size indeed is not a measure of quality. But, compressing a image of size X then decompressing the same compressed image resulting in a size of X not X - Y should result in pretty much the same image or good enough for government work. I really like to capture the moment of the "smoking gun" by pausing the playback then clicking the snapshot. It's truly amazing what can happen in the blink of the eye or 1/2 a second. Sometimes someone if facing the perfect position for a fraction of a second ts capturing the perfect image can be elusive given a lot of folks are recording at lower frame rates to preserve HD space.
 
Last edited:
@bp2000

I did a little more testing this morning. My conclusion is that Local (JPEG) works perfectly for my needs as it gives you a high quality WYSIWYG image. Server selected image source continues to be iffy on if you will get the image you are looking at in UI3 or an image that's near but not a match for what you are looking at in UI3. Server (85%) give a file size slightly smaller than Local (JPEG) and Server (100%) gives a file size almost double of Server (85%). All the captured images are of resolution 2688 x 1520 off my 4MP cam recording and with UI3 quality set for 4MP. For my testing there was no discernible difference in viewable image quality but I was not capturing license plate nuimbers or fine detail but rather people and vehicles. As previously discussed, server snapshots don't even come close to capturing a WYSIWYG image when the clip is still being actively recorded. If that never gets fixed I think Local (JPEG) provides a very usable image. Thank you for adding that feature. :clap:
 
You should be aware that the 4MP streaming quality option is set to a 4 Mbps bit rate while the 8MP option has an 8 Mbps bit rate and is therefore better quality even on lower resolution streams.
 
Good day everyone. I have a quick question that I can't seem to find an "official" answer to.

If I set up my cameras to record in MP4 direct to disk, does that mean I will never be able to play back any of the clips?
I'm of course asking about clips that are in the past, and not currently being written to any longer.
I cannot play back any clips recorded with the settings above; I always get the error "the video stream was lost, attempting to reconnect".

Is that the expected behaviour? I read through the documentation but it doesn't specificy anywhere that you cannot play back clips recorded to MP4, D2D, unless they are currently open because they are being written to...

If I check the dev tools in Chrome, the error above gives me a 503 (Service Unavailable).
If I play any of the MP4 remotely (via share) or locally, they play back, not a codec issue.
CPU never goes past 25%, Mem never goes past 75%...
I don't get it.

Thanks
 
Thank you (looks like it's fixed), someone recommended intalling the klite codec pack, but not on the server side.

Interesting, ok this seems to have fixed the issue, but why is my question. I assumed that the remote side is actually playing back the video, and the server piece just streams the "data", but that's clearly not the case as I look at the CPU when I play back the MP4 clips remotely (browser), and it's definitely spiking, and sometimes stalls if I skip forward big steps. I do see that the CPU is hit much less when playing back BVR clips.

I would configure it all for BVR if I could either 1) automate an export from BVR to MP4 at the end of each day or 2) BVR would be a recognizable file type to use with Handbrake or HandbrakeCLI.
#2 would definitely be preferred though
 
All remote viewing through Blue Iris is using transcoded video, which means Blue Iris does in fact have to decode (and encode again) your clips. Blue Iris's MP4 handling is not very good, and as you've noticed, it uses way more CPU than it should when playing them.

I believe BI does have limited support for automatic exporting, however it would be a huge waste of disk space. If interested, it is found in Blue Iris Settings > Clips and archiving, near the bottom.

Are you aware that you can initiate exports from within UI3 so you can remotely get MP4 versions of your clips? Be aware that when you export via UI3, your exports are saved in Blue Iris's "New" folder and count against that folder's space allocation. UI3 does not currently possess the ability to delete the exported items when you are done with them; if you want to delete exported items manually, this should be done from Blue Iris's local console by clicking the folder icon above the clip list and choosing Convert/Export queue, then deleting items from there.
 
@bp2008 I wasn't aware of it having to transcode, it's not the only "tool" to do that, Plex does the same thing, but you can set the clients to actually play the direct video instead, if it supports local decode so the server side doesn't need to transcode it (in the case of BI, all my clients can play back the MP4s, so there would be no need to transcode). Too bad about the MP4 handling; I guess the BVR wrapper improves on that (as well as adding some other features).

The reason to export is that I am compressing all video the HEVC in order to save space; tools can't read the BVR format to do this compression, this is the main reason why I'm saving the clips to MP4; I would much rather use BVR format for the many reasons as there are added features, not to mention that I can have a single BVR file per day setting 24H period for combining (which isn't working for MP4s).

Yes, I'm aware I can initiate export, but this is manual; also aware that they are in the new folder rather than its subfolders - good pointers though!!
On the "export" topic - I see that there are more export profiles than there are "encoding" profiles. I don't find where I can edit the export profiles though, and I don't really want to change it when exporting, but rather export the MP4 as is under the BVR wrapper - is this possible or is that the default?

Thanks!
 
You may need to read some more of BI's help file ;)

If your cameras can encode H.265 themselves, use that with direct-to-disc in Blue Iris. If not, well then I suggest you buy a bigger hard drive because re-encoding to H.265 is a lot of work and reduces your quality due to the second layer of compression.

You can edit the export profiles by right clicking on a clip in Blue Iris's local console and choosing Convert/Export, then there is a configure button for the export profiles. Of course, in most cases you are better off not re-encoding during the export in the first place, and then the export profiles don't matter.