- May 30, 2019
-
-
Tim-Philipp Müller authored
-
There is no installed version of that, only an uninstalled version. (Ubuntu ships an installed version, but that's diverging from upstream.)
-
- May 29, 2019
-
-
Tim-Philipp Müller authored
-
- May 06, 2019
-
-
In plug_src we changed the element state before adding it to the owner container. This prevented the pipeline from intercepting a GST_STREAM_STATUS_TYPE_CREATE message from the pad in order to assign a custom task pool. Fixes #53
-
- May 01, 2019
-
-
If an address/port was previously decided upon (ex: multicast in the SDP), then use that instead of re-creating another one Fixes gstreamer/gst-rtsp-server#57
-
-
-
-
Handle the situation when a call to gst_rtsp_media_set_state is done when media status is preparing. Also add unit test for this scenario. The unit test simulate on a media level when two clients share a (live) media. Both clients have done SETUP and got responses. Now client 1 is doing play and client 2 is just closing the connection. Then without patch there are a problem when client1 is calling gst_rtsp_media_unsuspend in handle_play_request. And client2 is doing closing connection we can end up in a call to gst_rtsp_media_set_state when priv->status == GST_RTSP_MEDIA_STATUS_PREPARING and all the logic for shut down media is jumped over . With this patch and this scenario we wait until priv->status == GST_RTSP_MEDIA_STATUS_PREPARED and then continue to execute after that and now we will execute the logic for shut down media.
-
The close handler could trigger a crash because it invalidated the watch_context while still leaving a source attached to it which would be cleaned up at a later point.
-
The previous fix for race condition around finish_unprepare where the function could be called twice assumed that the status wouldn't change during execution of the function. This assumption is incorrect as the state may change, for example if an error message arrives from the pipeline bus. Instead a flag keeping track on whether the finish_unprepare function is currently executing is introduced and checked. Fixes gstreamer/gst-rtsp-server#59
-
The sequence number in the rtpinfo is supposed to be the first RTP sequence number. The "seqnum" property on a payloader is supposed to be the number from the last processed RTP packet. The sequence number for payloaders that inherit gstrtpbasepayload will not be correct in case of buffer lists. In order to fix the seqnum property on the payloaders gst-rtsp-server must get the sequence number for rtpinfo elsewhere and "seqnum-offset" from the "stats" property contains the value of the very first RTP packet in a stream. The server will, however, try to look at the last simple in the sink element and only use properties on the payloader in case there no sink elements yet, and by looking at the last sample of the sink gives the server full control of which RTP packet it looks at. If the payloader does not have the "stats" property, "seqnum" is still used since "seqnum-offset" is only present in as part of "stats" and this is still an issue not solved with this patch. Needed for gst-plugins-base!17
-
- Nov 10, 2018
-
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
It's needed by all kinds of other headers, including the ones that are required for defining the GstRTSPServer struct itself and its API.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
... by actually making it a single-include header and moving everything related to the GstRTSPServer type to rtsp-server-object.h instead. Otherwise there are too many circular includes. https://bugzilla.gnome.org/show_bug.cgi?id=797361
-
- Oct 22, 2018
-
-
Avoids ending up with races where a timeout would still be around *after* a client was gone. This could happen rather easily in RTSP-over-HTTP mode on a local connection, where each RTSP message would be sent as a different HTTP connection with the same tunnelid. If not properly removed, that timeout would then try to free again a client (and its contents).
-
- Oct 02, 2018
-
-
Tim-Philipp Müller authored
-
- Sep 16, 2018
-
-
Tim-Philipp Müller authored
-
- Aug 16, 2018
-
-
Nicolas Dufresne authored
-
- Jul 20, 2018
-
-
Tim-Philipp Müller authored
-
- Jul 16, 2018
- Jul 12, 2018
- Jun 27, 2018
-
-
Fix race when setting up source elements. Since we set the source element(s) to PLAYING state before hooking them up to the downstream funnel, it's possible for the source element to receive packets before we actually get to linking it to the funnel, in which case buffers would be pushed out on an unlinked pad, causing it to error out and stop receiving more data. We fix this by blocking the source's srcpad until we have linked it. https://bugzilla.gnome.org/show_bug.cgi?id=796160
-
- Jun 21, 2018
-
-
Matthew Waters authored
We were previously only ever waiting for a single stream to notify it's blocked status through GstRTSPStreamBlocking. Actually count streams to wait for. Fixes rtspclientsink sending SDP's without out some of the input streams. https://bugzilla.gnome.org/show_bug.cgi?id=796624
-
- May 18, 2018
- May 17, 2018
-
-
Tim-Philipp Müller authored
-
- May 14, 2018
-
-
If the connection is closed very early, the flushing marker might not get set and rtspclientsink can get deadlocked waiting for preroll forever. https://bugzilla.gnome.org/show_bug.cgi?id=786961
-
- Apr 20, 2018
-
-
When streaming data over TCP then is not the keep-alive functionality working. The reason is that the function do_send_data have changed to boolean but the code is still checking the received result from send_func with GST_RTSP_OK. The result is that a successful send_func will always lead to that do_send_data is returning false and the keep-alive will not be updated. https://bugzilla.gnome.org/show_bug.cgi?id=795321
-
- Apr 17, 2018
-
-
Sebastian Dröge authored
This reverts commit 3d275b13. While RFC 3264 (SDP) says that sendonly/recvonly are from the point of view of the requester, the actual RTSP RFCs (RFC 2326 / 7826) disagree and say the opposite, just like the ONVIF standard. Let's follow those RFCs as we're doing RTSP here, and add a property at a later time if needed to switch to the SDP RFC behaviour. https://bugzilla.gnome.org/show_bug.cgi?id=793964
-
- Apr 16, 2018
-
-
Set transport string to NULL after freeing it, so that at worst we get a NULL pointer if constructing a new transport string fails (which shouldn't really fail here). Also check return value of that, just in case. CID 1433768.
-
- Mar 30, 2018
-
-
Mathieu Duponchelle authored
This was broken since the work for delayed transport creation was merged: the creation of the transports string depends on calling stream_get_server_port, which only starts returning something meaningful after a call to stream_allocate_udp_sockets has been made, this function expects a transport that we parse from the transport string ... Significant refactoring is in order, but does not look entirely trivial, for now we put a band aid on and create a second transport string after the stream has been completed, to pass it in the request headers instead of the previous, incomplete one. https://bugzilla.gnome.org/show_bug.cgi?id=794789
-
- Mar 25, 2018
-
-
Sebastian Dröge authored
rtsp-media-factory-uri.c: In function ‘rtsp_media_factory_uri_create_element’: rtsp-media-factory-uri.c:621:17: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] data->factory = g_object_ref (factory); ^
-
- Mar 19, 2018
-
-
Tim-Philipp Müller authored
-
- Mar 13, 2018