search

nabto / nabto-ios-rtsp

Simple iOS app demonstrating RTSP tunnelling using FFMPG and Nabto
0 stars 1 forks source link

Unable to play rtsp stream #2

Open destryteeter opened 4 years ago

destryteeter commented 4 years ago

Environment:

Diagnosis: I've tried with 2 different rasp-enabled cameras. Both cameras can be viewed using the Android Nabto RTSP app. Oddly enough, the iOS sample app does not allow inclusion of the "TCP Host", "Basic auth username", or "Basic auth password" fields. I attempted to work around this by hard-coding the variables into the source code.

nabto commented 4 years ago

Features were added to Android demo upon a specific request, changes were pending on iOS. We will prioritize the change now.

nabto commented 4 years ago

The host field has been added to the bookmark UI. Basic auth username and password should be prompted for if necessary - if you don't see a prompt, there may be issues with the auth callback from the player component as was observed on Android for some RTSP hosts. This in turn was the reason for adding the input boxes there. If so, we can add those fields as well here - but please confirm if an issue or not.

destryteeter commented 4 years ago

Looks like the callback works, I was prompted to input user:pass, so probably no need to add these fields to the bookmark UI.

Created another PR (fix for the host field).

Maybe you can help debug this.

I have 2 ip cameras: Foscam and A-MTK.

First, the Foscam can be streamed while on the same LAN using rtsp://nabto:abc123@10.0.0.7:88/videoMain . It works when using VLC on my mac and when setting the path manually in the video view controller (startKxMovie). However, I could not get the default path provided by the source code to work. In this case it is rtsp://nabto:abc123@localhost:52573/videoMain .

The A-MTK is similar. Working rtsp url rtsp://nabto:abc123@10.0.0.34:555/media.amp?streamprofile=Profile1 . Non-working rtsp url rtsp://nabto:abc123@localhost:51345/media.amp?streamprofile=Profile1 .

nabto commented 4 years ago

Oops with the host field, guess it is because I tested using an RTSP server on 127.0.0.1 which is the same as the default value. Thanks! Will merge shortly.

With respect to your other problem, try to use 127.0.0.1 instead of localhost - we often see the name not being defined in the camera's hosts file.

destryteeter commented 4 years ago

Little more context. I'm using two Develco gateways on the same network (DP06 and DP09). I have two devices configured in the Nabto cloud console, each associated with one gateway and both reporting online. The P2P connection looks fine.

I am not certain the IP Cameras I have are specifically going to work (we're working on verifying a D-Link camera that Develco has worked with already to verify the feature on our end).

Here's the console output I see when attempting to stream both cameras:

2020-05-15 04:43:33.156253 | viewDidAppear: DT A-MTk [tunnel: 0]
2020-05-15 04:43:33.156771 | Reachability Flag Status: -R ------- networkStatusForFlags
2020-05-15 04:43:34.158123 | statusTimer
2020-05-15 04:43:34.169398 | path: rtsp://nabto:abc123@127.0.0.1:63911/media.amp?streamprofile=Profile8
2020-05-15 04:43:34.170979 | video play
2020-05-15 04:43:34.207935 | avformat_open_input error: Invalid data found when processing input
2020-05-15 04:43:34.208372 | Unable to open file, media.amp?streamprofile=Profile8
2020-05-15 04:43:34.209225 | Video Player error: no connection or invalid path

2020-05-15 04:44:20.138827 | viewDidAppear: DT Foscam [tunnel: 0]
2020-05-15 04:44:20.139438 | Reachability Flag Status: -R ------- networkStatusForFlags
2020-05-15 04:44:21.140918 | statusTimer
2020-05-15 04:44:21.167147 | path: rtsp://nabto:abc123@127.0.0.1:63917/videoMain
2020-05-15 04:44:21.170943 | video play
2020-05-15 04:44:21.227423 | avformat_open_input error: Invalid data found when processing input
2020-05-15 04:44:21.228413 | Unable to open file, videoMain
2020-05-15 04:44:21.230395 | Video Player error: no connection or invalid path
gammelby commented 4 years ago

If you are connecting through a gateway, the host field should contain the camera's LAN address as seen from the gateway and not 127.0.0.1. So if the gateway can reach the camera on IP 10.0.0.7, you should specify this IP address in the newly added host field in the UI. However, since it works fine on Android, you are likely already aware of this.

If you can view the feed directly on LAN without Nabto tunnels for remote access using the URL rtsp://nabto:abc123@10.0.0.7:88/videoMain you suggested above, it should indeed be possible also through the demo player app. If the gateway is online and the camera is connected, I can try from here in an attempt to debug the player.

If it proves to be a continued hassle: Since this is just an issue in the demo player component and not the communication platform, perhaps you could evaluate the platform and especially the gateway performance using other means? For instance, you can connect to the gateway using the nabto-cli tool on your Mac and then connect the VLC player to the TCP proxy spawned by the tool.

gammelby commented 4 years ago

... since you get the basic auth popup you are obviously able to connect to the camera and something else goes wrong (perhaps related to propagation of credentials). I can try to debug remotely from here as suggested above, but we should move that to email - please send the necessary connect info to me at ug at nabto dot com.

destryteeter commented 4 years ago

ok, I was able to use the nabto-cli tool to view the video stream for these two scenarios:

  1. unabto_tunnel running on Raspberry Pi, camera streaming to port 8081 with local ip 127.0.0.1
  2. unabto_tunnel running on Develco DP09/06, camera streaming to port 88 with remote ip 10.0.0.7

Following the readme in the nabto-cli repository, I was able to get this working on my mac.

I was also able to integrate the iOS NabtoClient into my mobile app (along with IJKMediaPlayer) and use the same process to view setup (1) on an iOS device. (Really cool).

However, I could not get setup (2) to work in my mobile app. It seems the issue is the cli tool allows creating the tunnel with a specific IP, while the iOS NabtoClient SDK does not:

So, the question is, how do I "Open TCP tunnel to using a non-local remote TCP server" using the iOS SDK?

destryteeter commented 4 years ago

One more comment. It looks like the Android SDK offers the ability to designate the remote IP, which is probably why I can get it working in the Android demo app, but not iOS.

public Tunnel tunnelOpenTcp(int localPort, String nabtoHost, String remoteHost, int remotePort, Session session) {
        Tunnel tunnel = NabtoCApiWrapper.nabtoTunnelOpenTcp(localPort, nabtoHost, remoteHost,
                remotePort, session);
        if(tunnel.getStatus() != NabtoStatus.OK) {
            Log.d(this.getClass().getSimpleName(),
                    "Failed to open TCP tunnel: " + tunnel.getStatus());
        }
        return tunnel;
    }
destryteeter commented 4 years ago

Eureka! I altered the iOS SDK to expose the remoteHost and was able to get streaming working for setup (2) above. Thanks for your help!

I made a PR with this fix. Looks like the framework needs to be uploaded to the nabto server and the client version needs to be updated before the cocoapod will work correctly.

gammelby commented 4 years ago

🤦 ... I apparently never got to actually pass the added host field to the SDK wrapper - and as mentioned tested with localhost as "remote" field so it worked like a charm. Thanks for the PR - it will take a bit of time for the official release, though. I hope it is sufficient with your hand-modified wrappers for the PoC in the meantime!