search

CroatianMeteorNetwork / RMS

RPi Meteor Station
https://globalmeteornetwork.org/
GNU General Public License v3.0
169 stars 47 forks source link

Error with RTSP URLs That Do Not End with .sdp #299

Open jocimarjustino opened 2 weeks ago

jocimarjustino commented 2 weeks ago

I tested some cameras and video streams with URLs that have a different structure from the IMX291 standard, such as:

These URLs work normally when tested using the following command:

gst-launch-1.0 rtspsrc location="rtsp://192.168.1.16:8554/west" ! rtph264depay ! h264parse ! decodebin ! autovideosink

However, they fail in RMS.

Workaround

I managed to work around the problem for testing purposes by modifying a few lines in the file BufferedCapture.py.

I changed line 500 from:

device_url = self.extractRtspUrl(self.config.deviceID)

to:

device_url = self.extractRtspUrl(self.config.deviceID).replace('"', '')

I also commented out lines 459 and 450:

            # if not rtsp_url.endswith('/'):
            #    rtsp_url += '/'

With these changes, I was able to run RMS with these URL patterns using gst as the media_backend. When using cv2, this issue does not occur, and everything works normally.

Testing Environment

Ubuntu 20.04 ( Desktop PC )
Ubuntu 24.04 ( Desktop PC )
Cybis320 commented 1 week ago

Hi Jocimar,

I'm not entirely surprised that that kind of issue is arising as I haven't been able to test on different setup - so, thank you for the report. I'm probably missing something, but I'm confused how removing quotation marks or not adding a missing backslash helped fix the issue here as there is no quotation mark in the examples you gave. Also, there already is a backslash in one example, so the code to add one if missing should have done nothing. Could you provide the offending config file (just the device section). Are there quotation marks there? Mine looks something like this.

...
[Capture]

device: rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp ; device id
force_v4l2: false
...

Also the log file contains the exact competed URL the code generated. Something like:

2024/06/13 04:08:30-DEBUG-BufferedCapture-line:515 - GStreamer pipeline string: rtspsrc  buffer-mode=1 protocols=tcp tcp-timeout=5000000 retry=5 location="rtsp://192.168.42.103:554/user=admin&password=&channel=1&stream=0.sdp/" ! rtph264depay ! h264parse ! avdec_h264 ! queue leaky=downstream max-size-buffers=100 max-size-bytes=0 max-size-time=0 ! videoconvert ! video/x-raw,format=BGR ! queue max-size-buffers=100 max-size-bytes=0 max-size-time=0 ! appsink max-buffers=100 drop=true sync=0 name=appsink

I suspect there are quotation marks around the url in config and the code adds another set. So I agree that adding .replace('"', '') is a good fix to help parse the URL. Not sure about commenting out the backslash code. It's needed with some versions of GStreamer and I don't see it being the source of the problem here.

jocimarjustino commented 1 week ago

Hi Cybis320,

The .config is practically the same as yours.

.config

[Capture]

device: rtsp://192.168.1.199:8554/sul ; device id

; Media Backend: options are gst, cv2, or v4l2.
;
; The preferred option is 'gst', which corresponds to GStreamer Standalone. This method bypass OpenCV,
; and provides the highest timestamps accuracy.
; For the OpenCV method, choose 'cv2', this will revert to the OpenCV method which has proven to be
; stable but has poor timestamping performance.
; To force OpenCV to use v4l2, choose 'v4l2', this will attempt to use v4l2 hardware acceleration
; with OpenCV (also has poor timestamping performance compared to gst.)
; If gst, or v4l2 fails, the code reverts to cv2.
; If media_backend is not set, the code will first attempt to use GStreamer Direct, them OpenCV
media_backend: gst

uyvy_pixelformat: false

Using the original code without removing " and / this happens:

2024/06/21 12:37:28-INFO-BufferedCapture-line:572 - Camera IP ping successful!
2024/06/21 12:37:28-INFO-BufferedCapture-line:587 - Initializing the video device...
2024/06/21 12:37:28-INFO-BufferedCapture-line:588 - Device: rtsp://192.168.1.199:8554/sul
2024/06/21 12:37:28-INFO-BufferedCapture-line:597 - Initialize GStreamer Standalone Device.
2024/06/21 12:37:28-DEBUG-BufferedCapture-line:515 - GStreamer pipeline string: rtspsrc  buffer-mode=1 protocols=tcp tcp-timeout=5000000 retry=5 location="rtsp://192.168.1.199:8554/sul/" ! rtph264depay ! h264parse ! avdec_h264 ! queue leaky=downstream max-size-buffers=100 max-size-bytes=0 max-size-time=0 ! videoconvert ! video/x-raw,format=BGR ! queue max-size-buffers=100 max-size-bytes=0 max-size-time=0 ! appsink max-buffers=100 drop=true sync=0 name=appsink
2024/06/21 12:37:28-INFO-BufferedCapture-line:528 - Start time is 2024-06-21 12:37:28.465327
0:00:00.468494655  2788 0x7a7958001100 WARN                 rtspsrc gstrtspsrc.c:7062:gst_rtspsrc_send:<rtspsrc0> error: Unhandled error
0:00:00.468902021  2788 0x7a7958001100 WARN                 rtspsrc gstrtspsrc.c:7062:gst_rtspsrc_send:<rtspsrc0> error: Bad Request (400)
0:00:00.469029932  2788 0x7a7958001100 WARN                 rtspsrc gstrtspsrc.c:8528:gst_rtspsrc_open:<rtspsrc0> can't get sdp
0:00:00.469165940  2788 0x7a7958001100 WARN                 rtspsrc gstrtspsrc.c:9188:gst_rtspsrc_play:<rtspsrc0> failed to open stream
0:00:00.469489278  2788 0x7a7958001100 WARN                 rtspsrc gstrtspsrc.c:6486:gst_rtspsrc_loop:<rtspsrc0> we are not connected
Cybis320 commented 1 week ago

Thanks for the logs, Jocimar. If I see correctly, it's just the addition of the trailing slash that's causing the issue, right? There is no quotation mark issue? I wonder if we should change the code to only add a trailing slash if the config url ends with '.sdp'. So it wouldn't add one in your case and would add one to the .sdp, which is required with some camera server and newer GStreamer versions combination.

jocimarjustino commented 1 week ago

Thanks for the logs, Jocimar. If I see correctly, it's just the addition of the trailing slash that's causing the issue, right? There is no quotation mark issue? I wonder if we should change the code to only add a trailing slash if the config url ends with '.sdp'. So it wouldn't add one in your case and would add one to the .sdp, which is required with some camera server and newer GStreamer versions combination.

Yes, it seems that just removing the bar solves the problem.

However, when making the proposed change here https://github.com/CroatianMeteorNetwork/RMS/pull/301, this happened:

(vRMS) rms@rms-VirtualBox:~/source/RMS$ python -m RMS.StartCapture -d 0.02
Disabled upload because the default station code is used!
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/home/rms/source/RMS/RMS/StartCapture.py", line 41, in <module>
    from RMS.BufferedCapture import BufferedCapture
  File "/home/rms/source/RMS/RMS/BufferedCapture.py", line 451
    if rtsp_url.endswith('.sdp'):
    ^
IndentationError: expected an indented block after 'if' statement on line 449
(vRMS) rms@rms-VirtualBox:~/source/RMS$

After fixing the indentation, it worked correctly.

            rtsp_url = match.group(0)

            # Add '/' if it's missing
            if not rtsp_url.endswith('/'):
            # Add '/' if it's missing from '.sdp' URL
                if rtsp_url.endswith('.sdp'):
                    rtsp_url += '/'

            return rtsp_url
 PING 192.168.1.199 (192.168.1.199) 56(84) bytes of data.
64 bytes from 192.168.1.199: icmp_seq=1 ttl=64 time=0.354 ms

--- 192.168.1.199 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.354/0.354/0.354/0.000 ms
2024/06/25 00:24:10-INFO-BufferedCapture-line:574 - Camera IP ping successful!
2024/06/25 00:24:10-INFO-BufferedCapture-line:589 - Initializing the video device...
2024/06/25 00:24:10-INFO-BufferedCapture-line:590 - Device: rtsp://192.168.1.199:8554/sul
2024/06/25 00:24:10-INFO-BufferedCapture-line:599 - Initialize GStreamer Standalone Device.
2024/06/25 00:24:10-DEBUG-BufferedCapture-line:517 - GStreamer pipeline string: rtspsrc  buffer-mode=1 protocols=tcp tcp-timeout=5000000 retry=5 location="rtsp://192.168.1.199:8554/sul" ! rtph264depay ! h264parse ! avdec_h264 ! queue leaky=downstream max-size-buffers=100 max-size-bytes=0 max-size-time=0 ! videoconvert ! video/x-raw,format=BGR ! queue max-size-buffers=100 max-size-bytes=0 max-size-time=0 ! appsink max-buffers=100 drop=true sync=0 name=appsink
2024/06/25 00:24:10-INFO-BufferedCapture-line:530 - Start time is 2024-06-25 00:24:10.298193
/home/rms/source/RMS/RMS/StartCapture.py:118: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  time_elapsed = (datetime.datetime.utcnow() - time_start).total_seconds()
2024/06/25 00:24:13-INFO-BufferedCapture-line:650 - Video format: BGR, 720P, color: True
2024/06/25 00:24:14-INFO-BufferedCapture-line:756 - Video device opened!
2024/06/25 00:24:14-INFO-BufferedCapture-line:862 - Grabbing a new block of 256 frames...
2024/06/25 00:24:21-INFO-BufferedCapture-line:951 - Block's max frame age: 2.586 seconds. Run's dropped frames: 0
2024/06/25 00:24:21-INFO-BufferedCapture-line:1028 - New block of raw frames available for compression with starting time: 1719285851.4218843
2024/06/25 00:24:21-INFO-BufferedCapture-line:862 - Grabbing a new block of 256 frames...
2024/06/25 00:24:21-DEBUG-Compression-line:279 - Compressing frame block with start time at: 1719285851.4218843
2024/06/25 00:24:22-DEBUG-Compression-line:300 - Compression time: 1.035 s
2024/06/25 00:24:22-DEBUG-Compression-line:307 - Saving time: 0.136 s
Cybis320 commented 1 week ago

I think there is a misunderstanding. The Pull Request removes the line if not rtsp_url.endswith('/'): and replaces it with if rtsp_url.endswith('.sdp'):

jocimarjustino commented 1 week ago

You are right! I'm sorry for the mistake.

Cybis320 commented 1 week ago

No worries... I get mixed up all the time.

dvida commented 6 days ago

I merged the PR, this should fix the issue everywhere now.