gst-rtsp-server issueshttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues2023-10-17T17:30:02Zhttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/153GStreamer - RTSP - Python - Could not open resource for reading and writing.2023-10-17T17:30:02ZVishak RajGStreamer - RTSP - Python - Could not open resource for reading and writing.Hello,
I have been using the camera to read the frames using gstreamer with opencv-python,
`cap = cv2.VideoCapture('rtspsrc location=rtsp://username:password@112.112.12.45:554/1/h265major latency=200 ! queue ! rtph265depay ! h265parse...Hello,
I have been using the camera to read the frames using gstreamer with opencv-python,
`cap = cv2.VideoCapture('rtspsrc location=rtsp://username:password@112.112.12.45:554/1/h265major latency=200 ! queue ! rtph265depay ! h265parse ! omxh265dec ! nvvidconv ! video/x-raw,format=BGRx ! videoconvert ! video/x-raw,format=BGR ! queue ! appsink', cv2.CAP_GSTREAMER)
`
I got this warning,
`(python3:2507): GStreamer-CRITICAL **: 19:19:38.746: gst_element_post_message: assertion 'GST_IS_ELEMENT (element)' failed
GStreamer warning: Embedded video playback halted; module rtspsrc81 reported: Could not open resource for reading and writing.
`
how to solve this issue, thankshttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/35Race between gst_rtsp_client_close() and client_watch_notify() leads to undef...2021-09-24T11:03:49ZBugzilla Migration UserRace between gst_rtsp_client_close() and client_watch_notify() leads to undefined behaviour## Submitted by Kseniya Vasilchuk
**[Link to original bug (#790909)](https://bugzilla.gnome.org/show_bug.cgi?id=790909)**
## Description
Created attachment 364515
prevent undefined behaviour
The failed preroll causes client_w...## Submitted by Kseniya Vasilchuk
**[Link to original bug (#790909)](https://bugzilla.gnome.org/show_bug.cgi?id=790909)**
## Description
Created attachment 364515
prevent undefined behaviour
The failed preroll causes client_watch_notify() which calls rtsp_ctrl_timeout_remove() function.
This function calls g_main_context_find_source_by_id() which use priv->watch_context to find the source to destroy it.
But if in the same time gst_rtsp_client_close() was called (e.g. by gst_rtsp_server_client_filter() function) it can unref and set priv->watch_context to NULL before rtsp_ctrl_timeout_remove().
In this case manual on g_main_context_find_source_by_id() says:
if GMainContext is NULL, the default context will be used. But we don't use default context in rtsp client so we trying to find non-existent source, it means:
//-> from https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html
It is a programmer error to attempt to lookup a non-existent source.
More specifically: source IDs can be reissued after a source has been destroyed and therefore it is never valid to use this function with a source ID which may have already been removed. An example is when scheduling an idle to run in another thread with g_idle_add(): the idle may already have run and been removed by the time this function is called on its (now invalid) source ID. This source ID may have been reissued, leading to the operation being performed against the wrong source.
//<-
So we have undefined behaviour here.
P.S.
If we are lucky and default context does not have source with such id, it causes "g_source_destroy: assertion 'source != NULL' failed".
I've attached a patch to prevent use g_main_context_find_source_by_id() with NULL GMainContext. Please watch it.
~~**Patch 364515**~~, "prevent undefined behaviour":
[prevent_undefined_behaviour.patch](/uploads/7b609ca870f2c09ea6824b463b6d4c0c/prevent_undefined_behaviour.patch)https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/18Client network loss causes stream freeze with UDP streams and a shared pipeline2021-09-24T11:03:54ZBugzilla Migration UserClient network loss causes stream freeze with UDP streams and a shared pipeline## Submitted by clo..@..il.com
**[Link to original bug (#761100)](https://bugzilla.gnome.org/show_bug.cgi?id=761100)**
## Description
If a client suddenly loses network connectivity, then it can cause other clients to disconnect or ...## Submitted by clo..@..il.com
**[Link to original bug (#761100)](https://bugzilla.gnome.org/show_bug.cgi?id=761100)**
## Description
If a client suddenly loses network connectivity, then it can cause other clients to disconnect or their streams to freeze IF any one client us utilizing UDP.
This only happens on a shared pipeline, and with UDP as the only set transport.
Steps to reproduce:
1) In gst-rtsp-server/examples/test-video.c, insert "gst_rtsp_media_factory_set_shared(factory, TRUE);" to line 136, and "gst_rtsp_media_factory_set_protocols(factory, GST_RTSP_LOWER_TRANS_UDP);" to line 137.
2) Recompile the gst-rtsp-server examples (navigate to the root directory, and run make)
3) Navigate to the example directory, and run the "test-video" shell script
4) use ifconfig to get your eth0/wlan0 IP address
5) Run the following command in a new terminal: "gst-launch-1.0 rtspsrc location=rtsp://<eth0/wlan0 IP address>:8554/test protocols=0x1 ! fakesink"
6) Open a VLC client, and connect to the localhost IP address - rtsp://127.0.0.1:8554/test
7) In another terminal, execute the following command: "sudo ip link set <eth0/wlan0> down"
This should cause the VLC client to quickly freeze it's current stream. The gst-launch-1.0 client will take some time before it disconnects, but during that time if you reconnect the VLC client to the localhost IP, the stream will continue.
There appears to be an issue with how UDP handles multiple clients on a shared pipeline. I can run any combination of UDP and TCP clients, and experience the issue if ANY one client loses their connection, even if that client is a TCP client. However, if the server is configured to only allow TCP connections, this issue never occurs.
Version: 1.6.0