Compressed video formats typically encode the difference between frames. However, to start a stream/video or allow for reasonably responsive seeking, key frames (a.k.a. I-frames) are needed to draw the entire picture every so often as a reference point. The problem with key frames is that they're very large compared to delta frames (a.k.a. P-frames and B-frames), which increases data usage and can cause stutters. To address this, their quality is often reduced—but if by too much, a pulsing effect appears.
Ideally, you want key frames to be as far apart as possible while still providing a reasonable seek speed and cutting granularity. Personally, I always use the maximum value these cameras support, which is 150. At 30fps, that is just five seconds (150 frames ÷ 30fps = 5 seconds). Most modern PCs can seek anywhere in such an encoded video in well under a second, this reduces video stuttering/pulsing, and significantly improves the amount of recorded video time your storage can hold. The other consideration is
Blue Iris, which is written with outdated standards from when PCs were far less powerful and didn't have much memory; so it will flag such cameras with an error, which I promptly ignore as it proceeds to work just fine. Just beware of three things:
- When you click on a live camera in BI/UI3 to maximize it, the image will start out blurry (using the camera's sub stream) until the next keyframe, where it will switch to the main stream. If your keyframe interval is 150 @ 30fps, this could take up to 5 seconds—depending where in the keyframe sequence the camera was the moment you clicked. If you can't tolerate that delay, reduce your keyframe interval to shorten it.
- Recorded clips must start with a keyframe, so make sure you set Blue Iris' Stream buffer time and Pretrigger record time to a number sufficiently high enough that it can go back in time to the previous keyframe (or the one before it) when receiving a recording trigger, so your recordings don't start several seconds after an event begins. I typically use a value of 20 seconds for both (right-click camera in BI -> Camera settings -> Record).
- During playback in BI/UI3, seeking in recorded clips will be slower on videos with larger key frame intervals. If you find it too slow, reduce your key frame interval (changes will take effect on future recorded clips). A faster CPU on the BI machine also helps with this (when you seek, it jumps to the nearest key frame, and then has to decode out to the spot you selected before it can begin playback).
Yes, the camera always uses all frames for motion detection, as does Blue Iris, regardless of your key frame interval. The only potential issue is what I wrote in #2 above. To further illustrate, let's say your key frame interval is 600, and your camera is running at 10fps (a very extreme example). This puts your key frames a whopping 60 seconds apart, and let's say they're happening on the turn of every minute of the clock. 12:45:00 PM you have a key frame, 12:46:00 PM you have another key frame, etc. At 12:46:15 PM, a person walks by. Your camera will send an ONVIF trigger to Blue Iris right away (or Blue Iris will detect the motion right away with its built-in motion detector), but it cannot start actually recording until the next key frame comes in at 12:47:00 PM—long after the person is gone! With a sufficiently large
Stream buffer time and
Pretrigger record time, Blue Iris can go back in time and start your recording at the 12:46:00 PM key frame, or even at the 12:45:00 PM key frame—despite the motion trigger happening at 12:46:15 PM. Too far back though, and it'll use more memory (to remember all those frames in case it needs to go back), and your clips will have a lot of nothing happening at the beginning.
For Blue Iris, what's more important than your key frame interval is that your main+sub stream frame rates match each other, and your main+sub stream key frame intervals match each other. The rest is a matter of preference.
