×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

IP camera rtsp support URL string for indi_webcam

  • Posts: 80
  • Thank you received: 4
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
2 years 1 week 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.
The following user(s) said Thank You: Markus Kempf
2 years 1 week ago #81538

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

  • Posts: 80
  • Thank you received: 4
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
2 years 1 week ago #81539

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

  • Posts: 2876
  • Thank you received: 809
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
1 year 11 months ago #82497

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

  • Posts: 80
  • Thank you received: 4
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
1 year 11 months ago #82515

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

  • Posts: 2876
  • Thank you received: 809
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
1 year 11 months ago #82518

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

  • Posts: 80
  • Thank you received: 4
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
1 year 11 months ago #82522

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

  • Posts: 2876
  • Thank you received: 809
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
1 year 11 months ago #82524

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

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

Markus
1 year 10 months ago #82834

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

  • Posts: 29
  • Thank you received: 3
Sorry for bumping up this old thread, just wanted to make sure that rtsp was finally supported, I can't seem to connect here and I wanted to make sure that someone else was successful. It looks like ffmpeg is officially supported, can I call the ffmpeg command ffplay directly?

Watch a stream tunneled over HTTP:ffplay -rtsp_transport http rtsp://server/video.mp4

Last edit: 1 year 2 months ago by lanco.
1 year 2 months ago #89678
Attachments:

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

  • Posts: 401
  • Thank you received: 41
Rob if by any chance found something else, please give us a heads up. It would be more than great to be able to use our surveillance outdoor cameras like this. Unfortunately many of them do not provide still images (so http).

For example my Tapo TPlink camera streams at: rtsp://admin:pass@192.168.x.x:554/stream1

I've tried a few things with he config file but unfortunately no luck :-(
1 year 3 weeks ago #91010

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

  • Posts: 2876
  • Thank you received: 809
Sorry I haven't had a chance to look at this recently. I'm very busy right now with work related stuff and I'm behind on some of my personal projects like this, but I think in the next month or two I should have some more time since we are getting to the part of the year when I tend to have more time.

Thanks,

Rob
The following user(s) said Thank You: Euripides
1 year 3 weeks ago #91012

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

Time to create page: 0.809 seconds