Blue Iris UI3

bp2008 said:
@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
Click to expand...
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.
 
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%
 
  • Like
Reactions: bp2008
Holbs said:
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.
Click to expand...

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.

 
  • Like
Reactions: looney2ns
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:
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
 
  • Like
Reactions: bp2008
Spuds said:
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
Click to expand...

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.
 
@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 revert back to 5.3.2.11 which is the last stable version.
 
  • Like
Reactions: sebastiantombs
I've been meaning to say thanks for UI3 for awhile now. It makes reviewing videos so much faster and easier. The thumbnail make it sooo easy to see what triggered a camera without having to check/playback each clip and that saves a heck of a lot of time.
 
  • Like
Reactions: handinpalm, looney2ns, actran and 4 others
@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 :)
 
  • Like
Reactions: handinpalm, jaydeel, Spuds and 3 others
@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!
 
bp2008 said:
@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 :)
Click to expand...
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.
 
bp2008 said:
@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.
Click to expand...
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.
 
  • Like
Reactions: looney2ns
looney2ns said:
I just had this issue for the first time ever on one of my cams this morning. It was set to 15fps, 30iframe, substream
Click to expand...
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?
 
@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.
 
  • Like
Reactions: samplenhold
samplenhold said:
So in loony's frame rate of 15fps and I-Frame = 30, would lend to one every two seconds, correct?
Click to expand...
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.
 
  • Like
Reactions: looney2ns and aesterling
bp2008 said:
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)
Click to expand...
Ok, I am learning something here! So why not make the I-Frame several seconds? Like 10, or 20?
 
You must log in or register to reply here.
Top Bottom