Network connectivity
The easiest way to connect cameras to the network is to follow the manufacturer's installation instructions. Below are ways to confirm whether the cameras are connected properly:No web interface
If the camera does not have a web interface, this often means the camera is not open for 3rd party integration and can only be accessible via the proprietary phone app provided by the vendor. This may be a good time to approach the camera vendor and ask how to connect the camera to 3rd party VMS systems using RTSP. One user asked how to connect the camera to VLC. After much prying, the vendor finally gave up the information. Camera vendors would prefer you use their software and lock you into their ecosystem.

RTSP or other video formats
Leverage 3rd party players such as VLC to connect to the camera. If VLC cannot connect, more likely than not, BI will not be able to do so either.

Some vendors may still provide access to the RTSP port to pull the video stream. TP Link is one such vendor that has a proprietary app interface, yet still provides RTSP access to the video stream. If the camera has a web interface, the RTSP port may be shared.

Port 80
The default web port for all internet devices is often the port used by cameras to access the web interface as well.
Keep in mind many camera vendors use Port 80 to relay ONVIF information as well. By default, BI will check for ONVIF support on Port 80.
Also keep in mind, vendors can use another port for the web interface. For example, Foscam uses port 88 for the web interface. Know your cameras.

Port 554
Port 554 is the default RTSP port. This is the port to access the video stream assuming the camera allows 3rd party access.
If the camera uses another port for the video stream for heightened security, often the camera provides the port information via ONVIF.
Sometimes you may need to review the camera documentation and/or reach out to the vendor.

Port 8999
If cameras choose NOT to convey ONVIF information via port 80, they often choose port 8999 which is also checked by BI by default.

ONVIF Gotchas

ONVIF Gotcha 1
KNOW your camera. If the camera states ONVIF support, but when hitting Find/Inspect, you do not see rich ONVIF information being pulled from the camera (ONVIF section below has details), then you have not established an ONVIF connection. Below is a camera that happens to use port 8080 as the default ONVIF port.

If you do not change the Discovery/ONVIF value in the IP Config Dialog from the default 8999 to 8080, BI will not know how to connect to the camera and pull the ONVIF information.

Another user had a camera that had ONVIF on port 8120. Ironically, he discovered the ONVIF port and successfully connected to the camera using ONVIF Device Manager (ODM).


Ironically he did not tell BI, ONVIF was available on port 8120 and thus BI could not connect until he changed the IP Config Dialog.



ONVIF Gotcha 2
It turns out camera vendors are adding another layer of security to their ONVIF controls. The ONVIF ports may be open by default. However, the amount of information available through the port can be limited until security permissions are set on the camera. In the Hikvision example below, access to the ONVIF capabilities were limited until we added the user account used by BI into the ONVIF user list with admin privileges.

Axis cameras also have this functionality. The username/password placed in BI needs to be an ONVIF account in order to pull in the ONVIF features.

Reolink
99% of cameras only support the RTSP protocol. On occasion, a vendor will support RTSP and RTMP. Reolink is one such vendor and the RTMP protocol seems to provide a healthier stream.
Checkout the Reolink Gotchas article for best practices on connecting Reolink cameras.

Other vendors. (work in progress)

BI only works with the H.264 and H.265 standards. Camera manufacturers have tweaked their encoding to optimize bandwidth for their apps. H.264+, H.265+ (note the + sign) Smart Codec etc are all proprietary encodings that can only be used by the vendor apps. When customers report the cameras work on their app but not in BI, the encoding is often times the reason. The No Signal Error is almost always due to the fact that the cameras are using a proprietary encoding.

Also best to start with H.264 encoding before moving to H.265. Also, choose H.264 Main/Baseline instead of High if given the choice. Provide BI the easiest connection available first and increase the complexity if and when needed.

Older Intel CPUs (before Skylake) with QuickSync do NOT have H.265 support. If the camera is set to H.265 encoding and your QuickSync does not support H.265, the Server may crash. See Hardware Recommendations article for details.
In order to get the server running again, you may need to turn off HA in the registry. See details.

Keep settings simple such that all the streams have the same FPS. Choosing between 30 fps or 15 fps is a user preference. For most surveillance situations, 10 - 15 fps is plenty good.
Setting all streams to have the same fps makes time reconciliation easier for BI. Turns out certain vendors like Hikvision set different fps (10, 15) for different streams. Different fps settings unnecessarily complicate playback synchronization with dual streams.

A key frame ratio >0.5, ideally 1.0 leads to a healthy video stream that delivers a good user experience. BI will tell you the key frame ratio. In this example, all the camera key frame ratios = 0.1


Rule of thumb: Make sure the key frame (i-frame) interval on your camera equals the FPS for the camera. This will deliver a key frame ratio equal to 1.0.

The setting on the camera is often referred to as i-frame interval or key frame interval. On more technical cameras, e.g. Axis, the setting is referred to as GOP (group of pictures). GOP means how many compressed frames are allowed before the next key frame (full frame).


Examples:

• Camera fps = 30. key frame interval = 30 (1.0 fps). Can consider key frame interval as high as = 60 (0.5 fps)
• Camera fps = 15. key frame interval = 15 (1.0 fps). Can consider key frame interval as high as = 30 (0.5 fps)

Every camera vendor has a different UI. However, observe the default settings for the i-frame interval for each of the streams for the camera vendor (below). All the streams are 15 fps. However the i-frame interval is 30/60/120! The only setting that may provide an ok user experience is the main stream. If dual streams are connected, the live view will probably be choppy, slow, sluggish! The i-frame interval for the two streams chosen to be used by BI for below example needs to be lowered to 15.


FYI, not all cameras allow the ability to set key frame intervals. Reolinks for example do not allow so for sub streams. Key frame ratios for sub streams will be 0.25. You can choose to disable sub streams if your server can handle the load. If not, you can compensate for low key frame ratios with larger pre-trigger buffers as stated below.

Pre-trigger buffer

This topic is discussed in the Record tab article because it's a recording setting. However, the Pre-trigger buffer goes hand in hand with the key frame ratio so placed here as well. Because D2D has become such a popular record setting (CPU savings), if the pre-trigger buffer is not set correctly based on the camera's key frame ratio, lots of issues may occur. Largely set based on user preference (5s is recommended). Rule of thumb:
Pre-trigger buffer >= 1/key frame ratio
For example, if the camera stats state 0.5 for the key frame ratio, 1/0.5 = 2s. The pre-trigger buffer for the camera should be >= 2s. Or just use a default 5s pre-trigger buffer for all cameras and increase if you cannot control the key frame interval on the camera and it is really low.

Creating healthy streams by setting the key frame ratio (>0.5) and a correct pre-trigger buffer removes so many issues.

• Users have noted missed triggers.
• Users have noted no recordings (0s recordings) for their alerts.
• Email alerts have black image attachments.
• Email alerts have images from wrong earlier alerts.

The reason having the right key frame ratio and pre-trigger buffer is so critical is because not doing so, results in BI not having the desired frames when needed. If the frame does not exist, bugs pop up!

While just a warning symbol, i.e. BI will stream the video, this can have very adverse affects. This warning is a clue that some of your camera settings (above) are not working well with BI. If you are receiving these warnings recently, it is because we are now also monitoring key frame ratios when the setting has an affect on your configuration, like direct to disc or limit decoding. The warning symbol appears if the key frame ratios drops below 0.4.

Fix: Revisit your camera encoding settings, especially the Key frame ratio section right above!

Reolink known issue: The sub stream for Reolinks often run at 0.25 kfps and the key frame interval is not configurable. Sub streams are a huge benefit for CPU load. So overall, if the video is not choppy, lagging etc, we recommend using sub streams.



From Help file:

The Log page in Status contains one or more warning messages or one or more
cameras has an error condition or warning, such as low frame rate or a push
webcasting error.

Historically, the warning message was frequently due to the camera's FPS. BI constantly measures the fps of your cameras. At a peak time maybe the camera was sending 15 fps. Maybe because of network congestion etc. the fps for that camera temporarily dropped to 2 fps. The warning message would pop up. Unless you observe persistent frozen cameras or lagging cameras, the issue resolved itself and you can ignore. BI will display this warning when the FPS is 15% of the observed actual max frame rate.