×

INDI Library v1.9.7 Released (29 Jul 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

IP camera rtsp support URL string for indi_webcam

  • Posts: 22
  • Thank you received: 1
as indi_webcam seems to be based on ffmpeg, it should not be a problem to implement an input field for the complete URL to open eg. rtsp streams. Or maybe as an alternative implement the ONVIF standard to discover and display IP (security) camera streams. The present method only allows to make simple http statements with port, username and password. That is unfortunately not flexible enough for a lot of cameras. Maybe the feature is already there and I'm to stupid to use it...

Markus
4 months 3 weeks ago #81536

Please Log in or Create an account to join the conversation.

Sounds like a good idea. I'll ask Robert to see if that's possible.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
The following user(s) said Thank You: Markus Kempf
4 months 3 weeks ago #81538

Please Log in or Create an account to join the conversation.

  • Posts: 22
  • Thank you received: 1
Many thanks for the consideration.

example URL: rtsp://192.168.76.71:554//user=admin_password=Cam1_channel=1_stream=0.sdp?real_stream
or
rtsp://admin:password@ip_address:554/h264Preview_01_main
4 months 3 weeks ago #81539

Please Log in or Create an account to join the conversation.

  • Posts: 2738
  • Thank you received: 766
Hi there, I have done a bunch of work on INDI Webcam in the last few days and I was trying to include this feature. I definitely made it possible to enter a custom path, but I was trying to connect to an RSTP source. It seems though that none of my ffmpeg builds whether on my Mac or linux machine support RSTP. RSTP is listed on the ffmpeg website and it says that all protocols are enabled by default. But if I tried to connect to an rstp stream, it says protocol not found and if I type "ffmpeg -protocols" at the command line, rstp is not on the list. Is this protocol not supported by default?
The following user(s) said Thank You: Alfred, Markus Kempf
3 months 3 weeks ago #82497

Please Log in or Create an account to join the conversation.

  • Posts: 22
  • Thank you received: 1
you talk about rstp but it is rtsp. I'm 100% sure that rtsp is supported by default in the Debian/Ubuntu distributions and the Windows x64 binaries distribution of ffmpeg. You can check it with the ffplay <URL> command to receive a stream.

Markus
3 months 2 weeks ago #82515

Please Log in or Create an account to join the conversation.

  • Posts: 2738
  • Thank you received: 766
Sorry that was a typo on my part. I may have made the same typo when trying to connect to the stream. I tried it again making sure that it was correct and got a little farther, but it seems that there are still some issues with supporting rtsp. I will need to study this further. The options that work for the http stream and from the other sources do not seem to work well for rtsp. I will have to experiment some more. Fortunately, my cell phone ip camera app does support rtsp streaming so I can test it. by the way, my URL appears to be in this form:

rtsp://user:password@IPAddress:Port/live
3 months 2 weeks ago #82518

Please Log in or Create an account to join the conversation.

  • Posts: 22
  • Thank you received: 1
Rob, maybe it is helpful to know that rtsp is just a protocol to transmit technical parameters like resolution or used codec. The data itself is transmitted via the rtp protocol. I just downloaded the current release 5.01 build for Windows x64 (gyan.dev) and used ffplay to play various rtsp URLs (Reolink, unknown chinese OEM vendor, v4l2rtspserver, vlc acting as server). Worked perfectly. Unfortunately there is a great variety of possible URLs. Every security cam vendor has a diiferent opinion. Thats the reason I asked for a generic input string. There is little to be gained by wrapping this up in a menu. I do not know how this translates into an API call inside your indi webcam driver, but I hope for working solution. Thank you very much already.

Markus
3 months 2 weeks ago #82522

Please Log in or Create an account to join the conversation.

  • Posts: 2738
  • Thank you received: 766
So yes, I understand the need for a custom URL and I have already added that as you requested. I would like it for the user to be able to just type in the IP, the name, etc like I had done for HTTP, but I understand that won't be possible if all the camera stream URL's are different. The problem now is that the different protocols will have different settings/options that need to be set in the code in order for them to work properly. Here is the list from their website: ffmpeg.org/ffmpeg-protocols.html. I tried connecting to an RTSP stream using the same options that I had set for the other methods of connection. It failed to connect. One issue is the "timeout" option that was required for capture devices and for IP cameras with http access, but apparently means something completely different for an RTSP stream. There seems to be a separate option called "listen_timeout" that only exists for RTSP. It worked better when I disabled the timeout for RTSP, but I will need to investigate it since it was important in the others. There is another option called "rtsp_transport" that may or may not be needed to get it to work right. Regardless, once I got it so it connected, I tried to get a frame the way I do with the other protocols and it crashed inside one of the ffmpeg libraries. So, I will need to spend some more time investigating this.

Note that I am not accessing the separate FFMPEG program via an external command line command, I am using libavformat and other internal methods and objects of ffmpeg to get this to work. So it might work a little differently than it does from the command line. So something that "just works" at the command line might require a little internal finagling to get it to work internally.

One concern that I have about introducing the custom URL is that people will try other protocols that may or may not work properly because they require special commands or options internally. But I think it is still important so I added it as you requested. We can work out those issues in the future I guess.
The following user(s) said Thank You: Markus Kempf
3 months 2 weeks ago #82524

Please Log in or Create an account to join the conversation.

  • Posts: 22
  • Thank you received: 1
thank you very much for enabling this feature request. Looking forward to test it with the upcoming May release.

Markus
3 months 3 days ago #82834

Please Log in or Create an account to join the conversation.

Time to create page: 0.633 seconds