diff --git a/docs/faq.rst b/docs/faq.rst index 7735ff38f..a703fd065 100644 --- a/docs/faq.rst +++ b/docs/faq.rst @@ -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. diff --git a/docs/userguide/definemonitor.rst b/docs/userguide/definemonitor.rst index bcd195570..90bfc9a37 100644 --- a/docs/userguide/definemonitor.rst +++ b/docs/userguide/definemonitor.rst @@ -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. diff --git a/onvif/proxy/lib/ONVIF/Device/Interfaces/Device/DevicePort.pm b/onvif/proxy/lib/ONVIF/Device/Interfaces/Device/DevicePort.pm index 35f259f31..c3c488ba1 100644 --- a/onvif/proxy/lib/ONVIF/Device/Interfaces/Device/DevicePort.pm +++ b/onvif/proxy/lib/ONVIF/Device/Interfaces/Device/DevicePort.pm @@ -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 object. @@ -3069,7 +3065,7 @@ Returns a L object. @@ -3085,7 +3081,7 @@ Returns a L object. diff --git a/onvif/proxy/lib/ONVIF/PTZ/Interfaces/PTZ/PTZPort.pm b/onvif/proxy/lib/ONVIF/PTZ/Interfaces/PTZ/PTZPort.pm index 8d42d439e..d1c5faa29 100644 --- a/onvif/proxy/lib/ONVIF/PTZ/Interfaces/PTZ/PTZPort.pm +++ b/onvif/proxy/lib/ONVIF/PTZ/Interfaces/PTZ/PTZPort.pm @@ -830,7 +830,7 @@ Returns a L object. diff --git a/scripts/ZoneMinder/lib/ZoneMinder/Memory.pm.in b/scripts/ZoneMinder/lib/ZoneMinder/Memory.pm.in index 7c5292720..205494791 100644 --- a/scripts/ZoneMinder/lib/ZoneMinder/Memory.pm.in +++ b/scripts/ZoneMinder/lib/ZoneMinder/Memory.pm.in @@ -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