QuantumEntangledAndy / neolink

An RTSP bridge to Reolink IP cameras
GNU Affero General Public License v3.0
257 stars 41 forks source link

Add web support for PTZ communication #124

Closed skylord123 closed 11 months ago

skylord123 commented 11 months ago

Is your feature request related to a problem? Please describe. So I use Xeoma to control my cameras. I have the RLC-423ws that has PTZ control through port 8000. Currently because this container uses a different IP address then my actual camera Xeoma gets confused and doesn't think the camera supports PTZ.

Describe the solution you'd like Would be awesome if this software could expose PTZ in the same format that the camera originally does it. Downside is each camera would need it's own port (but Xeoma lets you specify which port to do PTZ control over so even if you have many cameras that is fine).

So I would like to be able to specify a port to expose a web server to handle these requests. Preferably in a format similar to what the RLC-423ws already does on port 8000 but honestly any sort of generic PTZ schema should work since Xeoma has support for a wide range of different cameras.

Thanks!

QuantumEntangledAndy commented 11 months ago

Is there any reason you can't use MQTT?

QuantumEntangledAndy commented 11 months ago

It seems that Xeoma can use ONVIF. Ideally I'd like to support that BUT its a lot of work since theres no good ONVIF server library in rust (lots of client libraries but not much for server side). So I'd have to write it myself, which I doubt I'd have time for.

If your up for it your more then welcome to have a go and open a PR

skylord123 commented 11 months ago

It seems that Xeoma can use ONVIF. Ideally I'd like to support that BUT its a lot of work since theres no good ONVIF server library in rust (lots of client libraries but not much for server side). So I'd have to write it myself, which I doubt I'd have time for.

Would you be up to at least adding a basic proxy for now until we can get ONVIF support added? Something that literally just takes a proxy_from_port and proxy_to_url entries per camera?

For example:

[[cameras]]
name = "driveway"
username = "yay"
password = "fun"
address = "192.168.1.195:9000"
proxy_from_port = 8000
proxy_to_url = http://192.168.1.195:8000

This will at least give support for us that have Reolink cameras that support native onvif/api commands until we can get ONVIF support added to this repo. I'm also not entirely sure if port 8000 is ONVIF or just a direct API to the camera but if we proxy all the traffic through it doesn't matter.

If your up for it your more then welcome to have a go and open a PR

Not a bad idea. I've been meaning to learn rust. It will take me some time though.

Is there any reason you can't use MQTT?

Xeoma doesn't have direct support for MQTT sadly. I had to use Node-RED as a proxy in the past to get events into Home Assistant: https://skylar.tech/send-motion-events-over-mqtt-from-xeoma/

QuantumEntangledAndy commented 11 months ago

If your just looking to proxy a port. I think something more dedicated to that task like traefik is your best bet rather then me writing something adhoc.

skylord123 commented 11 months ago

So I got this to work by using NGINX to proxy the port. but IMO this should still be added to this container.

You can't run two docker containers on the same IP address so I had to map the docker containers to run from the host and map the ports instead (since I need both ports on the same IP address). Not a fan of this solution since I would prefer Neolink to have it's own ip address and not be using the host network because it makes network security much easier (trying to keep my security cameras separate from the rest of the network)..

The other not ideal solution would be to start up traefik and have it proxy BOTH neolink and the camera port together on one IP address. Downside of that approach is now the live stream has to go through neolink & traefik adding additional latency (which I am trying really hard to keep to a minimum). Plus if something goes wrong I now have more moving parts that I need to check.

Since it's just a web server proxy rust should be able to handle that extremely easily. Especially considering you did the effort to convert PTZ calls to MQTT already which is a lot more work then a simple web server port to port proxy.

Since this is mostly a docker related problem I may just layer NGINX on top of this container. That may be a good solution to this problem. Just sucks for people that aren't familiar with NGINX that try to replicate this down the road.

QuantumEntangledAndy commented 11 months ago

If you want to add such a feature please open a PR for it. It's not something I want to add in, spending my limited free time to add a feature I have no use for.

If I were to do this Id rather wait until I have the time and energy to do a full solution with ONvIF that will be benifical to a wider audience.

skylord123 commented 11 months ago

If you want to add such a feature please open a PR for it. It's not something I want to add in, spending my limited free time to add a feature I have no use for.

Will do.

If I were to do this Id rather wait until I have the time and energy to do a full solution with ONvIF that will be benifical to a wider audience.

Yeah I agree. PTZ control over the reolink protocol is the right way to fix this.