Homebridge assigning video feeds to closed ports on MacOS

Describe The Bug: I’ve been working with @Brandawg93 trying to work out why the https://github.com/Brandawg93/homebridge-nest-cam/ plugin won’t playback camera video on via MacOS but is fine on a RPi.

Some context The first issue was getting ffmpeg compiled on macOS with the necessary dependencies and options. Once I got past that @brandawg93 created a test version of the plugin that would output more detail from ffmpeg in the log so I could get a better idea on what was happening to playback.

What I found is that the plugin was working fine and ffmpeg is properly encoding the video stream, the issue is that it’s sending it out on a port that is not open. I determined this from the following:

The following is the hombridge nest cam’s FFMPEG log output. What you’ll see is the ffmpeg stream created and sent on srtp://192.168.7.89:56389?rtcpport=56389&localrtcpport=56389&pkt_size=1378

[6/19/2020, 2:42:17 PM] [Nest-cam] VIDEO command: ffmpeg -f,h264,-use_wallclock_as_timestamps,1,-probesize,100000,-i,pipe:,-preset,ultrafast,-tune,zerolatency,-c:v,libx264,-payload_type,99,-ssrc,13145893,-f,rtp,-srtp_out_suite,AES_CM_128_HMAC_SHA1_80,-srtp_out_params,mkjNkOWcszfZV603VWtyJM5j1uA/fvRO1Jkc4lTR,srtp://192.168.7.89:56389?rtcpport=56389&localrtcpport=56389&pkt_size=1378
[6/19/2020, 2:42:17 PM] [Nest-cam] VIDEO: ffmpeg version N-98255-g93016f5d1d Copyright (c) 2000-2020 the FFmpeg developers
  built with Apple LLVM version 10.0.0 (clang-1000.10.44.4)
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libopus --enable-libxvid --enable-chromaprint --enable-decklink --samples=fate-suite --enable-libspeex

[6/19/2020, 2:42:17 PM] [Nest-cam] VIDEO:   libavutil      56. 55.100 / 56. 55.100
  libavcodec     58. 93.100 / 58. 93.100
  libavformat    58. 47.100 / 58. 47.100
  libavdevice    58. 11.100 / 58. 11.100
  libavfilter     7. 86.100 /  7. 86.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100

[6/19/2020, 2:42:17 PM] [Nest-cam] [NexusStreamer] Connected
[6/19/2020, 2:42:18 PM] [Nest-cam] [NexusStreamer] Redirecting...
[6/19/2020, 2:42:18 PM] [Nest-cam] [NexusStreamer] Disconnected
[6/19/2020, 2:42:18 PM] [Nest-cam] [NexusStreamer] Connected
[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO: Input #0, h264, from 'pipe:':
  Duration: N/A, start: 1592595738.927563, bitrate: N/A
    Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 15 fps, 15 tbr, 1200k tbn, 30 tbc

[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO: Stream mapping:
  Stream #0:0 -> #0:0
[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO:  (h264 (native) -> h264 (libx264))

[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO: [libx264 @ 0x7fa01d007600] using SAR=1/1

[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO: [libx264 @ 0x7fa01d007600] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO: [libx264 @ 0x7fa01d007600] profile Constrained Baseline, level 3.1, 4:2:0, 8-bit

[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO: Output #0, rtp, to 'srtp://192.168.7.89:56389?rtcpport=56389&localrtcpport=56389&pkt_size=1378':
  Metadata:
    encoder         : Lavf58.47.100
    Stream #0:0: Video: h264 (libx264), yuvj420p(pc), 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 15 fps, 90k tbn, 15 tbc
    Metadata:
      encoder         : Lavc58.93.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A

[6/19/2020, 2:42:21 PM] [Nest-cam] VIDEO: frame=   37 fps=0.0 q=11.0 size=     355kB time=00:00:02.46 bitrate=1178.8kbits/s dup=18 drop=13 speed=4.91x    
[6/19/2020, 2:42:22 PM] [Nest-cam] VIDEO: frame=   46 fps= 43 q=11.0 size=     401kB time=00:00:03.06 bitrate=1070.8kbits/s dup=18 drop=13 speed=2.87x    
[6/19/2020, 2:42:23 PM] [Nest-cam] VIDEO: frame=   47 fps= 29 q=11.0 size=     406kB time=00:00:03.13 bitrate=1061.3kbits/s dup=18 drop=19 speed=1.96x    
[6/19/2020, 2:42:23 PM] [Nest-cam] VIDEO: frame=   54 fps= 25 q=17.0 size=     493kB time=00:00:03.60 bitrate=1121.3kbits/s dup=18 drop=20 speed=1.69x    
[6/19/2020, 2:42:23 PM] [Nest-cam] [NexusStreamer] Disconnected

While this was running I ran a port check using nmap Which shows that port 56389 is close on the computer. Hence no video playback getting out.

server jonathan$ nmap -p 56389 localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-19 14:33 CDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.46s latency).
Other addresses for localhost (not scanned): ::1

PORT      STATE  SERVICE
56389/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds

Each time video playback starts it’s sent on a new port and each time I check that port is closed.

Additionally, the reason I think this is a port issue is that the initial camera still images displayed iOS home app work correctly and refresh as expected. @brandawg93 tells me those images go out over port 80, which would why they work as that is an open port

I’ve been told it’s HAP-NodeJS that manages that port assignment and it’s something that might need to be looked at here.

Please let me know if/how I can help resolve this.

To Reproduce:

• Install homebridge-nest-cam on a mac running homebridge with a nest camera.
• see camera in the home app with successful still image
• try to watch video stream and playback never starts

Expected behavior:

• Playback should be displayed in the home app

Environment:

• Node.js Version: 12.6.1
• NPM Version: 6.13.4
• Operating System: MacOS 10.13.6 (17G10021)
• Process Supervisor: launchctl

[Brandawg93]

Not sure if this will help the team, but I went ahead and removed the ip dependency from homebridge-nest-cam and have implemented a custom function. This removes virtual and bridged interfaces (for NAS and Docker users) and returns a list rather than a string, allowing me to check how many ip addresses the devices has if any at all.

The ip package likes to put virtual addresses above others for a small subset of devices and only returns the first index of the list of interfaces.

[Brandawg93]

Definitely can be closed now.