Buffers Tab

The Buffers tab controls the image buffer parameters which set limits on the number of frames used for analysis and recording of events. When setting buffer parameters please keep in mind the FPS of the specific Monitor being defined as the actual time captured in the buffers is dependent on the FPS. Due to this, there are no specific default values that will work for all Monitors and care needs to be taken when setting these parameters. Note at the bottom of Buffers tab is an estimated RAM use summary to aid in parameter setting.

../../_images/define-monitor-buffers.png

Monitor Buffers Tab

  • Image Buffer Size (frames): This option determines how many frames are held in the ring buffer in the /dev/shm ramdisk. This ring buffer is used to store the raw RGB images that zms turns into JPEG images when live viewing. In the past this needed to be large because it queued frames for analysis but that has been replaced by a dynamic packet queue. A value of 3 to 5 is sufficient for live viewing.

  • Max Image Buffer Size (frames): This option determines the maximum number of frames held in the ring buffer. Ideally this would be left blank but if there is any slowness in the database or disks the queue will fill up and consume available RAM. A reasonable setting would be 2 times the keyframe interval. Keep in mind that the buffer frames for all Monitors are stored in shared memory and making this too large may cause issues. If you find that your system will not let you use the value you want it is probably because your system has an arbitrary limit on the size of shared memory /dev/shm that may be used even though you may have plenty of free RAM available. This limit is usually fairly easy to change, see the FAQ section for details.

  • Warmup Frames: This specifies how many frames the zma analysis daemon should process but not examine when it starts. This allows it to generate an accurate reference image from a series of images before looking too carefully for any changes. Setting this too high will cause it to take a long time to start, too low will result in false alarms when the zma analysis daemon starts up.

  • Pre/Post Event Image Count: These options determine how many frames before and after an event should be preserved with it. This allows you to view what happened immediately prior and subsequent to the event. A value equal to FPS for both of these is a reasonable starting point. If this results in a lot of short events and if it is preferred to combine them together to form fewer longer events then increase the Post Event Image Count size. The pre-event buffer is a true buffer and should not really exceed half the Image Buffer ring buffer size. However the post-event buffer is just a count that is applied to captured frames and so can be managed more flexibly. You should also bear in mind the frame rate of the camera when choosing these values. For instance a network camera capturing at 1 FPS will give you 10 seconds before and after each event if you chose 10 here. This may be too long and pad out events more than necessary.

  • Stream Replay Image Buffer: The number of frames buffered to allow pausing and rewinding of the stream when live viewing a monitor. A value of 0 disables the feature. Frames are buffered to ZM_PATH_SWAP, which is a ZoneMinder system path. Refer to Configuration Files for information about updating system paths. If this path points to a physical drive, a lot of IO will be caused during live view / montage. If you experience high system load in those situations, either disable the feature or use a RAM drive for ZM_PATH_SWAP.

  • Alarm Frame Count: This option allows you to specify how many consecutive alarm frames must occur before an alarm event is generated. The usual, and default, value is 1 which implies that any alarm frame will cause or participate in an event. You can enter any value up to 16 here to eliminate short-lived events not intended to be captured. Values over 3 or 4 are unlikely to be useful however. Please note that if you have statistics recording enabled then currently statistics are not recorded for the first ‘Alarm Frame Count’-1 frames of an event. So if you set this value to 5 then the first 4 frames will be missing statistics whereas the more usual value of 1 will ensure that all alarm frames have statistics recorded.