Jump to content
hardwired

Significant problem with Hikvision PTZ's

Recommended Posts

I recently discovered what I find to be a significant problem with Hikvision PTZ's when using motion detection recording (I'm using a DS-2DF8223I-AEL, an otherwise really impressive camera). When actively using the PTZ while tracking a subject, motion detection events are not sent to the VMS, resulting in large gaps in recording while following a subject.

 

I made contact with Hikvision support over this issue, and their response was that this was the correct method of operation. Needless to say, I disagree, and may have to rethink use of their PTZ's in the future.

 

Anyway, this is something to watch out for when using Hikvision PTZ's, as the only option to have recording during PTZ operation is to have continuous recording selected.

 

You may at least want to extend pre/post buffering, if that's an available option in your VMS.

Share this post


Link to post
Share on other sites

While this may seem like an odd or even not well thought out practice by Hikvision it's actually a fairly standard practice for Network IP Camera manufacturers to use.

 

As you state the only way around this is to use continuous recording methods. Which at least gives you an out.

 

It really is a programming nightmare to try and support alarm events like motion events and notifications as one of many examples. While/When PTZ controls are in use. So the usual approach is to not allow motion related events and notifications to take place while PTZ controls are in use.

 

If I was a betting man I would say that sometime in the near future updated firmware will support reporting motion detection events and notifications where PTZ controls are being used for Hikvsion auto-tracking reasons and not manual PTZ use.

 

That said, this will still require extensive coding changes to support because the instant any PTZ control is used. Many if not all motion detection events and notifications are suspended until PTZ controls have come to a stop. This is to avoid false positives for motion detection. Most likely things will change in the near future to support motion detection events and notifications for any auto-tracking use of PTZ controls.

 

But, most likely, when one is manually using PTZ controls motion detection events and notifications will continue to not be supported in many cases.

 

I say this for good reason. Currently PTZ controls each time they are used suspend motion detection events and notifications. So code would need to be changed for each PTZ control not to do this "If this or that". While this sounds easy it's defining the "If this or that" vs. always as it is now.

 

Worse, there currently are no methods to determine if a specific PTZ control was fired using auto-tracking or manually. So it may actually come down to adding PTZ control logic where one could instantly determine if the current PTZ control was fired manually or automatically for auto-tracking purposes.

 

Don

Edited by Guest

Share this post


Link to post
Share on other sites

Oh, I understand the manufacturer position: I don't think it's a well thought out approach, though. I can't imagine a single instance where you wouldn't want recording of an event when you are operating the PTZ.

 

I certainly wouldn't mind the camera outputting motion detection events at any time while either auto-tracking or manual PTZ events are occurring, though.

 

All it would take from the manufacturer side would be a check box to select for not suppressing motion detection events under any circumstances.

Share this post


Link to post
Share on other sites

Depending on what motion detection features, events and notifications you had enabled combined with how often you use PTZ controls manually. I think you would be extremely surprised at the amount of false positives you would generate. When not suspending motion detection events and notifications during the manual use of PTZ controls.

 

This is why I can't see most Network IP Camera manufacturers even taking the time to use a checkbox option for not suspending motion detection events and notifications when PTZ controls are invoked manually.

 

I do agree however, that when features like auto-tracking are used which involve the automatic use of PTZ controls that Network IP Camera manufacturers really do need to in the future include motion detection events and notifications in all cases. Which rumor has it at least that Hikvision is at least thinking about that in newer firmware releases.

 

Don

Share this post


Link to post
Share on other sites

The solution is simple, the camera should be set to record when the ptz is manually controlled, no motion events. Simply record the footage. It would be easy to implement, they simply choose not to do it.

Share this post


Link to post
Share on other sites

Actually, it's not that simple. If it was it would currently be being done.

 

The facts are false positives create wasted disk space.

 

This is why the current solution has and is to simply use continuous recording since no additional space is required because recording is continuous anyway.

 

This all said. Major coding changes would be required to undo the current PTZ motion detection logic suspension in any case. As stated. Hikvision is looking at doing this at minimum with auto-tracking that invokes PTZ controls during that process.

 

Don

Share this post


Link to post
Share on other sites
Actually, it's not that simple. If it was it would currently be being done.

 

The facts are false positives create wasted disk space.

 

This is why the current solution has and is to simply use continuous recording since no additional space is required because recording is continuous anyway.

 

Don

Its not a false positive if you are moving the ptz and want it to record. Even without an on/off option this would add minimal HD storage space unless the ptz is manually operated hours at a time. A simple on/off option would eliminate that issue for constantly used ptz's.

The solution is very simple to implement, certainly easier than traditional motion detection...they simply choose not to.

Share this post


Link to post
Share on other sites
Actually, it's not that simple. If it was it would currently be being done.

 

The facts are false positives create wasted disk space.

 

This is why the current solution has and is to simply use continuous recording since no additional space is required because recording is continuous anyway.

 

Don

Its not a false positive if you are moving the ptz and want it to record. Even without an on/off option this would add minimal HD storage space unless the ptz is manually operated hours at a time. A simple on/off option would eliminate that issue for constantly used ptz's.

The solution is very simple to implement, certainly easier than traditional motion detection...they simply choose not to.

If one was NOT continuously recording then one would not have been recording while using PTZ controls. So what you are saying makes no sense.

 

I clearly stated that current PTZ control use currently suspends any motion detection events ("Including recording") and in many cases notifications. To undo that requires extensive coding changes. There is no "easy" fix to avoid those changes at this time.

 

Continuous recording is never suspended as I assume you know. Which is why this currently is the only option to use in many cases when PTZ controls are being used to not miss recording something that could be taking place while using PTZ controls.

 

This is why Hikvision is reviewing how they should make those extensive ("Not simple") changes and when they should suspend motion detection events and notifications. Once that review process is complete, then those extensive coding changes will that place. Which are far from simple.

 

Don

Edited by Guest

Share this post


Link to post
Share on other sites
Actually, it's not that simple. If it was it would currently be being done.

 

The facts are false positives create wasted disk space.

 

This is why the current solution has and is to simply use continuous recording since no additional space is required because recording is continuous anyway.

 

Don

Its not a false positive if you are moving the ptz and want it to record. Even without an on/off option this would add minimal HD storage space unless the ptz is manually operated hours at a time. A simple on/off option would eliminate that issue for constantly used ptz's.

The solution is very simple to implement, certainly easier than traditional motion detection...they simply choose not to.

If one was NOT continuously recording then one would not have been recording while using PTZ controls. So what you are saying makes no sense.

 

I clearly stated that current PTZ control use currently suspends any motion detection events ("Including recording") and in many cases notifications. To undo that requires extensive coding changes. There is no "easy" fix to avoid those changes at this time.

 

Continuous recording is never suspended as I assume you know. Which is why this currently is the only option to use in many cases when PTZ controls are being used to not miss recording something that could be taking place while using PTZ controls.

 

This is why Hikvision is reviewing how they should make those changes and when they should suspend motion detection events and notifications. Once that review process is complete, then those extensive coding changes will that place. Which are far from simple.

 

Don

It makes total sense. While manual ptz is not in use then motion recording is active. A soon as manual ptz is engaged the camera starts recording. Simple, easy. This is NOT a difficult programming task. In fact it is VERY easy. Please dont provide the false impression that you know what hikvision is doing.

Share this post


Link to post
Share on other sites
Fenderman,

 

What part of even trying to implement a checkbox to allow motion detection events ("Including recordings") and notifications to take place requires extensive ("Not simple") coding changes to take place confuses you?

 

Don

I never said anything about implementing motion events. Please read. The users DONT want motion events. All they wants it to trigger recording when the ptz is manually engaged. It is VERY simply and easy to implement this. Extensive coding is NOT needed.

To make changes to current PTZ logic will require extensive coding changes.

 

Don

Edited by Guest

Share this post


Link to post
Share on other sites
Actually, it's not that simple. If it was it would currently be being done.

 

The facts are false positives create wasted disk space.

 

This is why the current solution has and is to simply use continuous recording since no additional space is required because recording is continuous anyway.

 

This all said. Major coding changes would be required to undo the current PTZ motion detection logic suspension in any case. As stated. Hikvision is looking at doing this at minimum with auto-tracking that invokes PTZ controls during that process.

 

Don

 

I disagree. It would be easy for them to send the motion flag whenever the camera is moved.

Share this post


Link to post
Share on other sites
Actually, it's not that simple. If it was it would currently be being done.

 

The facts are false positives create wasted disk space.

 

This is why the current solution has and is to simply use continuous recording since no additional space is required because recording is continuous anyway.

 

This all said. Major coding changes would be required to undo the current PTZ motion detection logic suspension in any case. As stated. Hikvision is looking at doing this at minimum with auto-tracking that invokes PTZ controls during that process.

 

Don

 

I disagree. It would be easy for them to send the motion flag whenever the camera is moved.

Please feel free to suggest that to Hikvision and make the claim that you feel it will be "easy to do" while also asking them if they agree. Please post their response back here.

 

Don

Share this post


Link to post
Share on other sites

I think the bigger problem is that Hikvision has their own ideas regarding what should be considered a "false" motion event.

 

I would agree with suppressing motion events during jumps between PTZ preset calls, but there is no use case that I can imagine where you wouldn't want to record during manual PTZ operation (and what would be the use of running a tour without recording it? all you would be doing is wearing out the PTZ components...)

 

Let's take my use case for an example. This particular camera is at a community center where the motion activity is under 25% overall, and the manual PTZ operation is probably less than 5% per day.

 

That means if I enable continuous recording on this particular camera, I will be wasting 70% of storage space, simply to catch events during PTZ operation. That seems far more wasteful than recording a small percentage of "False" events.

Share this post


Link to post
Share on other sites
I think the bigger problem is that Hikvision has their own ideas regarding what should be considered a "false" motion event.

 

I would agree with suppressing motion events during jumps between PTZ preset calls, but there is no use case that I can imagine where you wouldn't want to record during manual PTZ operation (and what would be the use of running a tour without recording it? all you would be doing is wearing out the PTZ components...)

 

Let's take my use case for an example. This particular camera is at a community center where the motion activity is under 25% overall, and the manual PTZ operation is probably less than 5% per day.

 

That means if I enable continuous recording on this particular camera, I will be wasting 70% of storage space, simply to catch events during PTZ operation. That seems far more wasteful than recording a small percentage of "False" events.

I can only suggest creating a relationship with Hikvision as I have done when creating interfaces to their Network IP Camera equipment. Make suggestions as well. That said, I already have had conversations about this subject matter with them. But since others think implementing changes like this are "easy". It should be just as "easy" to make suggestions and also ask if these changes are more complicated then some think they are.

 

I have no doubt what Hikvision's responses will be. Because I've asked the same questions in the past and tried to share their responses here to no avail.

 

Don

Share this post


Link to post
Share on other sites

I have sent out some questions to my contact at Hikvision. I don't necessarily think that making this change would be "Easy", but considering the complexity of other features they have added in recent updates (Face detection, etc.), I don't think it would be that difficult, either, if they felt it was worthwhile.

 

Unfortunately, until then, I may not be able to continue using what is otherwise one of the best PTZ's I've ever come across, and that's a shame.

Share this post


Link to post
Share on other sites
I think the bigger problem is that Hikvision has their own ideas regarding what should be considered a "false" motion event.

 

I would agree with suppressing motion events during jumps between PTZ preset calls, but there is no use case that I can imagine where you wouldn't want to record during manual PTZ operation (and what would be the use of running a tour without recording it? all you would be doing is wearing out the PTZ components...)

 

Let's take my use case for an example. This particular camera is at a community center where the motion activity is under 25% overall, and the manual PTZ operation is probably less than 5% per day.

 

That means if I enable continuous recording on this particular camera, I will be wasting 70% of storage space, simply to catch events during PTZ operation. That seems far more wasteful than recording a small percentage of "False" events.

I can only suggest creating a relationship with Hikvision as I have done when creating interfaces to their Network IP Camera equipment. Make suggestions as well. That said, I already have had conversations about this subject matter with them. But since others think implementing changes like this are "easy". It should be just as "easy" to make suggestions and also ask if these changes are more complicated then some think they are.

 

I have no doubt what Hikvision's responses will be. Because I've asked the same questions in the past and tried to share their responses here to no avail.

 

Don

Making the suggestion is easy, making the change is very easy for hikvision. Problem is hikvision doesn't care. They simply have not received enough complaints. As hardwired mentioned, they can do face detection but somehow turning on recording during ptz movement is difficult. Please.

Share this post


Link to post
Share on other sites

To clarify: I made two contacts with Hikvision. The first was with tech support, where a tier 2 tech made the comment that this was expected behavior. The second contact was to my regional rep, who I haven't heard back from yet. I'll update when/if I get more information.

Share this post


Link to post
Share on other sites
To clarify: I made two contacts with Hikvision. The first was with tech support, where a tier 2 tech made the comment that this was expected behavior. The second contact was to my regional rep, who I haven't heard back from yet. I'll update when/if I get more information.

Please feel free to send me a PM ("Private Message") and I will give you an email address for the Hikvision person who is in charge of this area. So that you can make sure you are truly getting the correct answers to your questions on this subject matter. As well as make any suggestions you may have on this subject matter.

 

Don

Share this post


Link to post
Share on other sites
To clarify: I made two contacts with Hikvision. The first was with tech support, where a tier 2 tech made the comment that this was expected behavior. The second contact was to my regional rep, who I haven't heard back from yet. I'll update when/if I get more information.

 

 

i have fixed this issue. pm me if you care

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×