Blue Iris

Remote Access • Web Interface (UI3)

2021-10-08T01:32:22+00:00

Introduction

This article documents UI details, mostly driven from tickets.

Webinar
The Web Interface webinar provides a great overview of the functionality and calls out many important tips and tricks.

Networking

Gotcha 1: Using DDNS instead of port forwarding. Accessing the UI3 interface from the LAN using the DDNS URL is very slow.

We are not networking experts so users on the forum may have a better answer.
One possibility is the firewall settings are not set correctly.
Another possibility is usually when you use a DDNS url from within the same LAN, the traffic gets proxied through the router using a function called "NAT loopback" or "hairpin NAT". It could be that their router is bad at this. One workaround is to try the BI server's LAN IP address instead of the DDNS url when on the same LAN.

Gotcha 2: Login is slow. Live view fails to load or takes a minute to load.

I recommend checking CPU and memory usage on both server and client while remote viewing. Most computers these days are plenty good enough for UI3, but that isn't a guarantee. And also make security software exceptions (see Windows Tuning article), as such software can interfere with the web server connections. A poorly performing network could also cause such issues.

If CPU usage is high, consider unselecting "Require/decode all camera frames when streaming".
Gear icon in top right of Console.

Gotcha 3: Ad-blockers
See ad-blocker gotcha.

Live view

Gotcha 1: Orange Clock Warning

If you get the orange clock warning, either the fps is low for the stream or the endpoint is overloaded because the resolution (i.e. bitrate) is too high.
Run through the Windows Tuning article just to make sure Windows is not in conflict with BI.
Readjust the stream using Gear icon (bottom right).

FYI, the UI3 gear settings are just presets values in the web server encoder settings

Gotcha 2: Live view is choppy.
Symptom: Many frames are missing. The time overlay skips several seconds. The live view was delayed by several seconds.

Fix: Try increasing the fps for the group stream.

If the load on the network gets too much, in the UI3 interface, click on gear icon on bottom right and choose a higher/lower resolution to ease network congestion (Gotcha 1 above).

Engineering warning

This setting was at 10 at one time, but it used so much CPU, it caused a lot of tickets for that. It should be increased judiciously. 15 would be even worse.

Perhaps now that dual-streaming is the norm, this will not be as much of an issue.

Playback

Gotcha 1: Playback is slow or choppy for recordings. 1 - 5 fps

If the live view of the same camera is streaming just fine, then there is probably not an issue with CPU or network performance. The main difference between live and clip playback is the involvement of the storage device on the BI server. It may be having trouble seeking and reading an existing file if there is a lot of recording going on.

Some ideas:

1) Revisit Gotcha 1 above in the Live view section. Simplify the stream coming to BI using the gear icon.
2) Make sure playback in UI3 is set to 1x speed and not playing in reverse.
3) Try temporarily disabling recording on the BI server (set shield to red) to reduce disk load for testing purposes.
4) Make sure the recording format is BVR. I've had bad playback issues with MP4 before.
5) If hardware acceleration is used, look for the "Also BVR" checkbox in Blue Iris console > Camera Properties > Video tab. Toggle it on or off in case hardware acceleration is helping or hurting the playback somehow.

If still an issue, run through Remote device tests to rule out the server and network.

UI3 Settings

Gotcha 1: I set the UI3 timeout to 0 (i.e. never time out), but the browser still logs me out.

In General settings, users can set the UI3 idle timeout period.

Users state this setting is not being honored and UI3 still logs out. UI3 will let you know when a session disconnected because of a timeout.

If instead you received the login page, that means UI3 lost the session with BI which resulted in reloading the page which typically redirects to the login page.

It could be caused by anything that causes temporary connectivity loss, such as the network going down for 1 minute or longer, or even Blue Iris crashing. Or maybe even a session length limit applied to the Blue Iris user account. Although I think the user would realize if they had set this on all their BI systems. There certainly is not a session length limit by default.

The other possibility is the endpoint viewing UI3 is disconnecting. For example, if the endpoint is a laptop, power saving settings may have put the laptop to sleep or disconnected the laptop from the network.

Gotcha 2: Login credentials

The login page does not remember user credentials.

Like all other UI3 settings, the username, password, and "Log in automatically" checkbox state are saved in the browser's Local Storage. Local Storage can be inspected for troubleshooting purposes in the browser's developer tools. In Chrome, a person would open developer tools > Application tab > Storage > Local Storage > [address]. This will show all local storage items that exist for the selected web site. Look for the keys "bi_username", "bi_password", and "bi_rememberMe".

To make the saved credentials get lost, the browser may be clearing Local Storage regularly (such as when the tab is closed) due to security or privacy settings. Or perhaps a browser extension is responsible. Most browsers treat "Local Storage" the same as "Cookies" so most settings affecting Cookies would affect this as well.

Console view

Gotcha 1: Reduce margins between camera windows.
See Gotcha 7 in 5.5 Release notes.

Gotcha 2: Missing cameras

Below are settings that can prevent a camera from being visible on UI3.

A camera could be marked as hidden (BI Camera Properties > General), or its webcasting could be disabled (BI Camera Properties > Webcast).
Or the user could be logged in to the web server using a limited account that does not have permission to view all cameras.
Or it could be that he just needs to use the Current Group dropdown in UI3 to select All cameras.

Gotcha 3: Can I filter Alerts/Clips by camera like in the console?

Yes. Go to Clips tab -> Select a camera. Filter is automatically applied.

BI Server Settings

Gotcha 2: Ad blockers
See Ad blockers gotcha.

Gotcha 1: User permissions
Global settings -> Users tab
User Permissions may be restricting access
Global settings -> Users tab
The below settings restrict access to LAN and/or applies restrictions based on the schedule.
Help button in dialog has details.

The Global settings -> Web server tab -> Advanced button has other possible access restrictions.
Help button in dialog provides details.

Statistics: Posted by varghesesa — Fri Oct 08, 2021 1:32 am

Remote Access • Mobile Devices - User interface

2021-08-09T17:53:50+00:00

Introduction

This article provides clarity to the user interface based on tickets.

Link to Mobile Devices - Setup article (if needed).

If you are facing video issues like Live view is choppy or you are getting a black screen when trying to playback an alert then you are having video streaming issues. The Camera Stream Gotchas article deals with all things streaming including streaming to mobile endpoints.

Alert actions

If your issue is with alert actions, Push / Email / SMS, go to the Alerts & Action map sub-forum.

Recent Alerts

Located in the cameras tab, the recent alerts column displays the last alert that was generated by each camera.

If you happen to delete the recent alert or the clip containing the recent alert, the space will be blank until the next alert is created by the camera.

PTZ

PTZ Controls are greyed out.

There is no such thing as PTZ controls when viewing a group of cameras, i.e. group view.
Camera settings -> PTZ tab. Enable Pan/Tilt/Zoom etc. checkbox has to be selected.
Global settings -> Users tab. The user using the app has to have PTZ privileges. PTZ/Control has to be checked.

Motion Overlays

Motion overlays are not visible
Go to the playback window for an alert.
Click the 3 dots button in the top right.
Video overlays are usually the BI timestamp but could have customizations based on the user.
Motion rectangles obviously show the motion overlays.

Also, keep in mind, if you have Re-encode instead of D2D as your Record setting, Motion overlays are not recorded unless you have them turned on during Live view. Camera settings -> Trigger tab -> Motion sensor.

Cameras

Gotcha 1: Camera streams no longer appear.
If none of the cameras appear, see mobile apps troubleshooting framework.

Gotcha 2: Some cameras do not show live video

Fix1:
Highly unusual. The most common reason is if the camera has no signal or lost signal. See No Signal article to troubleshoot.
Outside of the camera not connecting from the Console, the only other way this is possible is if webcasting for that camera was disabled.

Fix2:
The video pipeline: Camera feed -> Decode -> Encode ->Mobile device live view.

Decode: Turn Decode on/off to see if video improves
Camera settings -> Video tab. Hardware decode = Default (On) / No (Off)

Camera feed: See Camera settings article on optimal encoding settings on a camera.

Gotcha 3: Cameras do not show up on the phone

If cameras are visible on the console but do not show up on the mobile apps, there must be a permissions issue.

In the console, did you make the camera hidden?
FYI, we're trying to move away from hidden cameras because it often leads to confusion.
See 5.5 Release notes for details.

Otherwise the user account used to login to the phone app does not have permission to access the camera.
Double check your user settings. Global settings -> User tab.

Alerts list

Gotcha 1: Missing alerts

The Alerts tab in the mobile app should have the identical listing as the Alerts list in the Console.
If you notice differences (rare occasions)

Confirmed alerts
The mobile apps ONLY show Confirmed alerts. Know the difference between Confirmed alerts and Cancelled alerts. Confirmed alerts meet all the restrictions beyond the Trigger tab. This includes Artificial Intelligence, if enabled, the Trigger sources and zones restrictions in the Alerts tab and any other conditions specified in the Alerts tab.

For example, a user can unselect Hide cancelled alerts on timeline and 'all alerts'. Camera settings -> AI dialog. If a user does so, cancelled alerts due to AI will appear in the Alerts list in the console. However, the mobile app will NOT show cancelled alerts. This is one example where the Alerts list on the console may differ from the Alerts list on the mobile app.

User permissions
First confirm the username for login at the console is the same as the username used on the mobile device. For example, if you access the console via local_console and the mobile app with a user login, the user privileges may very well be different.

Does the user that logged into the mobile device have access to the camera?
In the cameras tab, is the camera listed? Can you see the live view?
If not, check user settings. Global settings -> Users tab.

Hidden cameras
Hidden cameras are not visible on remote devices in general. They are only visible to admin accounts on remote devices. Similar to user permissions issue (above), a non-admin user will not see alerts associated with hidden cameras. However, if an admin account is used to access the console, the alerts from the hidden cameras will still be listed.

One of the motivations for the 5.5 release of Dynamic Group Layout was to do away with the confusion associated with hidden cameras.

Instability

Gotcha 1: Ad blockers
See Ad blockers gotcha.

Statistics: Posted by varghesesa — Mon Aug 09, 2021 5:53 pm

Remote Access • Mobile Devices - Setup

2021-04-06T00:13:33+00:00

Introduction

This article walks you through connecting your iOS/Android devices (phones, tablets) to your Blue Iris server. It walks through all the dependencies and potential pitfalls when trying to setup your device.

If you prefer to watch the webinar associated with this article, checkout the Mobile Devices and Apps webinar.

If you are on an Android device, the Android gotchas article also has information the may help you self-correct the issue.

The Mobile Gotchas article is a list of past learnings from tickets. Good to review before creating a ticket.

Networking

There is no way for the mobile app to communicate with the Blue Iris server unless you setup your network to do so.
The Networking - Remote Access article will walk you through setting up the network correctly.

Checkpoint: The BI server is setup correctly. The network is setup correctly.

Mobile app

The below sections are about setting up the mobile app to connect to the BI server. This section has three main sections.

Server settings: Settings needed for the mobile app to be able to connect to any server.
Network connectivity: Based on server settings, can the app connect to the server. If not, how to troubleshoot.
App settings: All the settings on the mobile app that allows you to customize your user experience.

Server settings

Server settings - Wizard
This section explains setting up the mobile app using the wizard. Always best to use the Wizard the first time because the wizard sets up the app but also sets up the right permissions for the app on your phone.

This section is about the Add a new server button / dialog so the mobile app can connect to the BI server.

Easiest way to setup your phone settings to connect and work well with the BI App is to use the Wizard within the Add New Server function.
FYI, the BI Mobile App can connect to multiple servers.

The iOS Server Setup Wizard (helps configure iOS device settings)

The Android Server Setup Wizard (helps configure Android device settings)

The final step is to Scan the QR Code. Where is the QR Code?
The QR Code is located in one of the last pages in the Remote Access Wizard. (see below)

Server settings - Manual

FYI, you can choose to bypass the Server Wizard and go directly to the server setup page. Keep in mind the setup page only configures the settings needed to connect the mobile app to the BI server. Users should always go through the Wizard at least once so the mobile app has the correct phone privileges to work correctly. For example, you may need to allow the application to use your phone's location services if and when you activate geo-fencing. Privileges on the phone can only be set in phone Settings (manually) or through the Server Wizard.

Lookup key (iOS) / Get IPS (Android)
The Lookup key / Get IPS key is great for having BI populate your LAN / WAN address for you.
It helps prevent fat fingering the wrong values.
It also helps when you have an ISP provider that changes your WAN address a lot.

The Lookup key can be your best friend. However, for it to work, you have to enable the functionality on the BI server. On by default.
Register IP address to assist with client app connections. Global settings -> About tab.

Http vs Https

If you decided to add encryption, make sure to select https where appropriate. Revisit Web server settings section if stuck.

At this point, the mobile app should be setup. Time to connect to the server!

Network connectivity

This section helps you connect the mobile app to the BI server.
Update to the latest version or the latest stable version of the BI server software.
Features/functionality on the mobile app are not guaranteed to run with older versions of the server.

LAN test
Try connecting the mobile app to the server from the LAN. Hit save in Server settings page (if not done so already) -> Connect.

If successful, great! You have confirmed your mobile device has access to your BI server (license key, username, password, LAN address are all entered correctly) and you have confirmed at least some of the network requirements have been met like the BI web server is running and accessible from the LAN. You can scroll down to the WAN test.

If the mobile app spins after hitting the connect button, the app cannot talk to the BI server.

Mobile device permissions
Global settings -> Mobile devices tab
If the mobile app connects successfully to your server, your device will be listed in the Global settings -> Mobile Devices tab.

If your device is NOT listed, then the mobile app cannot register (i.e. talk) with the BI server.

Permissions
You first need to confirm correct user permissions for the user logging into the mobile app.
You also need to confirm the mobile device has access to the server.
See permissions article.

Network
If you have other mobile devices that do connect to the server, then obviously the network must be fine and you can skip this section.

Device test
Use the UI3 interface to confirm whether the network and BI server are working correctly.

WAN test
Now you can test whether the network is setup correctly for remote access.

Logout of mobile app. Disconnect mobile phone from LAN/Wifi, i.e. use your cellular network.
Try re-connecting app to server. If successful, confirmed remote access.
If a problem, confirm WAN address is correct (not LAN) in the Server settings.

If the UI3 device tests above passed, the primary reason the mobile app cannot connect but the mobile browser can connect is security settings.

Android devices
Self signed certs are no longer allowed within Android, so users will need to get a properly signed certificate in order to leverage HTTPS connections. See TLS section of Android gotchas article for details.

Server settings
If you enabled encryption via STunnel or NGROK, you need to choose the correct LAN/WAN protocol, i.e. http or https.

Network
Revisit Networking article and your network setup.
Review Networking Gotchas article and try to self-correct.

Web server advanced
Review the Web Server Advanced dialog. Make sure the mobile device is not blocked via the IP address.

Encoding settings
If the web browser works fine on the WAN but the mobile app does not, the biggest difference between the browser and the app is the media player used to play the video. The mobile apps section explains generally good streaming settings for the LAN/WAN.

At this point the Mobile app and your BI server can talk to each other.

Final tests

User permissions
If you can connect to the server, good time to confirm you have access to the appropriate camera groups. Revisit Camera groups section in the Permissions article -> Users tab section if the mobile app does not have access to the correct cameras.

Camera streams
This is a good time to confirm all your cameras are streaming well (no choppy video) on LAN / WAN. If not, adjust your streams.

App Settings
Now you can play with all the mobile app settings to get the experience that you want. Run through the app functionality and make sure everything is working.

The App Settings section is about all the app settings.
Home tab -> Gear icon.
These settings need to be set correctly so the app meets your needs.

Most of the setting descriptions are intuitive or can be understood by simply turning them on/off. Below I highlight the ones that raise tickets and cause confusion.

Camera settings

In addition to App settings, you also have access to camera settings.

Mapping:

Schedule : Camera settings -> Schedule -> Override global schedule for this camera
PTZ preset cycle : Auto-cycle patrol
PTZ event schedule : Camera settings -> Schedule -> Event schedule
DIO output 1 : Turn first output to on/off

Blue badges

Next steps

See Mobile Gotchas article before submitting a ticket.

Mobile app - Debug logs
Support sometimes needs to know what versions of the software are running (server & app), the make/model of the phone and the debug logs.
Follow steps below when providing the logs.

Go through steps to reproduce the issue.
After the issue occurs, send the debug log to YOURSELF. ? -> Debug log. The debug log will provide error details, if any.
After receiving the email, copy/paste the body of the email into a txt file.
Create/Reply to the support ticket by attaching the txt file. The logs can be quite large. A file attachment is preferred because of the length of debug log.
For iOS users only: Send a support info email from the mobile app as well. ?-> Send feedback to Support. Send the email to YOURSELF, not SUPPORT. This will clarify the software version you are currently running. The Android app already provides the support info with the debug log. iOS will do so shortly. In the interim, send the feedback email to YOURSELF, not support. Once you receive the email, copy / paste body as a reply to the support email so all the information remains together. This information is much smaller then the debug logs so pasting to body of support email is fine.

Optional video: If hard to describe, a video exhibiting the problem is ideal.

Optional temp login: A temporary login to reproduce the issue from our end is always helpful. For privacy reasons, many users set the account to only have access to one or two public facing cameras such as the front door / driveway.

Statistics: Posted by varghesesa — Tue Apr 06, 2021 12:13 am

Remote Access • Android 3.0 Gotchas

2021-02-26T22:17:33+00:00

Introduction
This article is from BI support in order get known issues and fixes to the community as soon as possible.

We did a complete refresh of the Android app on Feb. 12, 2021, starting with version 3.0.14. We appreciate all feedback and are vigilant in incorporating the feedback and bug fixes into the product asap.

Never a bad idea to reset the phone and the app: delete data, cache, reinstall the app and see if functionality returns or issues goes away.

Known Issues

Override Do not Disturb for BI app notifications.

Some users prefer to have their Do Not Disturb (DnD) settings overridden by the BI app, i.e. if a BI alert happens late at night, users still want to be notified.

The Android settings that allow you to override DnD will only apply to the "default" notification sound. We cannot support it when using custom notification sounds, as each notification category can only have one custom sound, where our system allows multiple custom sounds. This is a limitation of Android.

Users that need to override DnD should use the default notification sound.

Geofencing

Below is a list of settings that may or may not apply to your phone that could affect geo-fencing accuracy.

Make sure battery optimization is off.
WiFi must be turned on. It may seem weird, but the low power location management that Geofencing uses is actually primarily based off distances from WiFi signals.
Go to your device's Settings, navigate to your Location Settings. Make sure that your phone's Location is turned on and also in High Accuracy Mode.
Make sure that your device has given the app Location Permission (on Android 10 and higher, you will need to give location permission "All the time")
Newer devices put applications to sleep if they haven't been opened in a while. It is difficult to determine if your device has a setting for this or not. You will have to look through your phone settings to see. For example, the latest Samsung devices use the Smart Manager to put our app to sleep. To add our app to the unmonitored list on a Samsung, go to Settings -> Battery -> Unmonitored Apps -> then add Simple In/Out to the list.
The phone must have mobile data. Geofences will not work without an internet connection.
The phone must NOT be in Airplane Mode. Airplane Mode will disable both WIFI and Location.
Avoid using 'Power Saving Mode' while using Geofences. The Geofences will be a lot less consistent while Power Saving Mode is turned on (as it will automatically lower your location accuracy).
Avoid using 'Task Killer' apps on your phone. Task killer apps can potentially kill the background processes that monitor the Geofences. Any application that has the ability to kill, stop, or sleep our application may prevent Geofences from working.

User feedback regarding geo-fencing on Android devices:

Is there a problem with Samsung devices and the geofence function, because I have never got it to work well, this is my third Samsung phone.
When I had a iphone 6 there was no problem with geofence.

My Blueiris application has access to the location service all the time. The location (lat/lon) in BlueIris server setting is set up to where I live. When I check my location in a GPS tool on the phone it is within the range to be inside, but it still says I am outside. I have tried to reset the Geofence location in the app. Removed and added my device in Blueiris. Changed the Lat/Lon settings in the app.

Also, If I set the profile to be inside anyway it keeps the profile but when I check the device status it says I am outside of the Geofence.

Newer versions of Android have more aggressive battery saving measures. This can affect the frequency at which location updates are triggered. Try disabling any battery optimizations for the app. It's also important that the app's location permission is set to "allow all the time" and not "allow when app is open".

Nothing more we can do on the app side. We react to the location and if the device reports a geolocation outside of the geofence, a transition is triggered. Expanding the radius may help.

If geo-fence is not working for you, BI provides alternative solutions, albeit less convenient. For example, you could simply use the app as a remote control device. When you walk into the house or pull into the garage, you could manually switch the profile and vice versa when leaving.

Other users use the shield icon, which mimics the arm/disarm feature that you see on home surveillance solutions like ADT.

Geofence Gotcha1: You allowed the BI app location services yet the App continues to state permission denied.

The user needs to figure out how to "allow all the time" with their particular Android device. An uninstall / reinstall should allow them to go through the initial steps again.

3.0.22: Notification settings not working. Sound alerts keep playing the default sound only

In Settings, Users can now adjust the sound, LED and vibrate notifications.
If you want to go back to default settings, simply select "Choose Default Notification Options".

Fix: The user needs to figure out how to "allow all the time" with their particular Android device. An uninstall / reinstall should allow them to go through the initial steps again.

Can I roll back to the previous version?

It may be possible to continue to run the old app which Google already approved, however we do not have this APK for distribution. We are very responsive to feedback and fix issues asap.

What happened to the cast icon?

Chromecast sends the video stream to a Cast-enabled device. It's still there, but Android seems to have tighter restrictions similar to SSL certificates as described below.

The Chromecast button will show up in the top bar for a video if:

One of your two connections (LAN/WAN) is HTTPS.
The video you're looking to cast has audio.
The video you're looking to cast is not multi-cam.
The video is a live stream.

In the Camera tab, when I view a group, I cannot select a camera in the group. To view the desired camera, I must scroll through the list and select it.

Longpress camera in group to open camera

SSL certificates / TLS

Are you using TLS or certificates?

Self signed certs are no longer allowed within Android, so users will need to get a properly signed certificate in order to leverage HTTPS connections.

You may want to reconsider whether encryption is needed for your cameras. Blue Iris DOES already encrypt login credentials. Your password and session are secure WITHOUT using HTTPS or Stunnel. The video itself is ENCODED only, so it may be POSSIBLE for a malicious ISP or government agency to spy on your video, but it's safe from general "hacking". You can turn off Stunnel on the Settings/Web server page in the PC and the issue will resolve.

If you really want full HTTPS security on the app, please consider using NGROK instead, it's just much more straightforward than dealing with Stunnel and certificates etc.

However, if you want to proceed with Stunnel, continue reading.

Others users have stated they are using a public key. However, Android decides which CA authorities are valid, not BI. There is nothing we can do from the app side to force Android to trust a user's CA. Either they do or they don't. In fact, we were removed from the Play Store for ignoring errors and forcing Android to accept that connection. More details here. https://developer.android.com/training/ ... onProblems

The Android team is using a PositiveSSL cert from Namecheap.com. Other CA Authorities include ZeroSSL or GoDaddy. The SSL and HTTPS section in Help also has information regarding using SSL with a domain in order to work with Android.

For the java exception, "CertPathValidatorException: Trust anchor for certification path not found.", per the docs, this is caused by:

Using an unknown certificate authority and/or a self signed cert
A missing intermediate certificate authority.

Missing Intermediate Certificates Authority
Google says the solution is "Configure the server to include the intermediate CA in the server chain. Most CAs provide documentation on how to do this for all common web servers."

User 1 example: namecheap.com (Sectigo)
From another user, who got his certificate from Sectigo (previously Comodo) through namecheap.com (as well). Some slight changes to the STunnel config as seen below (obfuscated):
[blue-iris]
accept = ##
connect = xxx.xxx.xxx.xxx:##
CAfile = certname.ca-bundle (had to add this line for the intermediary stuff I think)
cert = certname.pfx

User 2 example: pfSense CA
Simply created a new intermediate CA (on same pfSense install) signed by my original pfSense CA and then from that intermediate CA created a new Server Certificate for my BlueIris stunnel config.

I created a new .pem for the new cert and replaced the existing entry in my stunnel config, so I only needed to change the cert entry:

[blueiris]
accept = 8443
connect = 127.0.0.1:9443
cert = Iris10IntermediateCA.pem

The new Iris10IntermediateCA.pem is formatted just the same as the original:

Code:

-----BEGIN CERTIFICATE-----MIIERzCC……lW9xMlNg==-----END CERTIFICATE----------BEGIN PRIVATE KEY-----MIIEvwIB……BGDO7i4ng==-----END PRIVATE KEY-----

I also needed to trust (i.e. install) the new intermediate CA certificate onto my Android phone using the system settings UI flow. I’d have to do the same for every other Android phone/tablet we use with the BI app.

User 3 example: Let's encrypt service
I followed the instructions from letsencrypt which consists of:

Download and install the certbot client
On the BI machine run windows cmd : $ certbot certonly— standalone. It asks several inputs like domain name etc. Follow the process and this will generate 2 files privKey1.pem and fullchain1.pem
Declare the 2 generated files in stunnel config file :
cert=/etc/letsencrypt/live/example.com/fullchain1.pem
key=/etc/letsencrypt/live/example.com/privkey1.pem
Restart Stunnel and it works well.

Lets encrypt is free but the certificate will expire after 3 months.
Automatic renewal is also possible to setup. I didn't do it at this stage.

Another Let's encrypt user stated:

Thank you, I read the page (this article) and found out all I need is to put the certificate and private key in separate files instead of one pem file.

User 4 example: ZeroSSL service

Use ZeroSSL to generate a CA-signed certificate. Certificates with 3-month durations are free.
Download the certificate from ZeroSSL. This is a ZIP file containing the following files:
Code:
```
ca_bundle.crtcertificate.crtprivate.key
```
Rename private.key to key.pem and move it into the stunnel configuration folder (default location is C:\Program Files (x86)\stunnel\config).
It looks like Android requires the full certificate chain, including the root certificate, which is not provided by ZeroSSL by default. Their website's help section says the following: "If you need the full chain including the root certificate we recommend you use a tool like whatsmychaincert.com to download it". So, go to https://whatsmychaincert.com, enter your server's public IP address, and download the file containing the full chain.
Rename this file to cert.pem and move it into the stunnel config folder.
Edit the Blue Iris section of the stunnel config file to include both files as follows:
Code:
```
cert = cert.pemkey = key.pem
```
Restart stunnel and the Android app should connect successfully via HTTPS.

DDNS & STunnel Gotcha
Since I was using a DDNS to point to my host that I had to use the DDNS rather than the external IP. STUNNEL will only recognize the DDSN name and not the external IP.

User 5 example: No-IP DDNS + Let's Encrypt ssl
stunnel.pem file was composed of my key file and my crt file. It also needed the chain file appended to the end of it.
So my stunnel config uses stunnel.pem as the cert file.

Not working: mydomain-key.pem + mydomain-crt.pem concatenated into stunnel.pem
Working: mydomain-key.pem + mydomina-crt.pem + mydomain-chain.pem concatenated into stunnel.pem

Troubleshooting Certificates

If the above examples do not help resolve your certificate issue, this user was kind enough to document how he resolved the issue.

I went to https://www.geocerts.com/ssl-checker and put in my domain name www.cohovideofeed.com.
That site will tell you the problem.
I got the error:

A valid Root CA Certificate could not be located, the certificate will likely display browser warnings.

Had to add Root certificate and it had to be in the correct order.

Chaining certificates correctly

Some web servers need all SSL/TLS (root, intermediate and end-user) certificates in one file but CAs normally send you all their certificates separated, so you need to concatenate them manually. But pay attention while concatenating them because their order is important!
The correct order of a chained certificate is:

1. end-user certificate
2. all intermediate certificates
3. root certificate

I also had to add these lines:
sslVersionMax = TLSv1.2
sslVersion = TLSv1.2

Works great now

Statistics: Posted by varghesesa — Fri Feb 26, 2021 10:17 pm

Remote Access • Web server & Webcasting

2021-02-24T00:11:37+00:00

Introduction
Besides being a Video Management System, Blue Iris is also a Streaming Server. This allows users to share their camera feeds externally. The best way to understand how to leverage BI's streaming services is via the following use cases.

Webcasting (video streaming) Pipeline

Standard streaming pipeline: IP Cameras -> Media Server -> Endpoint

IP Cameras
The process starts with a video capture device otherwise known as a IP camera. The camera is dedicated hardware that usually captures 15-30 frames per second.
IP Cameras are high performance computers which is why they are so expensive. Compression algorithms are responsible for shrinking each frame to manageable chunks which can be transported over the internet. H.264 and H.265 are standard compression algorithms supported by Blue Iris.
Packaging involves bundling all the compressed frames into manageable sizes that can be transported over the network. Think of packaging as grouping 1-3s of video frames into one chunk of data that is transported across the network. HLS, MPEG DASH, RTMP and RTSP are all common protocols for video streaming.
Network: Responsible for moving the data from cameras to Blue Iris.
Blue Iris. Media server + Video Management System
Blue Iris is also a media server. Media servers can take streams in one format, for example RTSP from a camera and convert them to another format, for example, RTMP so that users can, for example, share their camera streams elsewhere such as YouTube. Media servers are responsible for taking video/audio inputs and streaming the content to various endpoints.
Network
And the final destination is the endpoint playing the video, for example a browser on a laptop, a mobile device, a TV, a gaming device etc.

In terms of the video pipeline as defined in the BI Streaming Overview article:
Source -> Decode -> Encode -> Endpoint

IP Cameras = Source
Media server = Decode + Encode
Endpoint = Endpoint

Web server

Global settings -> Web server tab

Every time a user accesses BI via a remote endpoint (mobile app, web browser), a connection is made between the BI web server and the endpoint.

Web server streams

Global settings -> Web server tab -> Advanced

BI allows for three types of streams from the web server.

Recommendations:
Streaming 0 profile: Leveraged by the UI3 endpoint. I would leave these settings as default.
Streaming 1 profile: LAN. Create a profile that works well in your LAN. Since these endpoints only sit on the LAN, you may want to provide a richer user experience via higher resolution streams.
Streaming 2 profile: WAN. Network bandwidth may be challenging on the WAN so you may want to make stream adjustments, e.g. trade-off resolution (small screen any way) for smooth video.
See mobile apps section below for some streaming recommendations.

Web server encoding settings

Global settings -> Web server tab -> Advanced -> Configure button

H.264 Encoding Settings

H.264 video encoding
Hardware acceleration: Usually set to No. Many GPUs do a poor job of HA encoding which leads to streams that cannot be played by media players. Best to leave off.
Quality: Value from 0 - 100. Lower the value, lower the quality. The marginal difference in quality after a certain point is minimal. For example, 100 does not produce an image that is twice the quality of a 50 setting. In most cases, quality = 50 is plenty good.
Rate control: If selected, you are choosing a Constant Bit Rate (CBR). Choose if you have bandwidth concerns.
If unchecked, you are using a Variable Bit Rate (VBR).
Frame type layout
Maximum keyframe interval (GOP): 300
Maximum B-frames between P-frames: 0 (only applies to Main profiles or above)
Profiles: H.264 provides features that are encapsulated in profiles.
Baseline restricts the encoder to certain basic features only. Baseline can easily be played back on most devices. Main and High add features on top of Baseline. Baseline profiles were widely used for mobile devices. However, now more and more mobile devices support Main or High profiles.
Main: B frames (above) are only allowed in the Main profile or above. They can be used to save on bandwidth but harder to decode. Widely used for web streaming.
High profile is often used in broadcasting. Used on high definition TVs. Also adopted by the Blu-ray disc storage format.
Presets: Presets are a collection of options that will provide a certain encoding speed to compression ratio. A slower preset will provide better compression. This means that, for example, if you target a certain file size or constant bit rate, you will achieve better quality with a slower preset. Similarly, for constant quality encoding, you will simply save bitrate by choosing a slower preset.

Audio encoding

Audio: AAC or MP3
Bitrate (kbps): 192

Streaming formats

BI support M-JPEG, H.264 and other formats. The Http interface -> Direct image and video requests section in the Help file has details.

Use cases

UI3 web endpoint

This is one of the most common ways to access cameras remotely from a web browser (laptop) or mobile browser (phone).
Hit the Help button from Global settings -> Web server tab for details.

The Blue Iris Web Interface webinar walks through the user interface and all its features/functionality.
See Web Interface (UI3) gotchas article for learnings from past tickets.

Large screen TVs

Many users are using TVs to display their cameras. Since these devices are usually on the LAN, they want to take advantage of their high resolution screens with high resolution video streams, since they know their network can handle the load.

With UI3, it is easy to experiment with higher and higher resolutions to determine what works best with your monitor. Simply choose different resolutions by using the gear icon in the lower right corner.

One final comment. If you have a monitor or TV that does NOT have internet connectivity a popular solution is to purchase an Amazon Firestick and run UI3 from there to the monitor. Firestick + Silk browser + UI3 interface is the goto solution for many resellers when trying to display the cameras on a TV or monitor.

Mobile apps (iOS / Android)
The streams used by the mobile apps are set in Camera settings -> Web server tab -> Advanced page. See Web server streams section above for details. The default resolution for Streaming 0 is 720p.

If the request from the app (720p default) is <= the sub stream resolution, the sub stream is streamed. Below are LAN/WAN suggestions that generally deliver smooth video based on higher/lower network bandwidth.

LAN / WAN streaming profiles

What's great about BI is it allows the ability to assign different streaming profiles for the LAN / WAN. A common convention is to assign Profile 1 for LAN connections and Profile 2 for WAN connections.

Video Pipeline: Camera video / feed -> Decode -> Encode -> Endpoint (high resolution tablet / low resolution phone)

A tablet with a bigger screen and always connected to the LAN may have value in a higher resolution stream. Being on the LAN, the network considerations are usually not as stringent either.

However, a WAN profile may entail a lower resolution stream. Most WAN profiles are used by mobile phones with small screens. Why unnecessarily send a stream with a high resolution that provides no additional value on a phone screen and also adds unnecessary load to the network and perhaps results in choppy video.

LAN settings

As stated above, according to our convention, LAN settings would be assigned to Streaming Profile 1

To get high resolution, smooth video, try the following settings for one of your web server video streams.

Use variable bit rate instead of constant bit rate. Unselect Rate control. Crank up Quality value. Gotcha: If network bandwidth too high, adjust.
Profile = high Uses more bells and whistles such as b-frames to optimize bandwidth while delivering quality. Gotcha: If endpoint cannot decode, adjust.
Preset = veryfast. Set to lowest to maximize quality. Gotcha: If CPU utilization is high adjust.
Uncheck Resize output frame. Send the full camera resolution to the device. Gotcha: If network bandwidth spikes, adjust. If the player at the endpoint starts to choke, adjust
b-frames are great for increasing quality and optimizing bandwidth. Gotcha: However, if you have a PTZ camera, b-frames can cause delays displaying the new view after a camera position changes.

Don't forget to choose the appropriate stream for the mobile app. Below is a reminder on how to do so.
Home tab -> Gear icon -> LAN. Profile 1 is the LAN stream.

WAN settings

The below settings generally provide a good user experience on mobile phones connected to the WAN (cellular network).

Differences between WAN vs LAN:

Switch from variable bit rate to constant bit rate to reduce network load.
Changed profile to superfast. Trade quality for lower CPU load and processing time.
Resize frame. Reduce resolution since stream is going to a small screen any way.

Multiple servers

Because BI is also a media server (RTSP server), you have the flexibility to pull video from one BI server to another.

Use case: Enterprises with large deployments may have multiple servers because they have >64 cameras. However, they may want to pull video from one server to another. Why? Because suppose five cameras belong to a user group and 3 cameras reside on Server A and the other two reside on Server B. In order to display all 5 cameras to the users belonging to this group, admins will pull the two cameras from Server B to Server A. The admin can then create a camera group for the corresponding user group, thus providing one pane of glass for all the cameras belonging to the group.

In order to pull a camera from one server to another, first confirm Webcasting is enabled for the camera.

Attain the following information for the remote server:

IP / Port of the web server
Username / password for a user that has access to the camera.
Pull camera or group stream
rtsp://ip:port/cam1 (camera)
rtsp://ip:port/groupname (group)

In example below, I have a camera called ADF7.
I was testing locally so IP address was 127.0.0.1. My web server is running on port 7000.

Embed video in your website

Many users like to share a camera on their website. Below are two code snippets showing how to do so.
Change url to meet your environment

server is a placeholder for the ip address or hostname of your BI server
The web server listens on port 81 by default. Use the port you specified if different from 81.
ADF_Cameras is a placeholder for the camera name or camera group name in your server.

tag

Code:

tag

Code:

livestream.htm is a web page that loads a video player and feeds it an HLS stream from Blue Iris. This is the best thing to embed in an iframe if you want minimal user interface functionality. This method adds several seconds of video delay though, making it not ideal for all use cases.

The page source of livestream.htm includes the usage details. It takes different URL parameters than UI3.

livestream.htm supported URL parameters:

cam=short: Select camera or group with [short] name
autoplay=0: Disables autoplay.
audio=1: Unmute at startup. Also disables autoplay.
mode=2: Hide video player controls
mode=3: Use browser's standard video player controls

Two other considerations when embedding streams:

1. Authentication must be dealt with, either by enabling anonymous access or by turning off secure login and embedding credentials in the URL.

2. If the web site is hosted with HTTPS, the link to embed a video stream must also use HTTPS which will mean setting up stunnel or a similar secure proxy in front of Blue Iris.

Embed video in your website via RTSP.Live site

If the above is too complicated, you can also try the RTSP.Live free service.

YouTube - Streaming

Use case: Pushing Blue Iris live camera stream(s) to YouTube's media server via RTMP.

YouTube provides URLs to connect to 3rd party software such as Blue Iris.

BI setup is just as simple. Camera settings -> Webcast tab.

You do need to supply the correct stream settings that will work with YouTube.

Audio: Set to AAC. 128 kbps
Max bitrate (kbps): 2048. YouTube prefers 9500 kbps so go higher if network can support bandwidth.
Maximum keyframe interval (GOP): 60
Profile: main
Preset: superfast
Zero frame latency: Unchecked
Resize output frame width x height: Checked. 1280 x 720. YouTube prefers 2560 x 1440 (double 1280 x 720) so go higher if network can support bandwidth and camera has the resolution. No point increasing the resolution if your camera is 1 MP (1280 x 720).

YouTube will provide Stream status feedback based off which, you can adjust BI settings further.

Amazon Echo Show + Monocle Coming soon!

Pro tip 1: Leverage UI3 to help set optimal encoding settings on your mobile device

Global settings -> Web server tab -> Advanced tab
Encoder profiles: Configure button.

The encoder dialog box is a bit daunting. What are good values for all those settings?
If like most, you are not well versed on encoder settings, use the UI3 interface for help!

The issue here is if you bring up a browser on your phone and go to the BI web interface, playback and live view work fine. When doing the same through the app, the streaming is choppy, jittery etc.

Test 1: Need to make sure live stream and playback are first smooth on the BI Server. Garbage in = Garbage out.
Test 2: If you open a browser on the phone/tablet and go to the BI web interface (UI3), are the live view and playback a good experience. If so, then you know the problem is not with the network.

If you are still reading, then the problem probably means the player used by your device cannot handle the incoming stream well. The short answer is to go to Global settings -> Web server -> Advanced -> Encoder profiles (Choose Streaming 1 (LAN) or 2 (WAN)) -> Configure dialog. Use the below settings to start and see if they work.

Below are the changes from the default settings:

First, I turned on Constant Bit Rate (CBR). This settings caps the amount of data going to the player at 1024 kbps.
Next, I reduced the resolution to 856 x 480. You are streaming to a mobile device, so reducing the resolution will probably have no affect on your viewing experience. I played with "Retain aspect ratio within frame". On iOS devices, the setting seemed fine. But I noticed instability and crashes on some Android devices. It does not really change/help the user experience, so my conclusion was to just leave it off unless required for another reason.
Finally, I set Hardware encode = No. The hardware encoding often will not play on mobile players. Best to encode using BI software.

Reference: If you want a deeper understanding of the settings in the encoder dialog or how encoding generally works, a great reference article was created by IPVM titled "H.264 vs MJPEG - Quality and Bandwidth Tested". If you are not familiar with IPVM, they are a great resource for research and information regarding surveillance and security cameras.

So how did I choose the values for the bit rate and resolution?

I cheated and used the expertise of the BI development team! If you click on the gear icon in UI3 (lower right), you can select any predefined resolution and hit the pencil button up top. You then see the encoding settings for the selected resolution. I just copied those values into the encoder dialog on the console.

Once I made the stream adjustments, I went to the mobile app settings and chose the appropriate settings for my LAN and WAN connections.

Statistics: Posted by varghesesa — Wed Feb 24, 2021 12:11 am