fenderman
Staff member
- Joined
- Mar 9, 2014
- Messages
- 36,902
- Reaction score
- 21,274
The current webserver is one big bug...UI3 is fantastic and miles ahead of the default...
Blue Iris UI3
- Thread starter bp2008
- Start date
awsum140
Known around here
With the "wring out" that UI3 has had here any bugs that show up now look like a flea on an elephant.
fenderman
Staff member
- Joined
- Mar 9, 2014
- Messages
- 36,902
- Reaction score
- 21,274
hopefully youll survive..
6890
n3wb
- Joined
- Mar 15, 2018
- Messages
- 12
- Reaction score
- 1
The image quality is defiantly better. The frame rate for that video is definitely worse. The bandwidth to view the video is higher too, maxes my upload when viewing the 4k camera, (still not full res) which is odd because its higher mbps at 2 FPS than the whole camera is to BI at 15 FPS, but whatever I'll deal with it.
Are you using jpeq images or H.264 streaming? Using jpeg would explain the increased bandwidth use.
DognamedTank
Getting the hang of it
- Joined
- Feb 24, 2018
- Messages
- 90
- Reaction score
- 41
The quality for the stream all depends on your settings (and if you have the hardware to back them up). To change the stream quality, go to Options>>Web Server>>Advanced... and configure the streaming profile.
For my setup, I can view a single cam using H.264 from UI3 and it doesn't really make a difference for my server CPU%. If I ask my server to encode the all camera view, then my CPU% takes a hit so I have to sacrifice some quality. I get better FPS using jpeg for the all camera view, but better overall performance using H.264 for the single cams. I'm using a I7-4790 with hardware Decoding running for all the h.264 streams (only took me 3 years to realize hardware decoding wasn't running because of my nVidia card). I have 23 cams running at ~950 MP/s and my normal CPU% now is 25-30%
For my setup, I can view a single cam using H.264 from UI3 and it doesn't really make a difference for my server CPU%. If I ask my server to encode the all camera view, then my CPU% takes a hit so I have to sacrifice some quality. I get better FPS using jpeg for the all camera view, but better overall performance using H.264 for the single cams. I'm using a I7-4790 with hardware Decoding running for all the h.264 streams (only took me 3 years to realize hardware decoding wasn't running because of my nVidia card). I have 23 cams running at ~950 MP/s and my normal CPU% now is 25-30%
Which version of IE was this?
This afternoon I got a fully-updated emscripten build environment up and running (that's the magic sauce which turns C++ code into JavaScript for the web). I ran some builds of the openH264 decoder and learned some things.
1) I was able to achieve **very slightly** improved file sizes and execution speed ... a 5% improvement at best ... which I attribute to the newer compiler.
2) Updating the openH264 source to the latest (2 years newer than we've been running) resulted in 7-10% performance LOST, so we'll be sticking with the old version, recompiled of course to deliver that ~5% gain.
3) I also tried compiling to "WebAssembly", but some script error I couldn't find a solution for is preventing it from loading in any browser. It probably wouldn't have been faster anyway.
4) I doubled the memory limit that prevented 4K video from being decodable, so 4K works now.
More importantly, the next beta update will be able to decode 4K H.264 video, although the only way for Blue Iris to produce it at this time is to configure a group stream to 3840x2160 resolution. It is a tremendous CPU hog and I don't recommend it. I benchmarked with a short 4K @ 4 Mbps clip. An i7-7700K can barely hit 15 FPS decoding it, and a Samsung Galaxy S7 got 3.19 FPS. Blue Iris also uses a ridiculous amount of CPU time to encode this high of a resolution since it doesn't use hardware acceleration for encoding.
Update: Just for kicks, I ran my 4K video sample through Chrome's built-in video decoder using a Chrome Native Client plugin. 60 FPS. Which actually means higher than 60 FPS, because this particular player can't go higher than my monitor's refresh rate. Last year I had planned to use this player for UI3, and it was going to be great. But then I learned that Google is removing Native Client plugin support from Chrome (in just a few months now), so this excellent player didn't even make it to the beta release.
1) I was able to achieve **very slightly** improved file sizes and execution speed ... a 5% improvement at best ... which I attribute to the newer compiler.
2) Updating the openH264 source to the latest (2 years newer than we've been running) resulted in 7-10% performance LOST, so we'll be sticking with the old version, recompiled of course to deliver that ~5% gain.
3) I also tried compiling to "WebAssembly", but some script error I couldn't find a solution for is preventing it from loading in any browser. It probably wouldn't have been faster anyway.
4) I doubled the memory limit that prevented 4K video from being decodable, so 4K works now.
More importantly, the next beta update will be able to decode 4K H.264 video, although the only way for Blue Iris to produce it at this time is to configure a group stream to 3840x2160 resolution. It is a tremendous CPU hog and I don't recommend it. I benchmarked with a short 4K @ 4 Mbps clip. An i7-7700K can barely hit 15 FPS decoding it, and a Samsung Galaxy S7 got 3.19 FPS. Blue Iris also uses a ridiculous amount of CPU time to encode this high of a resolution since it doesn't use hardware acceleration for encoding.
Update: Just for kicks, I ran my 4K video sample through Chrome's built-in video decoder using a Chrome Native Client plugin. 60 FPS. Which actually means higher than 60 FPS, because this particular player can't go higher than my monitor's refresh rate. Last year I had planned to use this player for UI3, and it was going to be great. But then I learned that Google is removing Native Client plugin support from Chrome (in just a few months now), so this excellent player didn't even make it to the beta release.
Last edited:
Beta b29 is available in the first post.
* Rebuilt the h264 decoder with a newer compiler, better optimizations, and double the memory limit. Improved file size and performance by approximately 5% and it is now 4K-compatible.
* Rebuilt the h264 decoder with a newer compiler, better optimizations, and double the memory limit. Improved file size and performance by approximately 5% and it is now 4K-compatible.
awsum140
Known around here
All I can say is WOW! Talk about a labor of love.
I am new here and I must say that I really like the new UI! The only thing I wonder about is why you are using javascript to decode the H.264 video. I am not an expert, but I guess there must be some standard way of showing H.264 video in a browser (HTML5?)?
You're not wrong to think that. HTML5 video standards are widely supported and the decoders built into browsers are much more efficient than a JavaScript decoder could ever hope to be. The problem is the browser's decoder can only be accessed by sending it fully-constructed mp4 video files. You can construct mp4 files cheaply enough in JavaScript but you have to build the entire file, containing at least a second or two of video (from one i-frame to the next), before the browser can start playing it. This creates a lot of video lag and an equal amount of startup delay. Try the "HLS player" in the right-click menu, this is exactly what it does.
Hi, I'm just looking at trying this out tonight. Without having to read all 28 pages, are the install instructions on P1 still up to date? No need to back up any files?
My only concern is I have horrible DSL "theoretical" max upload of .5Mbps which usually runs about than 1/2 that. Will this even work for me to view my cameras remotely with that upload home speed?
My only concern is I have horrible DSL "theoretical" max upload of .5Mbps which usually runs about than 1/2 that. Will this even work for me to view my cameras remotely with that upload home speed?
The instructions in post #1 are still up to date. No need to back up anything, though if you want to anyway, login.htm is the only file that gets replaced.
It works on horrible DSL upload, although you will want to configure one or two of your H.264 streaming profiles (Blue Iris Options > Web Server > Advanced) to have really small bit rate limits. 384 Kbps and 192 Kbps maybe. You can keep one profile with a high bit rate for when you're on the LAN. Definitely max out the keyframe interval (300) because key frames take the most bandwidth and make the picture look like shit at low bit rate. It gradually gets better until Blue Iris puts another key frame in there making it look like shit again. Most of the UI files are cacheable and besides that Ken added response compression to BI nearly a year ago so it should load fairly quickly after the first time. Loading clip list thumbnails is going to suck probably. Clip thumbnails aren't cachable due to a header the BI web server sends with them. It has been on my list of notes for Ken to look at for months but he hasn't gotten around to it yet.
It works on horrible DSL upload, although you will want to configure one or two of your H.264 streaming profiles (Blue Iris Options > Web Server > Advanced) to have really small bit rate limits. 384 Kbps and 192 Kbps maybe. You can keep one profile with a high bit rate for when you're on the LAN. Definitely max out the keyframe interval (300) because key frames take the most bandwidth and make the picture look like shit at low bit rate. It gradually gets better until Blue Iris puts another key frame in there making it look like shit again. Most of the UI files are cacheable and besides that Ken added response compression to BI nearly a year ago so it should load fairly quickly after the first time. Loading clip list thumbnails is going to suck probably. Clip thumbnails aren't cachable due to a header the BI web server sends with them. It has been on my list of notes for Ken to look at for months but he hasn't gotten around to it yet.