added ability to override host

[adrum]

I have my UFV running inside a Docker container, and the Docker container runs on a different network. Long story short, the IP that gets returned for the RTSP stream is whatever IP gets pulled from UFV, which is unreachable from the device running my Homebridge. This adds the ability to force the RSTP URL to use whatever we define for apiHost in the Homebridge config.json. I almost added this to be the default behavior, but didn't know if it would break any existing installations.

I've requested this ability to override it from Unifi Video Controller admin, but it's not been picked up yet.

[gozoinks]

So to test this, I would add overrideHost = true to my homebridge config, and then the plugin will use the API hostname as the RTSP host?

[byronmccollum]

I have a similar problem that this might fix...

My NVR is attached to two separate networks, my home network, and a camera network. The camera network does not have a gateway, and is completely isolated from the home network. This is common where network drops for cameras might be in an insecure locations, to help with physical network isolation.

The NVR appears to offer an RTSP URL for each network it is attached to, and it just so happens the first of these URLs returned is for the camera network, which Homebridge is unable to access in order to proxy the stream.

Forcing stream URLs to be based off the API URL works around this for me, but only when Homebridge is on the same network as API access to the NVR. A more explicit way of specifying which RTSP URL to use, maybe based on CIDR matching, would allow for more flexibility in complex network setups.

[adrum]

@gozoinks I added another option for more flexibility. If someone has multiple NVR on an instance, they would be able to control globally, per NVR, or mix the two approaches.

You can use one of the following options:

// Global
{
  "platform": "camera-ffmpeg-ufv",
  "name": "UniFi Video (ffmpeg)",
  "overrideHost": true,
  "nvrs": [
    {
      "apiHost": "nvr-ip-or-hostname.example.com",
      "apiPort": 7443,
      "apiProtocol": "https",
      "apiKey": "<api key from NVR user settings>"
    }
  ]
}

// Per NVR
{
  "platform": "camera-ffmpeg-ufv",
  "name": "UniFi Video (ffmpeg)",
  "nvrs": [
    {
      "apiHost": "nvr-ip-or-hostname.example.com",
      "overrideHost": true,
      "apiPort": 7443,
      "apiProtocol": "https",
      "apiKey": "<api key from NVR user settings>"
    }
  ]
}

// Mixed Global and Per NVR
{
  "platform": "camera-ffmpeg-ufv",
  "name": "UniFi Video (ffmpeg)",
  "overrideHost": true,
  "nvrs": [
    {
      // This NVR would use apiHost for the RTSP stream
      "apiHost": "nvr-ip-or-hostname.example.com",
      "apiPort": 7443,
      "apiProtocol": "https",
      "apiKey": "<api key from NVR user settings>"
    },
    {
      // This NVR would use whatever the first url is in the API response for the RTSP stream
      "apiHost": "nvr-ip-or-hostname.example.com",
      "overrideHost": false,
      "apiPort": 7443,
      "apiProtocol": "https",
      "apiKey": "<api key from NVR user settings>"
    }
  ]
}

[adrum]

@byronmccollum In that particular scenario described, would homebridge even be able to reach the API at all using apiHost? If so, the RTSP stream should be available under the same address.

I run an internal DNS on my network so it just uses whatever hostname I've assigned my NVR.

[byronmccollum]

@adrum You are correct. I was making it more complicated than it needed to be. I was thinking about adding Homebridge to my IoT network, and that clouded things a bit.

So the host override is all that’s needed, and it works great! Was able to stream cameras from work today.

[adrum]

@gozoinks Have you had a chance to review this yet?

[byronmccollum]

I'm still running this patch against 0.7.1, and it's been working great.

[jmbwell]

Thanks for the nudge. I've been thinking, if the goal is to allow the streams to come from a separate host other than the API host, then might there be situations in which we need to specify an arbitrary host independent of the API host or the streaming host? In which case, perhaps instead of an overrideHost set to true/false, the config should support a "streamingHost" parameter that is used if set, but otherwise uses the apiHost as it is now.

[adrum]

@jmbwell @gozoinks Just to make sure we are on the same page, the original goal was to guarantee the url for streaming that ffmpeg uses matches the API URL was pass in the Homebridge config. In my situation, the Unifi Video API would respond with the docker container network IP instead of the API Host I was using in the homebirdge config, which made the stream inaccessible from homebridge. Since the API Host is guaranteed to be reachable (since we can hit the API), we should also be able to access the stream from the same API Host.

This may be something that is a safe assumption and should be the default behavior. I added as a config option in order to guarantee existing installation would continue to function as they did before the change.

[jmbwell]

Should it then just always use the apiHost for streaming and ignore the rtspHost listed in the JSON the way it is now?

Perhaps that's the best behavior. rtspHost is probably in there for the NVR's internal purposes. I wonder if the NVR would ever have any reason to provide a streaming host other than itself.

[jmbwell]

In other words, instead of requiring an overrideHost option, just always override…

[adrum]

@jmbwell I've added the code to force the streaming url to use the apiHost. I've also merged upstream and resolved conflicts.

[byronmccollum]

👍 Sounds good to me 👍