ONVIF / Camera Management Support

[Alan Ryan]

Hi Scott,

EPIC work,  I'm so impressed by the depth of knowledge and what you have achieved here.  Even more so when I dig in and see that it's all built from scratch.

We have been building something very similar at my day job for the last few years, with gstreamer under the hood, instead of ffmpeg.  During this effort I have gained a lot of experience with ONVIF and proprietary vendor protocols, such as Axis's VAPIX and Bosch's XMLRPC.

I would like to incorporate this knowledge into Moonfire, but wanted to get your steer on it here before I put any code down.  Also , my Rust experience is very limited - I will certainly need some PR walkthroughs, pointers where my code can be better if that's workable.

For now, after reading your API doc, I was thinking something like the following would work for ONVIF/Moonfire

### GET /api/cameras/<uuid>/onvif/<schema>/<call>/

Some examples from client perspective:

1. Get the System Date And Time
 let dateandtime =  get("/api/cameras/958d89e5-9a04-4118-8931-3572d8d9f6fe/onvif/core/GetSystemDateAndTime/")

2. Get a List of Users
let users =   get("/api/cameras/958d89e5-9a04-4118-8931-3572d8d9f6fe/onvif/core/GetUsers/")

3. Update FrameRate on Stream/Profile

 let response =   patch/put("/api/cameras/958d89e5-9a04-4118-8931-3572d8d9f6fe/onvif/media/SetVideoEncoderConfiguration/",  
            '
                {
                  "SetVideoEncoderConfiguration": {
                    "Configuration": {
                      "token": "Profile1",
                      "RateControl": {
                    "FrameRateLimit": "15",
                    "EncodingInterval": "1"
                      }
                    }
                  }
                }
                ');
            
With the JSON payload representing the XML Entities used by ONVIf, the option to send XML would be viable too..

Non ONVIF Cameras, or limited ONVIF Support

When we encounter devices that do no fully support ONVIF, we can fall back to Proprietary protocols, in my experience, from an API consuming client this gets tricky.

e.g. ONVIF Profile T supports "SetImagingSettings" - whereby we can specify encoding as "H.264" or maybe "VP9" || "H.265".

An Axis Camera without ONVIF Profile T support allows the encoding to be set without ONVIF supoprt - using the `VAPIX::vapix_update` command.

However leaking this underlying 'camera knowledge' in our API would mean we depend on consumers to understand the device they are accessing, and reducing the function/value of the API, essentially   the problem being: "How does the consumer know which protocol to use"

Ideally we could extend the 'ONVIF' REST API, to deal with all devices , when we receive a 'SetImagingSettings' call for a non Profile T camera, we could query it to detect it's brand/protocol and bridge the request by using e.g VAPIX to speak with the camera  - hiding the complexity from the consumer.

I could talk on this all day, hopefully above is enough to give you an understanding of what's in my head.

Alan

**Security

I would imagine the  the `<calls>` being protected by HTTP Auth,  mirroring the ACLs `ONVIF` uses.  So, `GetsystemDateAndTime` would need no Auth or View permissions, whereas `GetDNS` would require Operator or Admin level  access.