Autotracking with Axis Camera

[alexyao2015]

Autotracking with Axis Camera

[hawkeye217]

Thanks for the info.

For the first issue: There was a recent discussion about GetServiceCapabilities and AXIS cameras.

The ONVIF protocol says here that the GetServiceCapabilities call should return True if the camera supports MoveStatus information. This MoveStatus parameter is used by Frigate's autotracking to determine when your PTZ is moving.

The reason why this parameter was chosen was:

1. It is following the ONVIF standard.
2. Some cameras report bogus values for GetStatus - they may show MOVING or IDLE but because GetServiceCapabilities doesn't indicate support for MoveStatus, the values from GetStatus are untrustworthy. Additionally, some users with Hikvision cameras had a MoveStatus value that remained as MOVING even after the PTZ motor stopped.

Other cameras we've tested with and that users have reported success with all have correctly reported GetServiceCapabilities as expected by the ONVIF standard.

For the second issue: the ONVIF code in Frigate saves the absolute zoom limits from the camera here and then uses them in calculations elsewhere when absolute zooming is used. In my testing, the zoom_limits values are not always the same as the absolute zoom limit values reported in the ptz profile's Spaces.AbsoluteZoomPositionSpace object.

In short, I've found that the ONVIF "standard" is not quite as standard as one would hope. Basic things (continuous move, presets, streams, etc) seem to be widely standardized, but the implementation of some of the finer parameters seem to vary widely from manufacturer to manufacturer, despite them saying they "support ONVIF".

[alexyao2015]

Thanks for your comments! I understand the concerns now with some cameras not conforming to the ONVIF spec. I still do find it odd that a manufacturer like AXIS produces cameras that doesn't confine to a spec they helped create. Ultimately, I as well as others likely would want their cameras to work with this new feature, so I would like to toss out a couple of ideas for solving these issues.

For GetServiceCapabilities, could we leave this as an optional config options to simply ignore this check? I did see that in my specific case, disabling this check allowed the camera to still function as GetStatus did return the correct MoveStatus values.

As for the zoom limits, I know you mention that zoom_limits are different, but does this cause issues with other cameras if it were used instead of the Spaces.AbsoluteZoomPositionSpace object? I know it certainly worked on my camera, but I cannot speak to other cameras.

Additionally as I was taking look as this, I think I found a bug. The usage of np.interp is inverted here. Since the values are getting interpolated back from the camera's view to 0-1, the camera's zoom should come first.

Hopefully we can figure out a solution to getting something working in for everyone. I have my frigate version monkey patched with the few changes I mentioned and they have been working well on my camera.

[hawkeye217]

Thanks for your comments! I understand the concerns now with some cameras not conforming to the ONVIF spec. I still do find it odd that a manufacturer like AXIS produces cameras that doesn't confine to a spec they helped create. Ultimately, I as well as others likely would want their cameras to work with this new feature, so I would like to toss out a couple of ideas for solving these issues.

For GetServiceCapabilities, could we leave this as an optional config options to simply ignore this check? I did see that in my specific case, disabling this check allowed the camera to still function as GetStatus did return the correct MoveStatus values.

Adding features to work around individual camera issues or manufacturer's firmware bugs and incomplete ONVIF support isn't something that makes a lot of sense from a support perspective, especially when myself and the other maintainers don't have those cameras to test with.

As for the zoom limits, I know you mention that zoom_limits are different, but does this cause issues with other cameras if it were used instead of the Spaces.AbsoluteZoomPositionSpace object? I know it certainly worked on my camera, but I cannot speak to other cameras.

Additionally as I was taking look as this, I think I found a bug. The usage of np.interp is inverted here. Since the values are getting interpolated back from the camera's view to 0-1, the camera's zoom should come first.

This is incorrect and not a bug. Absolute zoom values from the camera get mapped to a value between 0 and 1. Frigate uses a value of 0-1 internally to keep track of cameras using absolute zooming, so the code as written is working as intended.

However, it may be possible to better catch errors or unexpected values with cameras like yours. Could you enable debug logging, restart Frigate, and paste the initial log output as well as your Frigate config here?

logger:
  default: info
  logs:
    frigate.ptz.autotrack: debug
    frigate.ptz.onvif: debug