- using VBR compared to CBR
CBR (constant bit rate) is where you assign a bit rate target and the camera tries its best to produce the video stream at that bit rate regardless of everything else. The bit rate directly affects file size, bandwidth usage, etc. Higher bit rate yields higher video quality. It is pretty simple, predictable, and relatively foolproof, hence its popularity.
CBR isn't great for efficiency in the real world though. For example, imagine you have a camera in an indoor hallway and absolutely nothing is moving in the scene most of the time, but occasionally a person walks down the hallway. Maybe you want 8000 Kbps bit rate while there is a person in the hallway, but you only need 1000 Kbps or less at other times. With CBR you can only have one or the other. If you encode at 8000 Kbps then you waste a ton of bandwidth recording 23 hours a day of pristine images of an empty hallway. If you encode at 1000 Kbps then the apparent quality is shitty when a person walks in front of the camera.
VBR (variable bit rate) is the solution to that problem. VBR lets you assign two limits: a bit rate (in Kbps)
and a quality (e.g. "low", "medium", "high"). Both are maximum limits, and the camera will use as much bit rate as necessary to hit whichever limit is lower at any given moment. The idea is you can have most of your video be at low bit rate because nothing is happening, and have the bit rate jump up (up to the maximum bit rate you assigned) when something happens and more bit rate is temporarily required.
The issue with VBR is, it compromises visual quality to save bandwidth and storage space, which goes against the goal of having your camera capture the most detail possible. Also, VBR often does not work as well as you would like. For example in order to get significant bit rate savings you might have to set the quality to "low" or "medium", but that might not yield the kind of visual quality you want when something important happens. So you set the quality to "high" or "highest" and then you find that your video of the empty hallway is using the full bit rate limit anyway so you are not saving any bit rate anymore compared to CBR. Because of this, often people decide to just use CBR at a high bit rate and don't fuss around with VBR.
Personally I use VBR at low or medium quality for many of my sub streams, to save bandwidth, but then I use CBR at high bit rate for main streams which get recorded only on motion detection (very sensitive motion detection) which makes the high/wasteful bit rate less impactful because it is not being recorded 24/7.
- Frame Rates higher than 15
It is pretty to look at, but uses more resources. Only you can decide if it is worth the tradeoff.
- I-Frame Intervals 4 times higher than the FPS
This affects seek time and stream loading time in many situations.
Higher i-frame intervals give you a better compression ratio (better quality / lower bit rate) but can make seeking less efficient and make streams load slower because you need to wait for the next i-frame before playback can begin. Affects some NVR products more than others.
I personally use i-frame interval 2 times the FPS in a lot of cases. 4 times for stuff where I care about efficiency a lot (such as streams coming into
Blue Iris over the internet). i-frame interval matching the FPS is really not great for compression efficiency but I do configure it that way on many of my most prominent cameras to make the main stream startup faster.
Fun fact, in Blue Iris's web server streaming profiles and in UI3 streaming profiles, you want the i-frame interval to be as high as possible. This is because, as a quirk of how Blue Iris's remote streaming was designed, all streams are actually low-latency live streams. Even when you're playing a clip. The client/web browser never actually needs to seek forward or back or record the video, so you want the video to start with an i-frame and then have as few as possible i-frames afterward. Video players do actually tend to freak out if you go several minutes without a new i-frame so the i-frame interval is 1000 by default
- using more than 1 substream (if the software is recording all available streams, using extra storage, which cannot be turned off)
That is bizarre behavior. You should be able to control which streams are loaded and recorded. If not, that software might be a little bit too simple.
