RTSP on iOS14. Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0

Related to #502 (closed).

Hello! I'm using LibVLCSharp.Forms 3.6.1 and VideoLAN.LibVLC.iOS 3.3.17 I get an error while playing the rtsp stream. "Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0"

On the old version (3.3.10) it works without error.

changed the description

Does this affect the rtsp playback or is this just a command-line occurrence?

marked #570 (closed) as a duplicate of this issue

marked this issue as related to #570 (closed)

marked #568 (closed) as a duplicate of this issue

marked this issue as related to #568 (closed)

changed milestone to %3.4.0

added Bug Maintenance VLC Core user feedback labels

Hello, I'm using MobileVLCKit 3.3.17. It is working on iOS but not on iOS14.7.1 and iOS14.8.1. the log print "Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0".

marked #574 (closed) as a duplicate of this issue

marked this issue as related to #574 (closed)

Don't play RTSP live stream on iOS14.7.1 and iOS14.8.1. I'm using the MobileVLCKit 3.3.18b7 but it is not working ! the log print "Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0"!

Full log needed.

See https://videolan.videolan.me/VLCKit/interface_v_l_c_library.html#a30523c86de4b6a2fbc86f1d6a8274b59

Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0

This is not the complete log.

2021-12-31 11:56:29.700391+0800 FPWorkDemo[50252:13174542] [DBG] Creating an input for 'rtsp://172.16.0.133:8554/channel0' 2021-12-31 11:56:29.702793+0800 FPWorkDemo[50252:13174542] [DBG] reusing audio output 2021-12-31 11:56:29.702984+0800 FPWorkDemo[50252:13174542] [DBG] keeping audio output 2021-12-31 11:56:29.703705+0800 FPWorkDemo[50252:13174645] [DBG] using timeshift granularity of 50 MiB 2021-12-31 11:56:29.704098+0800 FPWorkDemo[50252:13174645] [DBG] using default timeshift path 2021-12-31 11:56:29.704501+0800 FPWorkDemo[50252:13174645] [DBG] rtsp://172.16.0.133:8554/channel0' gives access rtsp' demux any' path 172.16.0.133:8554/channel0' 2021-12-31 11:56:29.704796+0800 FPWorkDemo[50252:13174645] [DBG] creating demux: access='rtsp' demux='any' location='172.16.0.133:8554/channel0' file='(null)' 2021-12-31 11:56:29.705161+0800 FPWorkDemo[50252:13174645] [DBG] looking for access_demux module matching "rtsp": 12 candidates 2021-12-31 11:56:29.705692+0800 FPWorkDemo[50252:13174645] [DBG] version 2016.10.21 2021-12-31 11:56:34.710785+0800 FPWorkDemo[50252:13174645] [DBG] connection timeout 2021-12-31 11:56:34.712934+0800 FPWorkDemo[50252:13174645] [ERR] Failed to connect with rtsp://172.16.0.133:8554/channel0 2021-12-31 11:56:34.713648+0800 FPWorkDemo[50252:13174645] [DBG] version 2016.10.21 Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 2021-12-31 11:56:44.800287+0800 FPWorkDemo[50252:13174645] [DBG] RTP subsession 'video/H264' 2021-12-31 11:56:44.810915+0800 FPWorkDemo[50252:13174645] [DBG] selecting program id=0 2021-12-31 11:56:44.811602+0800 FPWorkDemo[50252:13174645] [DBG] setup start: 0.000000 stop:0.000000 2021-12-31 11:56:49.840326+0800 FPWorkDemo[50252:13174645] [DBG] We have a timeout of 65 seconds 2021-12-31 11:56:49.840651+0800 FPWorkDemo[50252:13174645] [DBG] play start: 0.000000 stop:0.000000 2021-12-31 11:56:49.840831+0800 FPWorkDemo[50252:13174645] [DBG] using access_demux module "live555" 2021-12-31 11:56:49.841340+0800 FPWorkDemo[50252:13174645] [DBG] looking for packetizer module matching "any": 75 candidates 2021-12-31 11:56:49.841600+0800 FPWorkDemo[50252:13174645] [DBG] using packetizer module "h264" 2021-12-31 11:56:49.841802+0800 FPWorkDemo[50252:13174645] [DBG] looking for video decoder module matching "any": 36 candidates 2021-12-31 11:56:49.843873+0800 FPWorkDemo[50252:13174645] [INF] Using Video Toolbox to decode 'h264' 2021-12-31 11:56:49.844151+0800 FPWorkDemo[50252:13174645] [DBG] using video decoder module "videotoolbox" 2021-12-31 11:56:49.844483+0800 FPWorkDemo[50252:13174645] [DBG] looking for meta reader module matching "any": 3 candidates 2021-12-31 11:56:49.844755+0800 FPWorkDemo[50252:13174645] [DBG] no meta reader modules matched 2021-12-31 11:56:49.845096+0800 FPWorkDemo[50252:13174645] [DBG] rtsp://172.16.0.133:8554/channel0' successfully opened 2021-12-31 11:56:49.845430+0800 FPWorkDemo[50252:13174645] [DBG] tk->rtpSource->hasBeenSynchronizedUsingRTCP() 2021-12-31 11:56:49.845636+0800 FPWorkDemo[50252:13174645] [DBG] Buffering 0% 2021-12-31 11:56:49.846849+0800 FPWorkDemo[50252:13174645] [DBG] Buffering 3% 2021-12-31 11:56:49.847123+0800 FPWorkDemo[50252:13174645] [DBG] Buffering 10% 2021-12-31 11:56:49.847170+0800 FPWorkDemo[50252:13174750] [DBG] found NAL_PPS (pps_id=0 sps_id=0) 2021-12-31 11:56:49.847465+0800 FPWorkDemo[50252:13174645] [DBG] Buffering 20% 2021-12-31 11:56:49.848000+0800 FPWorkDemo[50252:13174645] [DBG] Stream buffering done (310 ms in 2 ms) 2021-12-31 11:56:49.848318+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.848487+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.848668+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.849324+0800 FPWorkDemo[50252:13174645] [ERR] buffer deadlock prevented 2021-12-31 11:56:49.849556+0800 FPWorkDemo[50252:13174645] [DBG] Decoder wait done in 1 ms 2021-12-31 11:56:49.850001+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.850104+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.850626+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.850779+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.850915+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851030+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851163+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851263+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851471+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851569+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851659+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851830+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.851942+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.852042+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.852130+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.852652+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.852780+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.852880+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.852972+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.853069+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.853156+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.853247+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.864733+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.884759+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.886711+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.897310+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.903547+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.921864+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.926394+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.946528+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.965567+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:49.971833+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.017154+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.030402+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.039635+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.102400+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.126768+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.127591+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.132748+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.143716+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.152937+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:56:50.165209+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:57:00.707959+0800 FPWorkDemo[50252:13174645] [WAR] no data received in 10s, eof ? 2021-12-31 11:57:00.708278+0800 FPWorkDemo[50252:13174645] [DBG] EOF reached 2021-12-31 11:57:00.708512+0800 FPWorkDemo[50252:13174645] [DBG] waiting decoder fifos to empty 2021-12-31 11:57:00.708853+0800 FPWorkDemo[50252:13174750] [WAR] waiting for SPS/PPS 2021-12-31 11:57:00.813187+0800 FPWorkDemo[50252:13174645] [DBG] killing decoder fourcc h264' 2021-12-31 11:57:00.813474+0800 FPWorkDemo[50252:13174645] [DBG] removing module "videotoolbox" 2021-12-31 11:57:00.813672+0800 FPWorkDemo[50252:13174645] [DBG] removing module "h264" 2021-12-31 11:57:00.813854+0800 FPWorkDemo[50252:13174645] [DBG] removing module "live555" 2021-12-31 11:57:00.815223+0800 FPWorkDemo[50252:13174645] [DBG] Program doesn't contain anymore ES

@fpower Did you had a chance to fix this issue?

So, this is an often reported bug from many different users. Can anyone of you provide a RTSP stream for testing so we can see how to fix this? If you cannot, we cannot fix.

yes.i know! it is working on the VLC app! Our phones need to be connected to WiFi signals emitted by hardware to play video streams. I wonder if there is a way to put it in an accessible address, or to create a video stream in H264 format by referring to its Settings.

Or is there something wrong with the Settings when I created the player?

NSArray *options = @[@"--network-caching=300",@"--avformat-format=mgx",@"--rtsp-tcp",@"--rtp-caching=100"];

Seee #519 (closed)

See iOS15 fix

marked this issue as related to #519 (closed)

marked this issue as related to #521 (closed)

changed title from Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 to RTSP on iOS14. Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0

marked #519 (closed) as a duplicate of this issue

marked #521 (closed) as a duplicate of this issue

marked #502 (closed) as a duplicate of this issue

marked this issue as related to #502 (closed)

It seems it is an issue on iOS14 only. But it worked in the past?

We came across this in a project as well. For us, we found that the call to gethostname was unreliable on some phones. I don't know if this is something related to any specific iOS versions, but we ended up with a patch to Live555 GroupSockHelper to call getifaddrs and fetch the first IP4 address on the wireless "en0" interface found. This fixed the "invalid IP address: 0.0.0.0" error for us. This patch is linked here and was added on to a previous patch on the GroupSockHelper in the Live555 source. This patch implementation assumes the wireless interface, and as such may not be suitable everywhere.

0037-contrib-live555-fix-hostname-lookup-on-iOS-devices.patch

We did however find more issues later on which are not directly related to this issue but certainly to RTSP use cases. These were related to users running a VPN, and routing issues for some carriers that happened to overlap with an IP we are connecting to. For these we ended up commenting out the proxy query in the HTTP access module for VLC to get around the proxy, then added calls to bind the sockets used for the initial HTTP and TCP connection to the "en0" named interface. I've included the patches below, but I expect they are a bit rudimentary in their current state. You'd probably want to enable configuration options to disable the HTTP proxy and to set a preferred connection interface (cellular or wifi).

0043-Disable-proxy-query.patch

0044-Bind-HTTP-requests-and-TCP-connection-used-for-RTSP-.patch

You'd probably want to enable configuration options to disable the HTTP proxy and to set a preferred connection interface (cellular or wifi).

like --no-http-proxy?

Exactly, though I think that is disabled for mobile correct?

Proxy support is enabled by default for iOS and tvOS.

Why?

I assume this to be the expected behavior because if the user configured a proxy, s/he would expect it to be used across the apps.

changed milestone to %3.5.0

added RTSP label

removed user feedback label

added Blocker label

See #502 (comment 269214) comment

I tried with an RTSP stream and it is working here now. I have no means to reproduce this problem.

changed milestone to %3.5.1

Closing the ticket as we did not reproduce in 7 months nor received new complaints.

closed

@fkuehne I have the same problem with the 15 and 16 iOS versions. Please take a look on my ticket

Sadly, I will not have the time to look at it soon as the VLC-iOS and other subtasks in VLCKit are keeping me quite busy. I can offer a contact to a consulting company in case you need this to be fixed urgently.

It would be great to have some options in this situation.

Email me at my user name at videolan org and I'll forward you accordingly.

@Z1napp did you eventually fix the problem? We are having the same problem with some of our customers.

Hi, @thombrink , unfortunately no, I’m still having troubles with this issue. Try to play with different vlc versions and different iOS devices (some of our customers are reporting that they are having different behaviors on devices lower than iPhone 14). Please let me know if you will figure out what’s wrong :)

Hi again, @thombrink, can you tell me what this problem looks like for the end user? For our customers who have reported this issue, there has been an increase in the streaming loading time

@Z1napp if I remember correctly we had to simulate a macos mdns server. The steam loading took very long because it couldn't resolve it's own ip-address. After that request timed out, the stream started. After I implemented a simple mdns service that just retuned the caller ip-address, the streams started to load quickly again.

mentioned in issue #703 (closed)

mentioned in issue #638