Intro
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.