Blue Iris UI3

Joined
May 1, 2019
Messages
2,215
Reaction score
3,504
Location
Reno, NV
@saltfish This looks like a good guide: Raspberry Pi Kiosk using Chromium

I'd also recommend installing/enabling a VNC server of some kind so you can connect remotely and fix things if they break.

Here's an alternative that looks pretty nifty: Screenly - Screenly Open Source Edition

Myself when I use a pi for a permanent video display, I prefer to connect it directly to cameras and render their sub streams. This way it doesn't slow down the Blue Iris server at all. I have my own tool for this, though others exist with more polish: SvenVD/rpisurv
can give a screenshot of your display screen output from your OmxPlayerAuto ? I originally was thinking of a HDMI cable from my Blue Iris server to TCL Roku bedroom tv with Blue Iris running on source2 or something, but then I remembered is not good idea to keep the main Blue Iris program running due to hogging up CPU resources. Then I thought of Rasberry Pi 4 using UI3 into the TCL tv, but unsure of the stability of UI3 longtime. I'd like to see if OmxPlayerAuto or the other polished one (rpisurv) could be an option. I'll still try the HDMI cable first just to see the CPU usage with it running 24/7 after I add 3 more cameras.
 

NielK

Getting the hang of it
Joined
Jan 2, 2018
Messages
44
Reaction score
77
Location
UK
Second attempt :)

Setup
  • RPi 4B, 2GB RAM, GPU memory set to 512MB
  • rpisurv 2.1.7 installed, taking rtsp streams directly from the cameras
  • Dahua 5442 cameras (15fps, main stream= 2688 x 1520, substream = 704 x 576)

Main stream display
  • 1 x main stream displays reliably
  • Adding a second causes rpisurv to hang "trying to connect"

Substreams
  • Up to 11 substreams reliably displayed
  • Extra substreams are displayed (tried up to 16) but the whole screen flashes rapidly with 12 or more.
  • rpisurv author says that the rapid flashing indicates that the GPU is at its limit
  • With 11 streams, memory usage = 230M / 1.40GB, CPU < 10%
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,007
Location
USA
can give a screenshot of your display screen output from your OmxPlayerAuto ? I originally was thinking of a HDMI cable from my Blue Iris server to TCL Roku bedroom tv with Blue Iris running on source2 or something, but then I remembered is not good idea to keep the main Blue Iris program running due to hogging up CPU resources. Then I thought of Rasberry Pi 4 using UI3 into the TCL tv, but unsure of the stability of UI3 longtime. I'd like to see if OmxPlayerAuto or the other polished one (rpisurv) could be an option. I'll still try the HDMI cable first just to see the CPU usage with it running 24/7 after I add 3 more cameras.
The video player isn't really screenshottable (video streams don't show up in a VNC window for example), but here is a photo of my bedroom display using it. It is red because I have many layers of red cellophane over the screen to make it more night-vision friendly.

The date/time/temperatures are all part of a web page open in a full screen browser. The camera images (7 of them) are omxplayer instances managed by omxplayerauto.

 

NielK

Getting the hang of it
Joined
Jan 2, 2018
Messages
44
Reaction score
77
Location
UK
Here's a photo of rpisurv displaying 9 and 11 camera substreams. The aspect ratio appears to be preserved only if the screen is divided equally into a 2x2 or 3x3 grid so maybe best to stick to 9 substreams. rpisurv can cycle round to display other "screens", each showing up to 11 substreams. Looks decent for live monitoring.

20201019_104845231_iOS.jpg 20201019_103006655_iOS.jpg
(FWIW, the pi is stuck to the back of the monitor and connected via a short hdmi cable.)
 
Last edited:

Spuds

n3wb
Joined
Nov 12, 2018
Messages
20
Reaction score
12
Location
TN, USA
I'm having a playback issue with UI3. that I can't resolve.

Some (not all) clips or alerts playback "torn" via UI3 but play back fine when done from Blue Iris itself. I'm using the latest BI (5.3.3.9) but I do see the issue with the current stable. To note that seemed to be after I tried the beta (5.3.3.x) which had some problems so I backed out to the stable version (5.3.2.x). I've tried rebooting the cameras as well as deleting and re-installing them with no improvement.

Here is an example of a clip via UI3 and the same clip from BI itself. Anyone else seen this or have any ideas to try? In the below example the next alert clip was fine :/ This is with Chrome and UI3 version 123

1603127338286.png1603127413239.png
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,007
Location
USA
I'm having a playback issue with UI3. that I can't resolve.

Some (not all) clips or alerts playback "torn" via UI3 but play back fine when done from Blue Iris itself. I'm using the latest BI (5.3.3.9) but I do see the issue with the current stable. To note that seemed to be after I tried the beta (5.3.3.x) which had some problems so I backed out to the stable version (5.3.2.x). I've tried rebooting the cameras as well as deleting and re-installing them with no improvement.

Here is an example of a clip via UI3 and the same clip from BI itself. Anyone else seen this or have any ideas to try? In the below example the next alert clip was fine :/ This is with Chrome and UI3 version 123

View attachment 72918View attachment 72919
Yes, one of my cameras does the same thing in about 1/4 to 1/2 of its clips. Sometimes those same bad clips open okay. It is pretty weird. I sent one of the affected clips to Blue Iris Support and he noted the sub stream in the clip fails to decode, and that there were some unusual video frames. He asked for access to the camera so I provided that on Thursday. Haven't heard back.

You should contact Blue Iris support about it. The more people report this problem, the more incentive he has to prioritize a fix.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,007
Location
USA
@Spuds are you using a sub stream on the affected cameras? I am on my one camera that is affected. Using H.265 on the main stream and H.264H on the sub stream.
 

Spuds

n3wb
Joined
Nov 12, 2018
Messages
20
Reaction score
12
Location
TN, USA
Yes the cameras that I have seen the issue on have sub streams enabled, both streams are H.265 .... Good to know I'm not alone, I'll contact BI as well !


ETA: Report submitted
 
Last edited:

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,007
Location
USA
@Spuds I've been told that the next patch, BI 5.3.3.12, should fix our problem. Apparently BI was only looking ahead up to 64 frames to find an i-frame in the sub stream in the recording. So the higher your sub stream's i-frame interval was above 64 frames, the more likely BI would be to fail in the manner we saw. I'm told this number is being increased to 300. That should be plenty :)

For what its worth, the Blue Iris developer recommends i-frame interval to be equal to the frame rate, and no more than double the frame rate. I often set mine outside of this range at 3 to 4 times the frame rate, so in a way I'm asking for issues :)
 

Spuds

n3wb
Joined
Nov 12, 2018
Messages
20
Reaction score
12
Location
TN, USA
@bp2008 Glad he was able to find something that may be the cause of the issue. I generally only run my i-frames at double the frame rate for both main and sub's ... so for me that falls in the 40-60 range, but I'm sure there are some nuances in the calculations. Thanks for the update!
 

looney2ns

IPCT Contributor
Joined
Sep 25, 2016
Messages
15,521
Reaction score
22,657
Location
Evansville, In. USA
@Spuds I've been told that the next patch, BI 5.3.3.12, should fix our problem. Apparently BI was only looking ahead up to 64 frames to find an i-frame in the sub stream in the recording. So the higher your sub stream's i-frame interval was above 64 frames, the more likely BI would be to fail in the manner we saw. I'm told this number is being increased to 300. That should be plenty :)

For what its worth, the Blue Iris developer recommends i-frame interval to be equal to the frame rate, and no more than double the frame rate. I often set mine outside of this range at 3 to 4 times the frame rate, so in a way I'm asking for issues :)
I just had this issue for the first time ever on one of my cams this morning. It was set to 15fps, 30iframe, substream. This happened after upgrading to 5.3.3.11 Just FYI.
 

biggen

Known around here
Joined
May 6, 2018
Messages
2,539
Reaction score
2,765
@looney2ns 5.3.3.12 is what has the fix, and that isn't released yet. But it does sound like that fix wouldn't affect yours with a short iframe interval like that.
Thats good news since I also run double iframes for the given fps. That is the Dahua default for all my cams. Matching iframe to fps has always caused a very pulsating blocky look when I tried in the past.
 
Joined
Aug 8, 2018
Messages
7,386
Reaction score
25,889
Location
Spring, Texas
I just had this issue for the first time ever on one of my cams this morning. It was set to 15fps, 30iframe, substream
All this I-frame talk all of a sudden has me confused. I thought I understood it, but now I am not sure.

I thought setting the I-Frame equal to the Frame Rate would achieve one I-frame per second, right? So in loony's frame rate of 15fps and I-Frame = 30, would lend to one every two seconds, correct? Or do I have this bass ackwards? Why would you want less I Frames?
 

biggen

Known around here
Joined
May 6, 2018
Messages
2,539
Reaction score
2,765
@samplenhold As I noted above, if I match them to the fps I get really bad pulsating on the video. Setting it double clears it up. I don't have enough knowledge as to why the pulsating happens. All I know is that it just does.
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,007
Location
USA
So in loony's frame rate of 15fps and I-Frame = 30, would lend to one every two seconds, correct?
Correct.

i-frames require a huge chunk of the available bit rate, so the more of them you have, the worse the compression ratio gets (worse quality / larger file size)

If your encoding settings aren't very well balanced, you get a pulsating effect at each i-frame. Sometimes there's nothing you can do about it. Other times you can improve it by increasing i-frame interval, reducing FPS, increasing bit rate, or reducing the quality setting if using VBR encoding.
 
Top