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

changed the description

yes I am also facing this issue I am using the 3.4.0 version and some stream is not loading and some time stream is freezing so anyone have any solution please suggest here

Hi, Aalok! You can try to lock the "MobileVLCKit" version to "3.3.16.3". But it's a temporary solution. I hope someone from the development team will reply to my request...

Hii @Z1napp the version "3.3.16.3" when I am installing it also return me that this version is also 3.4.0 so I am using this version no worry.

can you please tell me your stream is freezing or stopped while playing rtsp live stream?

What do you mean by "it also return me that this version is also 3.4.0"?

I'm just having a huge delay before I get the first frame and after that, the stream behaves normally. 3.5.1 - more than 20 sec 3.3.16.3 - about 1.5 sec

return means a terminal message like that

I am using this code for play rtsp stream but some time some rtsp links are not playing

func startstream(url: String) {
        guard let url = URL(string: url) else { return }
        videoPlayer.drawable = vwPlayer
        videoPlayer.media = VLCMedia(url: url)
        videoPlayer.delegate = self
        videoPlayer.libraryInstance.debugLogging = true
        videoPlayer.media?.addOption("-vv")
        videoPlayer.media?.addOptions([
            "network-caching": 500,
            "sout-rtp-caching": 100,
            "sout-rtp-port-audio": 20000,
            "sout-rtp-port-video": 20002,
            ":rtp-timeout": 10000,
            ":rtsp-tcp": true,
            ":rtsp-frame-buffer-size":1024,
            ":rtsp-caching":500,
            ":live-caching":500,
        ])
        videoPlayer.media?.addOption(":codec=avcodec")
        videoPlayer.media?.addOption(":vcodec=h264")
        videoPlayer.media?.addOption("--file-caching=2000")
        videoPlayer.media?.addOption("clock-jitter=0")
        videoPlayer.media?.addOption("--rtsp-tcp")
        videoPlayer.media?.clearStoredCookies()
        videoPlayer.play()
        GFunction.shared.removeLoader()
    }

you have any suggestion for this @Z1napp

Hello, Aalok. I'm not sure if it's the same problem as mine.

Below is my debug log Plese check and let me know what's the issue

2023-05-25 14:32:55.984532+0530 AquaVue[50046:492686] [DBG] connection timeout 2023-05-25 14:32:55.986050+0530 AquaVue[50046:492686] [ERR] Failed to connect with rtsp://frankweeks.dyndns.biz:8554/Streaming/Channels/102 2023-05-25 14:32:55.988204+0530 AquaVue[50046:492686] [DBG] version 2016.10.21 2023-05-25 14:32:55.988618+0530 AquaVue[50046:492686] [WAR] Password in a URI is DEPRECATED 2023-05-25 14:33:01.003000+0530 AquaVue[50046:492686] [DBG] connection timeout 2023-05-25 14:33:01.004052+0530 AquaVue[50046:492686] [ERR] Failed to connect with rtsp://frankweeks.dyndns.biz:8554/Streaming/Channels/102 2023-05-25 14:33:01.004923+0530 AquaVue[50046:492686] [DBG] version 2016.10.21 2023-05-25 14:33:01.005761+0530 AquaVue[50046:492686] [WAR] Password in a URI is DEPRECATED 2023-05-25 14:33:06.010685+0530 AquaVue[50046:492686] [DBG] connection timeout 2023-05-25 14:33:06.011690+0530 AquaVue[50046:492686] [ERR] Failed to connect with rtsp://frankweeks.dyndns.biz:8554/Streaming/Channels/102 2023-05-25 14:33:06.012523+0530 AquaVue[50046:492686] [DBG] no access_demux modules matched 2023-05-25 14:33:06.015932+0530 AquaVue[50046:492686] [DBG] creating access: rtsp://subscriber:aquavue92!@frankweeks.dyndns.biz:8554/Streaming/Channels/102 2023-05-25 14:33:06.017474+0530 AquaVue[50046:492686] [DBG] looking for access module matching "rtsp": 66 candidates 2023-05-25 14:33:06.018936+0530 AquaVue[50046:492686] [DBG] try to open 'rtsp://subscriber:aquavue92!@frankweeks.dyndns.biz:8554/Streaming/Channels/102' 2023-05-25 14:33:06.019806+0530 AquaVue[50046:492686] [DBG] connect to host 'frankweeks.dyndns.biz' 2023-05-25 14:33:06.021881+0530 AquaVue[50046:492686] [DBG] net: connecting to frankweeks.dyndns.biz port 8554 2023-05-25 14:33:06.023938+0530 AquaVue[50046:492686] [ERR] cannot resolve frankweeks.dyndns.biz port 8554 : nodename nor servname provided, or not known 2023-05-25 14:33:06.024453+0530 AquaVue[50046:492686] [ERR] Failed to connect to RTSP server frankweeks.dyndns.biz:8554 2023-05-25 14:33:06.025033+0530 AquaVue[50046:492686] [DBG] try to open 'rtsp://subscriber:aquavue92!@frankweeks.dyndns.biz:8554/Streaming/Channels/102' 2023-05-25 14:33:06.025347+0530 AquaVue[50046:492686] [DBG] connect to host 'frankweeks.dyndns.biz' 2023-05-25 14:33:06.025636+0530 AquaVue[50046:492686] [DBG] net: connecting to frankweeks.dyndns.biz port 8554 2023-05-25 14:33:06.026644+0530 AquaVue[50046:492686] [ERR] cannot resolve frankweeks.dyndns.biz port 8554 : nodename nor servname provided, or not known 2023-05-25 14:33:06.026998+0530 AquaVue[50046:492686] [ERR] Failed to connect to RTSP server frankweeks.dyndns.biz:8554 2023-05-25 14:33:06.027441+0530 AquaVue[50046:492686] [DBG] try to open 'rtsp://subscriber:aquavue92!@frankweeks.dyndns.biz:8554/Streaming/Channels/102' 2023-05-25 14:33:06.027766+0530 AquaVue[50046:492686] [DBG] connect to host 'frankweeks.dyndns.biz' 2023-05-25 14:33:06.028087+0530 AquaVue[50046:492686] [DBG] net: connecting to frankweeks.dyndns.biz port 8554 2023-05-25 14:33:06.029109+0530 AquaVue[50046:492686] [ERR] cannot resolve frankweeks.dyndns.biz port 8554 : nodename nor servname provided, or not known 2023-05-25 14:33:06.029386+0530 AquaVue[50046:492686] [ERR] Failed to connect to RTSP server frankweeks.dyndns.biz:8554 2023-05-25 14:33:06.029969+0530 AquaVue[50046:492686] [DBG] no access modules matched 2023-05-25 14:33:06.030683+0530 AquaVue[50046:492686] [ERR] Your input can't be opened 2023-05-25 14:33:06.030963+0530 AquaVue[50046:492686] [ERR] VLC is unable to open the MRL 'rtsp://subscriber:aquavue92!@frankweeks.dyndns.biz:8554/Streaming/Channels/102'. Check the log for details. VLCMediaPlayerDelegate: STOPPED observer calledSTOPPED 2023-05-25 14:33:06.063838+0530 AquaVue[50046:491714] [DBG] VLC media player - 3.0.12.1 Vetinari 2023-05-25 14:33:06.064041+0530 AquaVue[50046:492629] [DBG] removing module "audiounit_ios" 2023-05-25 14:33:06.064237+0530 AquaVue[50046:491714] [DBG] Copyright © 1996-2021 the VideoLAN team 2023-05-25 14:33:06.064474+0530 AquaVue[50046:491714] [DBG] revision 3.0.12.1-153-g001ad0071d 2023-05-25 14:33:06.064765+0530 AquaVue[50046:491714] [DBG] configured with /Users/fkuehne/videolan/gits/VLCKit-3.0-AS/libvlc/vlc/configure '--prefix=/Users/fkuehne/videolan/gits/VLCKit-3.0-AS/libvlc/vlc/install-iPhoneSimulator/x86_64' '--host=x86_64-apple-darwin' '--with-contrib=/Users/fkuehne/videolan/gits/VLCKit-3.0-AS/libvlc/vlc/contrib/iPhoneSimulator-x86_64-apple-darwin-x86_64' '--enable-static' '--enable-dvbpsi' '--enable-avcodec' '--disable-macosx' '--disable-macosx-qtkit' '--disable-macosx-avfoundation' '--disable-shared' '--enable-opus' '--disable-faad' '--disable-lua' '--disable-a52' '--enable-fribidi' '--disable-qt' '--disable-skins2' '--disable-vcd' '--disable-vlc' '--disable-vlm' '--disable-nls' '--disable-sse' '--disable-notify' '--enable-live555' '--enable-realrtsp' '--enable-swscale' '--disable-projectm' '--enable-libass' '--enable-libxml2' '--disable-goom' '--disable-dvdread' '--disable-dvdnav' '--disable-bluray' '--disable-linsys' '--disable-libva' '--disable-gme' '--disable-tremor' '--enable-vorbis' '--disable-fluidsynth' '--disable-jack' '--disable-pulse' '--disable-mtp' '--enable-ogg' '--enable-speex' '--enable-theora' '--enable-flac' '--disable-screen' '--enable-freetype' '--enable-taglib' '--enable-smb2' '--disable-mmx' '--disable-sparkle' '--disable-addonmanagermodules' '--disable-mad' 'host_alias=x86_64-apple-darwin' 'CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang' 'CFLAGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.4.sdk -mios-simulator-version-min=8.4 -arch x86_64 -DNDEBUG' 'LDFLAGS=-arch x86_64 -Wl,-ios_simulator_version_min,8.4' 'CPPFLAGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.4.sdk -mios-simulator-version-min=8.4 -arch x86_64' 'CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++' 'CXXFLAGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.4.sdk -mios-simulator-version-min=8.4 -arch x86_64' 'OBJC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang' 'OBJCFLAGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.4.sdk -mios-simulator-version-min=8.4 -arch x86_64' 'PKG_CONFIG_PATH='

Hi again, Aalok. As I said I'm not sure if it's the same issue. Probably it will be better to create a separate issue for this.

added RTSP label

mentioned in issue #560 (closed)

Good morning!

After years of use of VLCKit on macOS, where the issue reported here (and also in #502 (closed) and #560 (closed)) never manifested, I've recently started experimenting with the library on iOS, and I'm also seeing the following message logged on the console:

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

This message is logged 4 to 6 times, with an interval of about 5 seconds between each, and any RTSP stream I have tested doesn't start playback until after the last iteration is logged (so, with a delay of at least 20 seconds before playback starts).

For me, this is happening using VLCKit 3.6.0b10 in an app running on iOS 17 that has been compiled on Xcode 15.0.

I have tested different devices, also running iOS 16, and on every one RTSP playback is dramatically delayed.

The message is not logged when running in the Simulator, where indeed playback is instantaneous.

My understanding of what's happening is extremely limited, but I tried reading everything that was posted on this issue and spelunking in code I don't really understand. Please excuse if what follows isn't helpful to debug this.

My uneducated guess is that this issue might either be caused by:

A regression to a patch to Live555 from a couple years back (!91 (merged)), which I understand @fkuehne made to address the fact that iOS expects a hostname to have .local suffix;
Or, possibly, the fact that a similar request to the OS for the hostname happens somewhere else in the code, where it's not yet patched to include the required .local suffix.

I've tried opening the /libvlc/vlc/contrib/src/live555/rules.mak file in my cloned and built VLCKit 3.6.0b10 ƒ and it seems, to my ignorant eyes, that the necessary statements are still there:

83     # Disable Multicast interface lookup option
84	$(APPLY) $(SRC)/live555/DISABLE_LOOPBACK_IP_ADDRESS_CHECK.patch
...
95	$(APPLY) $(SRC)/live555/groupsock-fix-hostname-lookup-on-iOS.patch

... but I don't really know how patches are applied and I might be looking in the wrong place, or again maybe there are other functions that ask iOS for the hostname without the expected suffix, triggering the delay.

If the latter hypothesis were true, that additional and not-yet-patched request for the hostname must have been added after 3.3.10: the OP in #560 (closed) mentions they didn't experience the delay with that release.

Or maybe I am looking at this from the wrong side, and this is not a bug at all: after seeing mentioned on Apple forums that requesting a com.apple.developer.networking.multicast special entitlement would address the Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 log message, I searched the issues here for any mention of that entitlement.

I found #638, which indeed refers to a significant delay in RTSP playback.

So, my question in case this is not a bug, but expected behavior: do I – and everyone else experiencing this (quite frequent, from what I've read) issue – just ask Apple for the com.apple.developer.networking.multicast entitlement?

Thanks in advance, and as always, for any suggestions; I am obviously happy to test anything that might help.

We are aware of the problem, but we are unable to reproduce this in a reliable manner. Also, the reports on this tracker are of intermittent detail. We'd be happy to have a look especially if we were provided with a sample stream that can be reliably used for weeks (if you tell us which webcam to buy, that's also possible). We can also provide consulting services if needed.

Regarding my patch, it made things better in the iOS 13/14 era if I remember correctly. With iOS 17, that code path is more or less dead as gethostname() on that OS version will always return "localhost.local" (for privacy reasons), so in conclusio the lookup will always fail.

RTSP can involve multicast UDP content, but does not require to have it. This depends on stream and server configuration. So, if you have multicast content, yes, then you need the entitlement. If you are doing UDP unicast, then, no.

Thank you for your kind reply.

I have just sent you an email containing a RTSP URL that you'll be able to use for testing, and that is showing the delay reliably. It's from a Foscam FI9900P camera from a few years ago, but I'm also seeing the issue with some Hikvisions, TP-Link Tapo C200/210 and one Eufy camera (so, each camera I could test with).

Since my app is a generic RTSP player and can therefore deal with any kind of camera, I have applied for the multicast entitlement. I will report back when (if) it is granted, both if there are or aren't changes with this issue; thank you also for the very clear details you provided about this.

Have a great day!

Good morning, @cdf1982!

You can check the different VLC library versions as a workaround. For me, both the 3.5.1 and 3.6.0b4 versions are running extremely slowly, and I've experimented with several different VLC versions. You might want to give version 3.3.0 a try. Although you may still encounter the message "Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0," it will be thrown asynchronously a couple of times, and you won't need to wait for it.

It's still not a good solution to lock the version, because some of my customers are facing this delay, but at least you can try. Please let me know if this proves helpful! :)

@fkuehne, please let us know if we should request multicast entitlement to resolve this issue or if there are any scheduled fixes in place for it.

Thank you @Z1napp!

I will try compiling version 3.3.0 and report back .

In the meantime, I've also tried initialising the mediaPlayer with the "--rtsp-tcp" option, but it didn't improve the delay, and the Unable to determine our source address is still logged.

This last experiment makes me wonder about the multicast entitlement, because my understanding (which might be wrong) from the post on Apple's forums I linked earlier was that it might be necessary for UDP traffic, but if the issue is still there when streaming TCP packets...

@Z1napp regarding the multicast entitlement, see my statement above.

We currently do not have any pending or scheduled changes here.

Hello.

Apple has just granted my request for the com.apple.developer.networking.multicast special entitlement and I am happy to report that adding such managed Multicast entitlement to my app made the logged message go away, and most importantly drove the delay in playing RTSP on device down to basically zero (sub-1 second for loading a 1080p stream in WiFi or with medium-signal 5G... ), just as my prototype app was behaving in the Simulator.

At the moment I can only test on my iPhone (12 Pro running iOS 17.0.2) and on my iPad 10th gen (iPadOS 17.0.2), so my exceptionally positive experience is not a guarantee of equal results on previous versions of the operating systems, or with different devices (or compiling with Xcode versions older than 15.0).

But! It's hard for me to imagine that this dramatic change is a coincidence, so my suggestion for @Z1napp and for everyone else experiencing the delay is to apply for the entitlement.

Obviously, this is not my issue to close, but if Vadym's experience will match mine, I think this might be consider resolved.

Hope this helps, have a great week-end (mine certainly just got a lot better!) and a special thanks to @fkuehne (this is becoming an habit for me ;)!

Good morning, @cdf1982 ! I'm glad to hear that the issue has been resolved on your end :)

Yesterday, some of my customers and the support team updated to iOS 17, and unfortunately, the delay increased from 1 second to 30 seconds. I updated my device as well and experienced the same result.

I will attempt to request this entitlement, and I'm hopeful it will help. Thank you for your feedback!

@cdf1982 Good afternoon! Could you please contact me by email (aiozz@hotmail.com)? I have a question regarding this multicast property and I would like to ask it personally if you don't mind :)

The problem Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0 is gone after adding the multicast entitlement. Thank you all for the participation!

closed

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

Child items 0

Activity