Merge branch 'master' into storageareas
This commit is contained in:
Isaac Connor
commit
df0b600431
|
|
@ -3,7 +3,7 @@ Section: net
|
|||
Priority: optional
|
||||
Maintainer: Dmitry Smirnov <onlyjob@debian.org>
|
||||
Uploaders: Vagrant Cascadian <vagrant@debian.org>
|
||||
Build-Depends: debhelper (>= 9), dh-systemd, python-sphinx | python3-sphinx, apache2-dev, dh-linktree
|
||||
Build-Depends: debhelper (>= 9), dh-systemd, python-sphinx | python3-sphinx, apache2-dev, dh-linktree, dh-systemd, dh-apache2
|
||||
,cmake
|
||||
,libx264-dev, libmp4v2-dev
|
||||
,libavdevice-dev (>= 6:10~)
|
||||
|
|
|
|||
|
|
@ -311,7 +311,7 @@ There are a number of specific reasons why processor loads can be high either by
|
|||
|
||||
The main causes are.
|
||||
|
||||
* Using a video palette other than greyscale or RGB24. This can cause a relatively minor performace hit, though still significant. Although some cameras and cards require using planar palettes ZM currently doesn't support this format internally and each frame is converted to an RGB representation prior to processing. Unless you have compelling reasons for using YUV or reduced RGB type palettes such as hitting USB transfer limits I would experiment to see if RGB24 or greyscale is quicker. Put your monitors into 'Monitor' mode so that only the capture daemons are running and monitor the process load of these (the 'zmc' processes) using top. Try it with various palettes to see if it makes a difference.
|
||||
* Using a video palette other than greyscale or RGB24. This can cause a relatively minor performance hit, though still significant. Although some cameras and cards require using planar palettes ZM currently doesn't support this format internally and each frame is converted to an RGB representation prior to processing. Unless you have compelling reasons for using YUV or reduced RGB type palettes such as hitting USB transfer limits I would experiment to see if RGB24 or greyscale is quicker. Put your monitors into 'Monitor' mode so that only the capture daemons are running and monitor the process load of these (the 'zmc' processes) using top. Try it with various palettes to see if it makes a difference.
|
||||
* Big image sizes. A image of 640x480 requires at least four times the processing of a 320x240 image. Experiment with different sizes to see what effect it may have. Sometimes a large image is just two interlaced smaller frames so has no real benefit anyway. This is especially true for analog cameras/cards as image height over 320 (NTSC) or 352 PAL) are invariably interlaced.
|
||||
* Capture frame rates. Unless there's a compelling reason in your case there is often little benefit in running cameras at 25fps when 5-10fps would often get you results just as good. Try changing your monitor settings to limit your cameras to lower frame rates. You can still configure ZM to ignore these limits and capture as fast as possible when motion is detected.
|
||||
* Run function. Obviously running in Record or Mocord modes or in Modect with lots of events generates a lot of DB and file activity and so CPU and load will increase.
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Maximum FPS
|
|||
Alarm Maximum FPS
|
||||
If you have specified a Maximum FPS it may be that you don’t want this limitation to apply when your monitor is recording motion or other event. This setting allows you to override the Maximum FPS value if this circumstance occurs. As with the Maximum FPS setting leaving this blank implies no limit so if you have set a maximum fps in the previous option then when an alarm occurs this limit would be ignored and ZoneMinder would capture as fast as possible for the duration of the alarm, returning to the limited value after the alarm has concluded. Equally you could set this to the same, or higher (or even lower) value than Maximum FPS for more precise control over the capture rate in the event of an alarm.
|
||||
|
||||
**IMPORTANT:** This field is subject to the same limitations as the Maxium FPS field. Ignoring these limitations will produce undesriable results.
|
||||
**IMPORTANT:** This field is subject to the same limitations as the Maximum FPS field. Ignoring these limitations will produce undesriable results.
|
||||
|
||||
Reference Image Blend %ge
|
||||
Each analysed image in ZoneMinder is a composite of previous images and is formed by applying the current image as a certain percentage of the previous reference image. Thus, if we entered the value of 10 here, each image’s part in the reference image will diminish by a factor of 0.9 each time round. So a typical reference image will be 10% the previous image, 9% the one before that and then 8.1%, 7.2%, 6.5% and so on of the rest of the way. An image will effectively vanish around 25 images later than when it was added. This blend value is what is specified here and if higher will make slower progressing events less detectable as the reference image would change more quickly. Similarly events will be deemed to be over much sooner as the reference image adapts to the new images more quickly. In signal processing terms the higher this value the steeper the event attack and decay of the signal. It depends on your particular requirements what the appropriate value would be for you but start with 10 here and adjust it (usually down) later if necessary.
|
||||
|
|
@ -205,7 +205,8 @@ Warm-up Frames
|
|||
Pre/Post Event Image Buffer
|
||||
These options determine how many frames from 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 of 10 for both of these will get you started but if you get a lot of short events and would prefer them to run together to form fewer longer ones then increase the Post Event buffer size. The pre-event buffer is a true buffer and should not really exceed half the 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 1FPS will give you 10 seconds before and after each event if you chose 10 here. This may well be too much and pad out events more than necessary. However a fast video card may capture at 25FPS and you will want to ensure that this setting enables you to view a reasonable time frame pre and post event.
|
||||
Stream Replay Image Buffer
|
||||
This option ...
|
||||
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. 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 bogus events caused perhaps by screen flickers or other transients. 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,9 +25,7 @@ sub GetServices {
|
|||
soap_action => 'http://www.onvif.org/ver10/device/wsdl/GetServices',
|
||||
style => 'document',
|
||||
body => {
|
||||
|
||||
|
||||
'use' => 'literal',
|
||||
use => 'literal',
|
||||
namespace => 'http://schemas.xmlsoap.org/wsdl/soap/',
|
||||
encodingStyle => '',
|
||||
parts => [qw( ONVIF::Device::Elements::GetServices )],
|
||||
|
|
@ -50,9 +48,7 @@ sub GetServiceCapabilities {
|
|||
soap_action => 'http://www.onvif.org/ver10/device/wsdl/GetServiceCapabilities',
|
||||
style => 'document',
|
||||
body => {
|
||||
|
||||
|
||||
'use' => 'literal',
|
||||
use => 'literal',
|
||||
namespace => 'http://schemas.xmlsoap.org/wsdl/soap/',
|
||||
encodingStyle => '',
|
||||
parts => [qw( ONVIF::Device::Elements::GetServiceCapabilities )],
|
||||
|
|
@ -3059,7 +3055,7 @@ Returns a L<ONVIF::Device::Elements::SetClientCertificateModeResponse|ONVIF::Dev
|
|||
|
||||
=head3 GetRelayOutputs
|
||||
|
||||
This method has been depricated with version 2.0. Refer to the DeviceIO service.
|
||||
This method has been deprecated with version 2.0. Refer to the DeviceIO service.
|
||||
|
||||
Returns a L<ONVIF::Device::Elements::GetRelayOutputsResponse|ONVIF::Device::Elements::GetRelayOutputsResponse> object.
|
||||
|
||||
|
|
@ -3069,7 +3065,7 @@ Returns a L<ONVIF::Device::Elements::GetRelayOutputsResponse|ONVIF::Device::Elem
|
|||
|
||||
=head3 SetRelayOutputSettings
|
||||
|
||||
This method has been depricated with version 2.0. Refer to the DeviceIO service.
|
||||
This method has been deprecated with version 2.0. Refer to the DeviceIO service.
|
||||
|
||||
Returns a L<ONVIF::Device::Elements::SetRelayOutputSettingsResponse|ONVIF::Device::Elements::SetRelayOutputSettingsResponse> object.
|
||||
|
||||
|
|
@ -3085,7 +3081,7 @@ Returns a L<ONVIF::Device::Elements::SetRelayOutputSettingsResponse|ONVIF::Devic
|
|||
|
||||
=head3 SetRelayOutputState
|
||||
|
||||
This method has been depricated with version 2.0. Refer to the DeviceIO service.
|
||||
This method has been deprecated with version 2.0. Refer to the DeviceIO service.
|
||||
|
||||
Returns a L<ONVIF::Device::Elements::SetRelayOutputStateResponse|ONVIF::Device::Elements::SetRelayOutputStateResponse> object.
|
||||
|
||||
|
|
|
|||
|
|
@ -830,7 +830,7 @@ Returns a L<ONVIF::PTZ::Elements::SetPresetResponse|ONVIF::PTZ::Elements::SetPre
|
|||
|
||||
=head3 RemovePreset
|
||||
|
||||
Operation to remove a PTZ preset for the Node in the selected profile. The operation is supported if the PresetPosition capability exists for teh Node in the selected profile.
|
||||
Operation to remove a PTZ preset for the Node in the selected profile. The operation is supported if the PresetPosition capability exists for the Node in the selected profile.
|
||||
|
||||
Returns a L<ONVIF::PTZ::Elements::RemovePresetResponse|ONVIF::PTZ::Elements::RemovePresetResponse> object.
|
||||
|
||||
|
|
|
|||
|
|
@ -816,7 +816,7 @@ shared_data The general mapped memory section
|
|||
size The size, in bytes, of this section
|
||||
valid Flag indicating whether this section has been initialised
|
||||
active Flag indicating whether this monitor is active (enabled/disabled)
|
||||
signal Flag indicating whether this monitor is reciving a valid signal
|
||||
signal Flag indicating whether this monitor is receiving a valid signal
|
||||
state The current monitor state, see the STATE constants below
|
||||
last_write_index The last index, in the image buffer, that an image has been saved to
|
||||
last_read_index The last index, in the image buffer, that an image has been analysed from
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ fi;
|
|||
|
||||
if [ "$DISTROS" == "" ]; then
|
||||
if [ "$RELEASE" != "" ]; then
|
||||
DISTROS="xenial,bionic,trusty"
|
||||
DISTROS="xenial,bionic,cosmic,disco,trusty"
|
||||
else
|
||||
DISTROS=`lsb_release -a 2>/dev/null | grep Codename | awk '{print $2}'`;
|
||||
fi;
|
||||
|
|
|
|||
|
|
@ -150,6 +150,7 @@ input,textarea,select,button,.btn-primary {
|
|||
font-weight: 400;
|
||||
font-size: 100%;
|
||||
color: #333333;
|
||||
background-color: #f8f8f8;
|
||||
text-align: left;
|
||||
border-radius:4px;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -86,6 +86,7 @@ input,textarea,select,button {
|
|||
font-family: inherit;
|
||||
font-size: 100%;
|
||||
color: #333333;
|
||||
background-color: #eeeeee;
|
||||
}
|
||||
|
||||
input[type=text], input[type=password], textarea {
|
||||
|
|
|
|||
Loading…
Reference in New Issue