spelling mistakes
This commit is contained in:
Isaac Connor
parent
b3703a5eed
commit
45a9f9158d
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -25,15 +25,13 @@ 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 )],
|
||||
},
|
||||
header => {
|
||||
|
||||
|
||||
},
|
||||
headerfault => {
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -812,7 +812,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
|
||||
|
|
|
|||
Loading…
Reference in New Issue