Blue Iris UI3

@EyeOfSauron Can you better describe how that works? I want to make sure it was not implemented in a vulnerable way. I found no mention of it in the help file or web server config section, and passing along a Remote-User: username header or Remote-User: username:password had no effect.
 
  • Like
Reactions: hikky_b
@EyeOfSauron Can you better describe how that works? I want to make sure it was not implemented in a vulnerable way. I found no mention of it in the help file or web server config section, and passing along a Remote-User: username header or Remote-User: username:password had no effect.

I can only share what I was told - I sent him the request for this and included following docs:


I also told him this:

With this setup, BI should either trust only specific (proxy) IPs to provide those headers, or advise the user to ensure that BI cannot be accessed without going via the proxy.

It's possible that the docs and/or additional options are forthcoming since I just today replied that it was working as intended.

Just for a sanity test, as I am on my work computer and going via another proxy etc, I tried from the command line using a machine on my network, and it seems to work. Without it, I get a 401 response.

curl -I -H 'Remote-User: MY_USERNAME' -XGET http://blueiris.MY.DOMAIN

Edit: I also had to add -XGET to the curl command.
 
Last edited:
@hikky_b

That is a puzzling error, it seems that the streaming profile you are using may be getting forgotten somehow. I have not been able to figure out what sequence of events could cause that. Anyway I have tried to make the relevant code more fault-tolerant in UI3-264 which I would like you to install manually and let me know what happens. Maybe this will solve the problem for you or at least help identify the true solution.

Update:

No errors since installing UI3-264.

Will keep monitoring - Thank you!
 
  • Like
Reactions: bp2008
Anyone else experiencing this with IOS 16.4? Fails on both my iphone's with the same error. From a reddit post:

Updated my phone to 16.4, no longer was able to view UI3 in either chrome or safari. BI installed version was 5.7.1.2. My wife’s phone, still on 16.3, continued to work properly.
Updated BI to 5.7.2.4, still no working video in 16.4. Wife’s phone on 16.3 still works.
If you’re using iOS, maybe wait to update.


I filed a bug here that might be related to this issue- 267121 – WebKit requires keyframes now for video decodes, which makes it less forgiving for IP cameras -- I wonder if this PR ([WebCodecs] AudioDecoder and AudioData support by philn · Pull Request #16432 · WebKit/WebKit) may have introduced the "Key frame is required" or even an earlier change. Waiting to hear back from the developers for any input here.
 
Hi all,

Is there any way to setup the UI3 while using dual NIC? I tried running it and it comes back saying bad connection request.
 
Hi all,

Is there any way to setup the UI3 while using dual NIC? I tried running it and it comes back saying bad connection request.
Can you ping the IP of the BI server?
If so, it should work.
What URL are you using?
 
I actually found the original PR: 245878 – Implement WebCodecsVideoDecoder with VPx backend

It seems adding support for newer codecs (VP8/VP9) may have led to this breaking change.

I'm glad someone has finally been tracking down the cause of that problem and the proper place to report it :)

Hi all,

Is there any way to setup the UI3 while using dual NIC? I tried running it and it comes back saying bad connection request.

In Blue Iris Settings > Web server, make sure the "Bind exclusively" checkbox is not checked. Then ensure that the TCP port number for Blue Iris's web server is allowed through Windows Firewall. I always create a firewall rule to explicitly allow that traffic, and do not rely on the automatic firewall configuration to do the job properly.
 
I can only share what I was told - I sent him the request for this and included following docs:


I also told him this:



It's possible that the docs and/or additional options are forthcoming since I just today replied that it was working as intended.

Just for a sanity test, as I am on my work computer and going via another proxy etc, I tried from the command line using a machine on my network, and it seems to work. Without it, I get a 401 response.

curl -I -H 'Remote-User: MY_USERNAME' -XGET http://blueiris.MY.DOMAIN

Edit: I also had to add -XGET to the curl command.

None of this seems to be working still as of BI 5.8.3.1, and there's still no documentation of the feature in the help file or in BI settings. Something must be missing. I've tried sending this request from another LAN machine and also from a remote internet machine, and in both cases Blue Iris just returns a 302 (redirect) or 401 (unauthorized) depending on whether BI is configured to "Use secure session keys and login page".

I'm just concerned because for a long time Blue Iris did not make any attempt to authorize the X-Forwarded-For header, so it could be exploited by any outside attacker to gain access that is normally only available to privileged IP addresses. (since August 2022, BI now handles that and the X-Real-Ip header much more securely, only trusting header values that were sent by a LAN address). So I am naturally suspicious when other authentication bypass mechanisms are added, that they might be easily exploited by remote connections.
 
Last edited:
  • Like
Reactions: GoodToGo and actran
Attaching a pic of the web server settings for vision. The local internal LAN access is working on the blue iris server. If I ping it from another pc in the same network using the internal LAN address, it times out.

The remote external access cannot be seen from the same BI server or any other computer.

IP addresses hidden for obvious reasons.



Blue Iris Web server.jpgBlue Iris Web server.jpg
 
You can list the private LAN IP addresses as it does not tell anyone anything - they are the same as everyone else. The IP address of your service provider for your WAN is what you don't provide...Everything on the inside past the modem is fine to put out. Everything on the inside, the local will fall under these ranges and you are not telling anyone anything about how to hack your system because these ranges are reserved for the "home side" of the service so every home internally will be within this same range):

10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

And it is usually a number typo someone has with their IP address that causes troubleshooting to take longer because someone doesn't show the IP address and that extra 1 sticks out like a sore thumb to someone helping troubleshoot.
 
You can list the private LAN IP addresses as it does not tell anyone anything - they are the same as everyone else. The IP address of your service provider for your WAN is what you don't provide...Everything on the inside past the modem is fine to put out. Everything on the inside, the local will fall under these ranges and you are not telling anyone anything about how to hack your system because these ranges are reserved for the "home side" of the service so every home internally will be within this same range):

10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

And it is usually a number typo someone has with their IP address that causes troubleshooting to take longer because someone doesn't show the IP address and that extra 1 sticks out like a sore thumb to someone helping troubleshoot.

Thanks for that, I erred on side of caution.
 
Hi @bp2008, on recorded videos when seeking, the video quality is extremely compressed and low (with severe H.264 macro blocking so much so that it's hard to see what is going on). No matter what settings are used (like adjusting Blue Iris' encoder or UI3 profiles), nothing seems to change this ultra-low encoding profile that is used only during seeking (the actual recording playback is ok, this only affects seeking of recordings within UI3). I don't use sub-stream recordings and the UI3 "Seek with Sub Stream" setting is off.

A few years ago seek quality was ok but at some point it became a mess. This issue has persisted no matter the version of Blue Iris and UI3. Currently on UI3 version 249 and Blue Iris version 5.8.4.2. I tried many different encode settings (and a reset at one point) but could not find a fix or a solution by search. I want to finally ask if maybe I can do something about it, perhaps using an override in the JS to use a specific encoding profile for seeking?
 
Hi @sp0457

UI3's seeking (while you are actively holding down the mouse button and dragging the seek bar) is not done with H.264 since there's no API available to do that properly. While you seek, every frame is a jpeg snapshot.

If you were using a Jpeg streaming profile, I think it would use that profile to determine the quality to use for seeking.

But when you have an H.264 profile selected, UI3 does it differently. If I recall, the quality of those frames while seeking is dependent on the average bit rate that was achieved during the last few seconds of H.264 video streaming. The idea was, if the bit rate was very high, then the user is probably on a fast connection so getting large jpeg images won't be too laggy. But if the bit rate was very low, that indicates there might not be much bandwidth available so UI3 would try to use a very low quality for those jpeg images whiel seeking.

It may be time to adjust the logic that decides the quality. Or maybe I just need to add a "seeking quality" field to the streaming profile configuration, and not have it try to choose the quality dynamically anymore.

You already turned off the Seek with Sub Stream setting. That is good. The only other thing you can control at this time is to choose a higher quality streaming profile like "2160p" as this should in most cases result in a high enough video bit rate that the jpegs look good. Are you not seeing that behavior on your system? Do note that the "VBR" profiles typically function with a very low bit rate and this may adversely affect the quality that is used while seeking. But the profiles without "VBR" in the name have higher quality settings which typically yield a much larger bit rate, and therefore higher quality seeking.
 
  • Like
Reactions: sp0457 and actran
Hi @sp0457

UI3's seeking (while you are actively holding down the mouse button and dragging the seek bar) is not done with H.264 since there's no API available to do that properly. While you seek, every frame is a jpeg snapshot.

If you were using a Jpeg streaming profile, I think it would use that profile to determine the quality to use for seeking.

But when you have an H.264 profile selected, UI3 does it differently. If I recall, the quality of those frames while seeking is dependent on the average bit rate that was achieved during the last few seconds of H.264 video streaming. The idea was, if the bit rate was very high, then the user is probably on a fast connection so getting large jpeg images won't be too laggy. But if the bit rate was very low, that indicates there might not be much bandwidth available so UI3 would try to use a very low quality for those jpeg images whiel seeking.

It may be time to adjust the logic that decides the quality. Or maybe I just need to add a "seeking quality" field to the streaming profile configuration, and not have it try to choose the quality dynamically anymore.

You already turned off the Seek with Sub Stream setting. That is good. The only other thing you can control at this time is to choose a higher quality streaming profile like "2160p" as this should in most cases result in a high enough video bit rate that the jpegs look good. Are you not seeing that behavior on your system? Do note that the "VBR" profiles typically function with a very low bit rate and this may adversely affect the quality that is used while seeking. But the profiles without "VBR" in the name have higher quality settings which typically yield a much larger bit rate, and therefore higher quality seeking.
@bp2008

Thanks for the reply. Yes, seeking with mouse dragging and using a H.264 profile (CBR, 6000 kbps, 1080p that is defined on the server) results in very compressed video. I set this up server side so that all my home devices would have the same default profile. After reading your post, I set the same bit rate limit within UI3 (even though it's already set on the server) and the seek video quality is now ok. So setting the bit rate limit in UI3 is what fixes it (all other settings blank or as inherit). Thank you for the help.
 
@bp2008

Thanks for the reply. Yes, seeking with mouse dragging and using a H.264 profile (CBR, 6000 kbps, 1080p that is defined on the server) results in very compressed video. I set this up server side so that all my home devices would have the same default profile. After reading your post, I set the same bit rate limit within UI3 (even though it's already set on the server) and the seek video quality is now ok. So setting the bit rate limit in UI3 is what fixes it (all other settings blank or as inherit). Thank you for the help.

As you've perhaps now noticed, all of UI3's default streaming profiles override the bit rate limit and resolution limit of the serverside profiles. And most also override the encoding quality.
 
  • Like
Reactions: actran
Thanks @bp2008,

Another question. This may be more of a blue iris issue than UI3 but thought I'd ask: When using sub-streams, UI3 defaults to the frame rate and audio of the sub-stream when viewing the main camera stream. This is especially odd when using direct to wire when there is no encoding from Blue Iris. As a result, the main stream is choppy because the sub-stream has a lower frame rate so I have to set the sub-stream to the same exact frame rate and audio quality as the main stream to avoid this issue.

The primary reason for using sub-streams is to minimize CPU usage by having lower res video and frame rate for motion detection and when a group stream requires it. It'd be ideal if sub-streams can also have lower frame rate and no audio. Is this something that needs to be done by Blue Iris and or can it be addressed by UI3?
 
  • Like
Reactions: bp2008
Thanks @bp2008,

Another question. This may be more of a blue iris issue than UI3 but thought I'd ask: When using sub-streams, UI3 defaults to the frame rate and audio of the sub-stream when viewing the main camera stream. This is especially odd when using direct to wire when there is no encoding from Blue Iris. As a result, the main stream is choppy because the sub-stream has a lower frame rate so I have to set the sub-stream to the same exact frame rate and audio quality as the main stream to avoid this issue.

The primary reason for using sub-streams is to minimize CPU usage by having lower res video and frame rate for motion detection and when a group stream requires it. It'd be ideal if sub-streams can also have lower frame rate and no audio. Is this something that needs to be done by Blue Iris and or can it be addressed by UI3?

There is nothing I can do about those issues, as it is all within the domain of Blue Iris and is not something UI3 is involved with.

The one about sub stream audio is new to me. I was under the impression that a camera's audio came from the main stream, period. It is mentioned right in the first sentence of the Dual streaming section of Blue Iris's help file.

1705282911262.png