Blue Iris UI3

[davidmtml]

I'm trying to figure out if there's a way for me to increase the fps when viewing a clip back at higher playback speeds (8x, 16x etc.) when using UI3. Is this just a limitation of UI3, or is there some settings that I need to change?

When viewing a clip at 1x playback speed, I get on average 20-25fps. At 2x and 4x, I still get about the same. However, starting at 6x or higher, my fps drops to 5-6fps, and at the highest speeds of 128x or 256x, I get 2-3fps

1. This does NOT happen when using the Blue Iris application, only when using UI3. When using the actual Blue Iris application, the playback is buttery smooth even at 256x. This leads me to believe that there is no issue with hard drive speed.

2. This happens locally (same network), remotely (across the internet), and even using localhost:81 on the same machine that Blue Iris is installed. This means it is not a network speed issue.

3. CPU usage does not seem to be an issue either, showing a modest increase at the highest playback speeds, but still typically under 40%.


So, is this just normal for UI3, or is there something I can do? Does anyone get good performance at higher playback speeds using UI3??

 

[bp2008]

Hah I was just trying to reply to the separate thread you had created, and then you deleted it.

I think it is safe to rule out UI3 or any network as the cause of the problem, and you'll need to email Blue Iris support about it.

Let me attempt to explain why. Not to confuse you, but every video UI3 plays is actually a live stream. Even clip playback. You see, when you play a clip in UI3, Blue Iris does not actually send the video file. Blue Iris internally plays the video file and encodes the result into a live stream for UI3 to play. This is how, for example, you can have a 4K / 16 Mbps video clip and play it in UI3 as 720p / 1 Mbps. Because UI3 is only being sent a live stream of Blue Iris playing the clip.

Therefore, when you have UI3 play a clip at 256x speed for example, Blue Iris sends a live stream of the clip being played at 256x speed. If that live stream happens to max out at a tenth of the expected frame rate, it is because Blue Iris produced it that way.

Since you say all playback speeds perform smoothly in the Blue Iris application (a.k.a. the local console) and you have plenty of CPU cores to spare, it does stand to reason that you should be able to get similar playback performance in UI3. I agree your Blue Iris machine's storage device and CPU does not seem to be an issue. This seems to me like a coding issue in Blue Iris.

So, is this just normal for UI3, or is there something I can do? Does anyone get good performance at higher playback speeds using UI3??

I think results vary pretty wildly on this. Some playback rates (even fast ones) may work better or worse than others depending on a great many factors. I can for example play 1080p clips pretty well at all kinds of playback rates in UI3, except at some parts of the clip it will stutter horribly for no apparent reason, so I seek back to the start, and when it reaches the same place again it stutters horribly again. It could be something as simple as Blue Iris being too aggressive at dropping frames when it thinks its transcoding pipeline is falling behind, and certain parts of certain clips could trigger this more than others. But I'm really just speculating since Blue Iris is closed source and nobody but its developer can see the code or debug it.

 

[erkme73]

Anyone having issues getting PIP to work in Brave? It's been working great until a couple days ago and now the main screen goes black, but no PIP. Works good in Chrome. It may be on my system.

Resolved... Turns out somehow the PIP went to the background - behind everything else (vs. floating on top). Rookie mistake, although I didn't know this was even possible. Leaving this up here in case anyone else suffers from the same tardedness I do

 

[aesterling]

@bp2008 I saw this post from the developer of Scrypted and I'm curious if this webrtc+h265 progress will be of use for UI3 or doesn't matter?

H265 Update

There has been significant movement on h265 browser adoption: Safari quietly rolled out webrtc+h265 on both macOS 15.3 and iOS 18.3 (including app webviews). Chrome will include webrtc+h265 playback starting in version 136.

WebRTC + H265 Browser test: WebRTC Codec Support Checker - H.265/HEVC Compatibility
Chrome Status: Chrome Platform Status

Live streaming and playback of h265 video within supported browser and NVR apps no longer needs to be transcoded. Scrypted's ⁠webrtc plugin has been updated to support h265 over webrtc. The ⁠nvr plugin has also been updated to support native h265 playback when the viewer supports it.

Furthermore, the ⁠nvr Adaptive Streaming feature has also been rewritten with a new hardware transcode pipeline for viewers that do not support h265, like HomeKit. The new transcoder starts up quicker, has higher quality encoding, uses less resources, and is lower latency. Adaptive Streaming's h265 transcode to HomeKit now provides a near native experience. This is great news for people using ⁠unifi-protect Enhanced Encoding or 4K ⁠reolink cameras.

 

[bp2008]

@aesterling Probably doesn't matter. Much. The first obstacle is that Blue Iris would have to support WebRTC (it doesn't). I've also never done any coding using WebRTC so I'm entirely unfamiliar with how it works internally.

However it is likely that H.265 support in WebRTC means increased H.265 support in other APIs too.

UI3's default H.264 player (the one I call "HTML5") uses Media Source Extensions (MSE). MSE is an overcomplicated pain in the ass system designed for video-on-demand services (like Netflix, Youtube, etc) to be able to deliver video into a web browser using any streaming method they want. I guess they didn't want to standardize the streaming method and thereby make it easier for pirates to rip content. I never learned MSE at a low level because I found a third-party library that did all the hard work for me of packaging frames into fragmented MP4 files and feeding them into the MSE API. It doesn't work perfectly but it has always worked "well enough". I have no idea what it would take to support H.265 using this, because Blue Iris doesn't deliver H.265 via its web server so I've never been able to experiment. But I do know some web browsers, at some point in time, have supported H.265 using MSE.

UI3 also supports WebCodecs which is a relatively new standard which allows web pages to directly access the browser's video decoders. However besides being somewhat less robust than the HTML5/MSE player, its major obstacle is that Chrome and related browsers require a secure context (https) in order to use WebCodecs. Of course Blue Iris doesn't serve its web interface using https, so most people don't see WebCodecs as an option. Otherwise it would be our best bet for H.265 support in UI3.

edit: In the end, H.265 encoding is not likely to be in much demand in UI3 because H.264 encoding is already a bottleneck for 4K streaming from Blue Iris, and it is more efficient to encode than H.265. At most I would expect H.265 to eventually become supported for direct-to-wire streaming, but even that would have to be done somewhat carefully since H.265 support is not universal like H.264.

 

[CJ133]

So, I recently started having an issue where I cannot download clips via UI3 anymore. All I get is a download failed error.
It worked up until about a week ago. I tried updating BI and restarting the computer, no change. Tried restarting the mobile devices trying to download the clips and no change.

 

[bp2008]

@CJ133 Someone talked Ken into disabling clip downloads for non-admin users a few weeks ago. I told Ken it was a really dumb idea, but he disagrees apparently. Your web server user needs to have admin privilege now. If you dislike this change, please do make your voices heard by emailing Blue Iris support.

Honestly, Blue Iris is not a subscription TV service. What business does it have trying to prevent people from saving video they have permission to view??

 

[TheWaterbug]

@CJ133 Someone talked Ken into disabling clip downloads for non-admin users a few weeks ago. I told Ken it was a really dumb idea, but he disagrees apparently. Your web server user needs to have admin privilege now. If you dislike this change, please do make your voices heard by emailing Blue Iris support.

Honestly, Blue Iris is not a subscription TV service. What business does it have trying to prevent people from saving video they have permission to view??

Ugh. What version was this mis-feature implemented in? I'd like to roll back my 4 installations!!!!

 

[bp2008]

@TheWaterbug It would have been around March 10th (2025) which indicates the change came in 5.9.9.28 or 5.9.9.29. Unfortunately it seems IpCamTalk's update archive broke again several months ago.

 

[DarkHelmet]

Hey @bp2008, I think I may have found a UI3 bug. UI3 version 286, Blue Iris version: 5.9.9.38. Checked on Edge and Firefox if that matters.

In the image below, I have recently set presets 29 and 30. As you can see, I have left a gap on purpose. The labels do not seem to account for the gap. I'm hovering over #23 which is showing the "House Internal" label which is actually the label for #30. And #22 shows the label for #29.

 

[bp2008]

@DarkHelmet If there is a bug it is probably on Blue Iris's end. Look at the camera properties in Blue Iris. PTZ/Control tab. Click "Edit presets". This shows all your presets in a table. Under normal circumstances the "#" column should match the "Name/value" column, and the descriptions should line up with your expectations. When you click each row in the table you should see the correct thumbnail. If this stuff does not match up, you can clean it up there.

 

[DarkHelmet]

@bp2008 everything is correct in BI. The issue only appears in UI3.

 

[bp2008]

@DarkHelmet Ok I figured out the problem. I've sent a comprehensive bug report to Blue Iris support.

In the meantime, Name/value needs to match the preset # but description can be whatever you want as long as it is not empty. If either of those columns is empty, it creates a gap in the description array and breaks UI3 (but not as badly as it breaks the Android app!). There is no way for UI3 to know if there are gaps in the description array, or where the gaps are, so this is something you have to fix manually until Blue Iris fixes the array to not have any gaps.

 

[DarkHelmet]

@DarkHelmet Ok I figured out the problem. I've sent a comprehensive bug report to Blue Iris support.

In the meantime, Name/value needs to match the preset # but description can be whatever you want as long as it is not empty. If either of those columns is empty, it greates a gap in the description array and breaks UI3 (but not as badly as it breaks the Android app!).

appreciate you looking into it!