Autotracker: Basic zooming and moves with velocity estimation

[hawkeye217]

This PR adds a few features to the autotracker:

1. Basic zooming - There is plenty of room for improvement, but this implementation uses ONVIF absolute zooming to conservatively zoom in and out on an autotracked object. Relative zooming is also supported with some Dahua and Amcrest PTZs (which is what I had to test). Relative zooming will zoom concurrently with a pan/tilt movement.

2. Movements based on Norfair's estimation of the object's velocity. Faster moving objects now cause more PTZ movement so that the object is not out of the frame after a move. This requires the user to "calibrate" their camera on startup so that Frigate can measure movement times of the user's camera. These values are then stored and a simple linear regression is calculated to predict the time of a pan/tilt move. The intercept and coefficients of the calculation are written back to the config file.

I've tested with my setup and it's working, but I'd welcome anyone else with a PTZ to help test and improve the feature!

[netlify]

✅ Deploy Preview for frigate-docs canceled.

Name	Link
🔨 Latest commit	c4fa050
🔍 Latest deploy log	https://app.netlify.com/sites/frigate-docs/deploys/65139b122c91c8000865d361

[NickM-27]

Is there a reason why a user would want to use absolute zoom if relative zoom is available?

[hawkeye217]

Is there a reason why a user would want to use absolute zoom if relative zoom is available?

Relative zoom seems to be implemented differently depending on the camera. The ONVIF spec says:

5.7.2.2 Generic zoom translation space
The generic zoom translation space shall be provided by every PTZ node that supports
relative zoom, since it does not relate to a specific physical range. Instead, the corresponding
absolute range should be defined as the full positive and negative translation range of the
Zoom normalized to the range -1 to1, where a positive translation maps to a movement in tele
direction. The translation is signed to indicate direction (negative is to wide, positive is to tele).
There is no assumption about how the generic zoom range is mapped to magnification, field
of view or other physical zoom dimension.

That last line is the hangup.

The Dahua/Amcrest cams I tested use a generic zoom translation space. When you send it a positive zoom value along with pan/tilt values, it zooms in proportionally to the area of the frame with the centroid calculated by a relative pan/tilt. That makes it super nice for our application as we already have the bounding box dimensions for objects. So it's super easy to grab the centroid and bounding box of the object, do a few quick calculations, and send those values directly to the camera. The result is a perfect pan/tilt/zoom movement toward the object.

I'm just not sure if other brands implement relative zoom in the same way because the ONVIF spec says there's no assumption about how the generic zoom range is mapped. Hence the default to absolute zooming.

[NickM-27]

Thanks, I think we'll want some kind of detailed explanation on the docs for that.

I also think instead of two separate fields for zoom it would be preferable to have one field with an enum of none, absolute, and relative