It is crucial to understand the camera stats. Poor video feeds can lead to many other issues.

BI provides two ways to understand the health of your camera streams. For an individual camera, Camera settings -> General tab provides all the relevant information for an individual camera.


Main stream stats:

• Resolution of camera: 2.1 MP
• Frames per second (fps): 31.76
• Key frame interval per second: 0.70 fps
• Bit rate: 381.9 kB/s

Sub stream stats (if connected):

• Resolution of camera: 0.3 MP (640 x 480)
• Frames per second (fps): 29.77
• Key frame interval per second: 0.60 fps
• Bit rate: 42.4 kB/s

Frames per second and Key frame interval per second have the most bearing on smooth streams. For most people, an FPS value above 12 fps and a key frame interval above 0.5 and ideally 1.0 are good guidelines for a good streaming experience.

To get a holistic view of the performance of all your cameras, go to Status -> Camera tab.


The camera stats provide a quick overview of all your camera connections. You can easily tell which cameras are problematic, e.g. low fps or low key frame ratios.

Column detailsStatus counters (not shown in image)

Connecting NVR/DVR devices to BI is similar to connecting cameras. The Camera connector article has more details regarding the IP Config dialog if you are new to BI.

Below is the list of BI settings that can affect streaming.

Hardware decode (aka hardware video acceleration, HWVA).
Used to turn HA on/off for live camera feeds.

• Global settings -> Cameras tab. Turn on/off globally for All cameras.
• Camera settings -> Video tab. Turn on/off for a particular camera.
  Camera setting takes precedence over global setting.

Mix and Match GPUs
If you have multiple GPUs on your machine, it is possible to assign different cameras to different GPUs to distribute the load. Turn HA off globally and assign GPUs on a per camera basis.

Intel Processors choose Intel + VPP
If for some reason you experience instability, try the Intel selection without VPP.

AMD Processors choose DirectX
Leveraging the iGPU on a CPU (QuickSync, DirectX) provides big benefits.
Not a big fan of using external graphics cards (NVidia, AMD) for encoding/decoding.
The Choosing hardware for Blue Iris article referenced in Hardware Recommendations article has some interesting insights.

The software now turns off HA automatically for a camera if it determines the stream is not compatible and this is logged to Status->log as well.


If you want to fix the problem, you can go to the camera settings on the camera and adjust the encoding to a more simple format that may start working with your hardware. A simple example is if the camera was set to H.264 High encoding, adjust the setting to H.264 Baseline. If you were using H.265, switch to H.264.
Or wait for the next driver update that may fix the issue caused by the current driver.

See GPU link for even more information on GPU hardware.


Limit decoding unless required.
Used on the Live view stream. However, largely not needed anymore with the popularity of dual streams.
Limit decoding (as stated in Help) will only decode key frames. One side affect is if your kfps = 0.5, then you are receiving 1 key frame every 2s.
Thus, if you have a time overlay on your camera view, you will see video updates every 2s, not every 1s.


Overlays
Overlays can slow video. If your cameras are lagging, you may want to turn off overlays.


Also BVR
Used to turn HA on/off during video playback. 99% of the time it is better to leave this option off. The playback window allows you to scan backwards and forward. This work load is not conducive for hardware acceleration. Hardware acceleration is effective with smooth, consistent streams of video.


Image size (resolution) & FPS

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.

This article walks through the PTZ/Control dialog in Camera settings. This article is an extension of the PTZ/Control section in the Help files. This article focuses on use cases and how to accomplish common/popular tasks or make users aware of capabilities in BI. If you want to understand how an individual feature works, refer to the Help documentation.

If you prefer to listen instead of read, see the PTZ and Camera Control webinar.

If you were directed here from a ticket, try to self-correct using information below. The Next steps / Submitting a ticket section (bottom of article) explains what is needed to move forward.

You may be wondering why this dialog is called PTZ/Control. The PTZ part is obvious. The Control part has to do with features and functionality that exist on the camera that go beyond Pan-Tilt-Zoom. Over the years, BI has provided access to these features via their custom drivers. If you choose a BI driver (discussed in detail below), then additional features on the camera may be available.

To know what additional camera features are available, simply Right click on any camera -> PTZ/Control. The illustration below shows all the possible functionality available from a camera. Selecting the feature will confirm whether the functionality is available with your driver.

PTZ via ONVIFBI driversFinal steps Checkpoint: BI has PTZ controls for the camera working.

This section explains many of the knobs and buttons that exist in the dialog. We also highlight some of the popular solutions and explain all the settings required to implement the solution.

Custom PTZ DriverPTZ OptionsZoomSuspend motion detection

Many customers with PTZ controls would like the camera to move between presets, often referred to as PTZ Patrol. Blue Iris provides this ability. In addition, the user can associate different cycles to different profiles as well. For example, you can have one patrol sequence for the day profile and a different sequence for the night profile.

Work Hours Schedule
Many customers create a business hours / off-hours schedule with two profiles, (1) Away and (2) Work hours.

Goal:
Work hours has a unique auto-cycle patrol: 1 - 3 - 7 - 9
Away has another unique auto-cycle patrol: 1 - 5 - 9 - 14



To create the auto-cycle presets for the Profiles follow the steps below: Checkpoint: Auto-cycle created.
We created two profiles: Work hours & Away.
Work hours has a unique auto-cycle patrol: 1 - 3 - 7 - 9
Away has another unique auto-cycle patrol: 1 - 5 - 9 - 14

Just like you can define trigger alerts for non-PTZ cameras by setting the BI motion sensors in the trigger tab, you can do the same with your presets. Let BI do the monitoring and allow you to manage the alerts!

Coming soon! How customers are creating triggers to home automation systems and other devices based on Presets.

This section documents learnings from past tickets.

Gotcha 5: ONVIF PTZ presets disappear
Gotcha 4: No PTZ Functionality
Gotcha 3: PTZ stopped workingGotcha 2: PTZ appears not to work. However, there is just a long delayGotcha 1: Cannot set a preset

If still an issue:

Reolink H.264 High profile (default setting) causes no signal. Switch to H.264 Baseline.

Left channel main: /bcs/channel0_main.bcs?channel=0&stream=0&user={id}&password={pw}
Left channel sub: /bcs/channel0_sub.bcs?channel=0&stream=0&user={id}&password={pw}

Right channel main: /bcs/channel1_main.bcs?channel=0&stream=0&user={id}&password={pw}
Right channel sub: /bcs/channel1_sub.bcs?channel=0&stream=0&user={id}&password={pw}

Most cameras connect via RTSP today. However, Reolink provides RTSP and RTMP support. From our testing, RTMP seems to perform better. Many users were complaining about the No Signal message when using RTSP from BI. When switching to RTMP, the cameras worked perfectly for the mainstream and the sub stream.


In order to leverage the RTMP stream from Reolink, the Network IP Configuration dialog needs to look like below (note the RTMP choice for Model and usage of Port 1935 for media):


I believe the RLC 4 & 5 series both provide ONVIF support. If so, you can simply leverage ONVIF to populate the main and sub stream URIs. Please review Camera Connector article for details on connecting cameras correctly.

Note on PTZ: If ONVIF information is not seen being pulled over in the Find/Inspect dialog, one user stated it was because the RTSP port was NOT enabled in the web interface. ONVIF information came over on port 8000 after enabling RTSP. More importantly, PTZ controls came over via ONVIF.

Without ONVIF, selecting the "*RLC-410... Baseline RTMP" Model will also populate the mainstream. Simply copy/paste mainstream to sub stream. Change "main" to "sub" in sub stream URI as seen above. However, PTZ controls will not work.

According to another user, changing settings (e.g. encoding from H.264 High to H.264 Baseline) on the RLC-423 requires a restart. There may be a firmware bug that resets the PW, IP address from static to DHCP among other settings when performing a restart. Reolink support states no more support for this camera and recommends upgrading the camera.

According to a user, the RLC 423 Make/Model does not work. However, the camera connects via ONVIF. Unfortunately, PTZ controls do not come across through ONVIF.

Users are reporting a bad experience when connecting cameras to Blue Iris. One user reported receiving new firmware (v3.0.0.206_21031688). The firmware resulted in main/sub fps speeds of 20 FPS. Prior, the speeds were 4/15 FPS respectively. On BI, the mainstream lagged by 10s, drops to 2-4 fps and eventually causes BI to crash. Similar issues, i.e. crashes, BI freezing up stated by other users.

Another user said RTSP streams work well using settings below (810/620).

2021-May-26 Update

Below IP Config Settings seem to work according to another user.


Anecdotal: One more quick feedback…checking the Decoder compatibility mode on the Video=>Configure page, seems to allow the dual stream to work on the 810-A. Not sure what happens by checking this box, and it does come with some occasional brief video glitches, but the CPU usage drops and it seems that the sub stream is being monitored. Hope this condition can eventually be fixed.



2021-May-5 Update

The below settings tend to work. Yes, h265 is in the main uri, while h264 is in the sub uri. NOT a typo. Make sure to select Decoder compatibility mode.


The camera settings for sub/main (left / right) is below:

With the attached config I've pretty much eliminated video artifacts (minus that annoying everything turns grey in the x265 stream periodically) and this audio issue is the last one I'm hunting down.
I've attached my config for the RLC-820A since it seems to keep its sync the longest.
One thing I can tell you is decoder compatibility mode is no longer required with the later firmware, and just introduces more artifacts

Also, I've asked around, and the audio drift is very much an issue on the Reolinks, but I think I may have figured out the root cause and it's odd. I need more time to test to say it's "stable" but it seems to be related to the Reolink keeping time. They seem to keep "fast" time and get ahead. By default, once a day, they reach out to the NTP server and sync their time. Something happens where it adjusts the video, but not the audio stream when it syncs the time (even if ignoring OR subscribing to the RTSP time codes), causing the audio to end up further and further ahead with each time sync. Adjusting my time sync interval to test it, has caused the audio/video to stay in sync, for how long, I don't know.

The RLC820A doesn't need the time codes, and honestly in the below config does everything mostly well.


Users also select the H.264 RTSP model. Some hardware acceleration cannot decode H.265 so H.264 is selected.

Unlike the RLC-820A, the RLC822A DOES need the RTSP timecodes, or the audio will go out of sync. The audio is also constantly blipping a bit when using the time codes, but it at least stays in sync. Also, I made a massive network buffer, and a 15 second pre trigger. It used to be 12.5, but I would occasionally end up with the weird grey everywhere and only the moving object visible. The bigger pre trigger (or network buffer? I did both at the same time) seems to ensure there's a keyframe. Also I've adjusted the keyframe interval on the camera itself and it's 1 during the day, but still takes a dump at night with the newer firmware. The key thing to all of this is not letting the reolinks update their time and it seems to work better.

And LOL at notifying Reolink, if I knew what I know now, I'd never buy any of their terrible products. One of my cameras arrived broken and I've had the misfortune of dealing with their support already, I'm fairly certain they'd do nothing with the above mentioned information.


Users also select the H.264 RTSP model. Some hardware acceleration cannot decode H.265 so H.264 is selected.

E1 Zooms should now work in BI. Some gotchas include switching the H.264 profile from High (default) to Base. According to one user, the setting is buried in the camera's web interface. The setting can be found in the Playback tab -> Basic settings page as seen below.


When connecting the cameras, select the BI drivers instead of ONVIF to connect via RTMP instead of RTSP.

Update: 2022-Jan-8. Thanks again to our user community for feedback and learnings for the next user.


Reolink's PC Client software shows E1 Pro encoding settings.

The B800 series have been replaced by the 810/820 lineup so probably not widely used anymore. However, it turns out while the camera claims ONVIF compatibility, in fact the camera is closed and proprietary.

Here is a great article on one engineer's journey to reverse engineer the B800 to access the streams.

Reolink explicitly states on their website that the B400 is only compatible with their NVR.


You can always ask Reolink if they have updated camera drivers that allow connectivity to 3rd party software via the RTSP / ONVIF standards.

This document outlines the steps to connect IP Cameras successfully to Blue Iris (BI).

If you prefer to watch the webinar associated with this article, see the Camera Connections and Streams webinar.

More and more cameras are coming out with higher and higher resolutions (> 2MP). These cameras often provide two and sometimes three streams. The reason for the multiple streams is so camera vendors can provide better images and clarity (high resolution, more network bandwidth) and also provide a good user experience for remote access (mobile phones, web interfaces). This tension between higher resolutions and good user experience has resulted in cameras providing multiple streams.

The below steps explain how to connect cameras to BI with a single stream or multiple streams. If you have an older camera, multiple streams may not be available. For example, cameras with a resolution of 1 MP or less usually do not have or require dual streams. Most networks can support <1MP resolution cameras.


Closed environments

Some camera manufacturers have a closed environment, i.e. no 3rd party access to their cameras. Amazon Ring, Arlo and common examples. Some vendors are hybrid, they prefer to control the customer experience, however they also provide a public URL to their cameras for 3rd party access. Google Nest is the most common example.

Camera manufacturers that support 3rd party access will post ONVIF and/or RTSP support on their web product listings or documentation. If their product postings state vendor app, cloud solution with no mention of support for standards, well, those are tell-tale signs that the camera probably will not connect to BI.

How Blue Iris leverages the different streams
The biggest advantage of sub streams is the drastic drop in CPU usage for the same cameras. This savings is largely attributed to using the sub stream for live view in the all camera (mosaic) view which is the common view on most displays. By leveraging the sub stream at a much lower resolution, the decoding and displaying of the stream is much easier on the CPU. In addition, a significantly reduced amount of RAM is used on a per camera basis.

Specifically, in Blue Iris the main stream is used for:

• direct to disc recording so playback and evidence gathering is in high resolution
• single-camera live viewing and recording playback so if a user is focused on one particular camera, he/she has the clearest view possible
• audio recording

The sub stream is used for everything else:

• multiple-camera view (mosaic view)
• motion detection
• alert snapshots etc

Network IP Camera Configuration Dialog


Follow basic steps below to connect your IP cameras.

In order to be successful, the camera encoding settings are set to work with BI.
Furthermore, you have the following information for each camera.

• IP Address
• Username
• Password
• Web, RTSP and ONVIF ports

If not, work through Camera setup article.

UPnP / WS Discovery connections
Devices on the network may use various standard protocols such as WS-Discovery and UPnP (Universal Plug N Play) to let other devices know they exist on the network for connectivity. If your router also supports these protocols, then it is possible for BI to find these devices (unlikely and not recommended due to lack of security). In summary, there are two dependencies that need to be met before a camera is visible to BI:

• The router has to ALLOW UPnP traffic. Many ISP routers, e.g. AT&T, do not allow UPnP traffic because it presents a security risk. Crafty actors on the internet may find ways to discover devices on your network and get control.
  Mesh routers, e.g. Orbi Mesh, do allow UPnP traffic, because these routers sit behind the ISP firewall.
• Your cameras have to have UPnP enabled otherwise how can the camera be identified.

Most users start with Step 2.

Provide the username / password of the camera and select Find/Inspect.


The Find/Inspect button will discover all cameras and/or devices existing on the network that support the above stated protocols.
Select the camera you want added to BI and BI will take care of the rest.

Besides security, another reason I am not a big fan of network discovery protocols is because they are "brittle". If the BI server restarts/reboots for any reason, the UPnP connection to the camera is usually broken by the router and a new connection needs to be established.
Using the methods below hardens the network setup so connections are automatically re-established after power outages and equipment restarts.

ONVIF is a standard protocol that allows third party software such as BI to gain access to capabilities from a camera for use within BI. Camera vendors may provide different levels of ONVIF support. Some may only provide the URI of the RTSP streams (i.e. access to the video streams). Other vendors may include more camera capabilities such as PTZ and/or audio controls with their ONVIF support.

ONVIF is by far the easiest way to connect cameras to BI. If the camera is not discovered in Step 1, continue providing more information. Provide the IP Address in addition to the username/password for the camera. Many vendors support ONVIF either through port 80 or 8999. Thus, BI will check those two ports by default. If you know ONVIF is available on a different port for your camera, replace 8999 with the value for your camera.

Hit Find/Inspect.


If an ONVIF connection was not established, the Find/Inspect dialog will tell you so.


No ONVIF InformationIn contrast, below is a sample response from the camera when an ONVIF connection is established. Look at the volume of information transferred to BI.

Key information gathered via ONVIF to make connecting to cameras easy:

• Manufacturer: Many cameras are rebrands from another company (Original Equipment Manufacturer, OEM). The Manufacturer field often reveals the OEM. In below example, the User Guide stated Alptop but the OEM was iCamera. Very important information to know when choosing the appropriate driver in Step 3.
• RTSP URI(s): Probably the most important piece of information. This tells BI how to get access to the video from the camera. Without this information no video feeds will appear.
  Also note, many cameras provide multiple streams. In this example, they are referred to as MainStream and SubStream. Make note of both streams. Occasionally, the sub stream does not auto-populate in the IP Config Dialog and you have to manually enter the URI.
• PTZ settings. Almost always part of a camera's ONVIF implementation, these settings make it easy for 3rd party software to get access to the PTZ controls of a camera.
• Audio. Not frequently shared via ONVIF, however a great bonus to connect to a camera's microphone or speaker if available.

Camera streams and dual streamsMake note of all the other information that could be pulled from the camera depending on the level of ONVIF support.

• PTZ controls and presets
• Sometimes audio is pulled from a camera with speakers via ONVIF
• Occasionally, 2-way talk is also pulled from a camera with speakers and microphone via ONVIF. (rarely)

No ONVIF PTZ informationHit OK and the camera should connect.

If you successfully connected your camera using ONVIF and the video and all the PTZ controls (if you have a PTZ camera) are working fine, then there may not be a need for this step. Generic/RTSP for the Make/Model may meet your requirements.

However, if there is more functionality you want to extract from the camera or you just want to experiment and see what other functionality has been leveraged from the BI drivers, then continue. See PTZ / Controls article to learn what other controls may be accessible via BI drivers. BI has been around for 20+ years. Over the years we have found ways to connect to cameras that do not have ONVIF and gain access to additional functionality provided by the cameras.

Another reason for this step is the PTZ commands from the camera via ONVIF are ok, but there is more functionality which you would like to leverage. Maybe the Make / Model is in our BI list. The BI drivers may be even more robust because a past customer had the same request. Worth a shot to test.

Audio and other advanced functionality
Finally, cameras that support ONVIF share their capabilities such as PTZ allowing BI to access those capabilities without needing the user to do anything. However, camera vendors frequently share their PTZ capabilities but not Audio and other functionality. It is very rare for advanced functionality such as two-way audio to be shared via ONVIF.

BI over the years, has reverse engineered many cameras to provide the advanced capabilities. This is one reason for the exhaustive list of Makes and Models listed in the IP Config Dialog. It is often due to a customer request for access to a camera feature (camera audio, two-way talk, IR light, windshield wiper etc.) that was not provided via ONVIF. Try the BI drivers, if the ONVIF integration is lacking functionality that you desire.

Choose BI Drivers (Make / Model)

This example shares best practices for using BI drivers. As always, I tried to connect via ONVIF. After entering username, password and IP address, I hit Find/Inspect.
Results from ONVIF below.
I populated the Mainstream and Sub stream fields based on the ONVIF output.


From the General tab, I could see the high-res video was being pulled twice! Basically the camera and BI was doing double the work for ZERO benefit. This can happen. Camera vendor software is often not great.


Make
Based on the above, the immediate fix (for this example) if you have no other information is to leave the Sub stream URI blank to prevent doubling the load on your resources.
However, from the UI of the camera software, I could immediately tell this camera was a Hikvision rebrand.
Always choose the Make of the camera (if it exists) first. If the Make does not exist but you know your camera is a rebrand from an OEM, e.g. Hikvision, choose Hikvision as the Make.

Model
The Model listing with an * is the recommended model. If the preferred driver does not work, try all the different models to see if any can make a connection to your camera. With each Make/Model selection, choose the OK button instead of Find/Inspect. If you hit Find/Inspect, BI tries to re-establish an ONVIF connection (the Make/Model will again go back to Generic/RTSP). Make sure the RTSP port value remains populated with the default 554 or the specific value provided by Advanced Port Scanner.

So I went back to the IP Config Dialog and selected Hikvision as the Make.
I also changed the Main and Sub fields to default. By doing so, you are telling BI to try alternative URI streams that worked with the driver instead of the ONVIF values.


When using BI drivers, often the sub stream default values are blank. However (as stated in Step 2), if the main stream works, then it becomes easy to often guess the sub stream. The difference between the main stream path and the sub stream path will often be a single digit such as "stream0" to "stream1" or a word change such as "main" to "sub".
In my example, I am familiar with Hikvision nomenclature and their cameras often distinguish between the main and sub stream via the ending 1 or 2 in the URI.
So the sub stream in image above is populated because I copy/pasted the main stream URI and altered the last value from a 1 to a 2.

What's great about BI is it remembers the ONVIF values AND the BI driver values, so you can Mix and Match!
Maybe the ONVIF URI delivers a better main stream. Maybe the BI driver delivers a better sub stream. You can experiment with ALL permutations!

Hit the Help button in the IP Config Dialog to understand the options. Deviate from the default settings with caution.

Connecting cameras and getting video from your cameras is a crucial first step. But you may not be done. The next step is to make sure the BI Server settings are correct so the cameras deliver a good experience (smooth, high quality stream) on BI. The Video tab article will show you the way.

If the camera does not connect, review the Troubleshooting articles in the Troubleshooting Toolkit -> Cameras section.