Blue Iris UI3

CCTVCam

Known around here
Joined
Sep 25, 2017
Messages
2,660
Reaction score
3,480
Those are ridiculously low frame rates. 15fps would be more typical. Video is going to be very jumpy / jerky at those fps. Also the key frame rate should be 1 key frame every X fps where x is the number of frames per second ie. 4fps is using 1 every 4. On the substreams it looks as if it's 1 key frame every 8.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,006
Location
USA
Those are ridiculously low frame rates. 15fps would be more typical. Video is going to be very jumpy / jerky at those fps. Also the key frame rate should be 1 key frame every X fps where x is the number of frames per second ie. 4fps is using 1 every 4. On the substreams it looks as if it's 1 key frame every 8.
The iframe interval there is half of the frame rate for the main streams, and a quarter of the frame rate for the sub streams. On some cameras (Reolink) it is not adjustable so you take what you can get. I suspect those are all reolinks, given what he said earlier.

But anyway the combination of the unusually low frame rate and having it not match between main and substreams, that is probably what is ultimately causing all the streaming issues.

I also would expect a load like that (all sub streams and super low frame rates too) to not run anywhere near 50% CPU on 10 cores, even weak cores like that 2680 v2 would have, even with virtualization overhead. So there may be other problems besides the mismatched and low frame rates.

Also, that screenshot cropped out the summary section at the bottom which would have been very useful for determining if the CPU load is warranted.
 

VirtualCam

Young grasshopper
Joined
Sep 25, 2015
Messages
49
Reaction score
11
Those are ridiculously low frame rates. 15fps would be more typical. Video is going to be very jumpy / jerky at those fps. Also the key frame rate should be 1 key frame every X fps where x is the number of frames per second ie. 4fps is using 1 every 4. On the substreams it looks as if it's 1 key frame every 8.
Yes, I didn't really need anything higher for what I was doing, and I was trying to get more storage time vs frames. However on the one camera I increased from 2 FPS to 6 FPS, the amount of time to create a 4GB file only dropped from 90 minutes to about 80 minutes. There was also similarly no noticable difference in network traffic or CPU usage. So maybe X.264 compression is better than I thought it was. I've bumped several more up to 10 so we'll see how it looks after 24 hours.
 

Wen

Getting the hang of it
Joined
Aug 24, 2015
Messages
80
Reaction score
25
Is there any way in BI3 to check the "NoSignal" info that appears in BI's status screen? The "NoSignal" info also appears in the Andriod BI app.

Thanks in advance. Love this product. Great job!
 

Evisser4

Young grasshopper
Joined
Mar 5, 2018
Messages
43
Reaction score
9
@Wen I'm not sure what you're talking about exactly.
On the bi app for iOS and android it shows the count of no signals on a camera by camera basis. I think what he is saying is that he is happy with what he sees in the app but he wants a way to view it the exact same in blue iris on PC.
 
  • Like
Reactions: Wen

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,006
Location
USA
I'll add those things to the Camera Properties panel, but there's nowhere else in UI3 where it would be very appropriate. The Full Camera List panel could display that information I suppose, but it would be a lot of clutter and for it to look halfway decent I think it would require that panel to be redesigned to look like the mobile app's camera list. Which I'm not interested in doing.
 

Wen

Getting the hang of it
Joined
Aug 24, 2015
Messages
80
Reaction score
25
@Wen I'm not sure what you're talking about exactly.
In BIue Iris when you select the Status Tab, you can view the camera names, the IP address, the frame rates, and other data for each camera. There is also a NoSignal tally, that tracks how many "NoSignal" events have been recorded. This info. can also be tracked in the Anderoid app.

But there doesn't seem to be any way to access this information in BI3. The Log page does have the info, but it's not aggregated as a total for each camera.

Thanks in advance for your time!! Fantastic app.
 

hikky_b

Pulling my weight
Joined
Nov 24, 2019
Messages
156
Reaction score
168
Location
London
Hi BP, back to cause you more grief! :nervous: Strange one and it's almost definitely Apple being Apple....

This issue has only been discovered since experimenting with your latest build of UI3 with MQTT support (Which is really great!), but I don't believe the issue is new, just uncovered.

Essentially, I have an instance running on an iPad through "Kiosker" (Full Screen Web App) that runs UI3 within an iFrame (I know, but there is a reason :p ). The iPad logs into UI3 automatically using an anonymous user.

When logging in I get an error popup saying: "Attempted to access sessionManager before it was initialized" - has been like this for some time but it never mattered before. I assume it's loading up a fresh anonymous session each time UI3 is loaded. This is also means I am locked to using the anonymous user, otherwise I need to retype the log in details every time the page is loaded.

This also leads to the issue whereby my MQTT credentials are not saved between refreshes of the UI3 instance.

I first thought this was solely because I was running UI3 within an iFrame, which it partly is, however it is only an issue using Safari based browsers (Desktop & iOS). If I load the page through Chrome on another device, I receive no errors, and UI3 logs in automatically into the specified user account and also retains the MQTT credentials. In fact, this is how another desktop instance is configured.

Is this a fixable/workable issue or simply a limitation with Safari/WebKit based browsers in this specific scenario?

Thanks!

Screenshot 2022-06-22 at 15.30.04.png
 

hikky_b

Pulling my weight
Joined
Nov 24, 2019
Messages
156
Reaction score
168
Location
London
@hikky_b Looks like that would happen if cookies are disabled in your browser. I don't normally test that way so something broke :)

I've fixed it for the next UI3 release, but I have no ETA for when that will be.
Thank you very much! I understand my use case here with running ui3 within an iFrame is not general practice :smash:

Strangely, cookies are enabled and I don't receive the toast error when logging into ui3 directly, only when running through an iFrame.

I will test the update the and post back here.
 

aesterling

Getting comfortable
Joined
Oct 9, 2017
Messages
352
Reaction score
346
@bp2008 are there any additional caveats with UI3 when using the new "direct to wire" feature in BI 5.5.9.0, beyond what's mentioned in the help PDF? Thanks!

Screen Shot 2022-06-28 at 09.29.21.png
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,006
Location
USA
@bp2008 are there any additional caveats with UI3 when using the new "direct to wire" feature in BI 5.5.9.0, beyond what's mentioned in the help PDF? Thanks!

View attachment 131987
Yeah there are. I've had about an hour to play with it.

First of all, the only way to use this feature is by enabling "Direct-to-wire" in one of BI's streaming profiles as explained in BI's help file, and configure some streaming profile(s) in UI3 to inherit from that. I used Streaming 2 for this and left Streaming 0 alone because everything uses Streaming 0 by default. I'll ask Ken for a URL parameter I can send so that this behavior can be turned on or off or inherited explicitly from UI3. Update: This is done and implemented in BI 5.5.9.2 / UI3-221.

There are some quirks that people should be aware of:

1. "Direct-to-wire" only works for H.264 streams. If the camera is sending H.265, BI will not send a "direct to wire" stream. BI will re-encode instead.
2. Stream can take longer to load when using "direct-to-wire", because decoding can't begin until a keyframe arrives.
3. If UI3's streaming profile defines a low enough resolution limit and Direct-to-wire is enabled, then BI will send the sub stream if available.
4. The video stream will often not match the resolution that UI3 requested. This can confuse UI3 when it comes to sizing the video player and handling digital zoom, and behavior may vary between UI3's different H.264 player options. Generally it should still be usable but this is not a very well supported situation.
5. Direct to wire is not used for clips (yet?) and possibly never will be used for timeline.
6. UI3 has a lot of H.264 video decoders available and they each may handle "direct to wire" streams a little differently.
  • HTML5 H.264 Player (this is the default) - Seems to be okay, but perhaps with some extra delay, I'm not sure why or if I can do anything about it.
  • JavaScript H.264 Player - Seems to work quite well, but as always, it is the most CPU-intensive.
  • WebCodecs H.264 Player (available only through HTTPS proxy servers) - Appears to drop some frames and stutter, I'm not sure why, possibly some cameras use frame types that I need to handle differently in the code.
  • NaCl H.264 Player (available only in Chrome with Native Client turned on in chrome:/flags/) - Generally glitchy and not recommended for use anyway.
 
Last edited:

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,006
Location
USA
Blue Iris 5.5.9.1 or 5.5.9.2 fixed an issue with Direct-to-wire streams being stuttery when used with a cam that has sub streams enabled (some frame timestamps were being repeated and others skipped).

As of Blue Iris 5.5.9.2, UI3's streaming profiles can override the "Direct-to-wire" and "Full Range Color" parameters. Full Range Color is best kept off except in rare situations where your video is not utilizing the full dynamic range of your display and you have no other way to correct it. In most cases, enabling Full Range Color is not beneficial and will only cause the brightest and darkest details in your video to be lost.
 

astroshare

Getting the hang of it
Joined
Dec 18, 2020
Messages
76
Reaction score
41
Location
Florida Panhandle
Have an issue when playing clips with direct-to-wire enabled (see screenshot). The video doesn't appear to switch to the main stream. If I pick another profile without DTW it plays back fine. All my cameras are running H264. I also have no problem just viewing the cameras with DTW enabled.

backyard.png

Edit: Nevermind, I missed number 5 previously
5. Direct to wire is not used for clips (yet?) and possibly never will be used for timeline.
 
Last edited:
Top