- Mar 15, 2021
-
-
Tim-Philipp Müller authored
-
- Feb 16, 2021
-
-
Tim-Philipp Müller authored
Part-of: <!192>
-
Tim-Philipp Müller authored
Part-of: <gstreamer/gst-rtsp-server!192>
-
Tim-Philipp Müller authored
Part-of: <gstreamer/gst-rtsp-server!191>
-
Tim-Philipp Müller authored
Fixes gstreamer/gst-rtsp-server#130 Part-of: <gstreamer/gst-rtsp-server!191>
-
- Feb 03, 2021
-
-
Currently the send_func() runs in a thread of its own which is started the first time we enter handle_new_sample(). It runs in an outer loop until priv->continue_sending is FALSE, which happens when a TEARDOWN request is received. We use a local variable, cont, which is initialized to TRUE, meaning that we will always enter the outer loop, and at the end of the outer loop we assign it the value of priv->continue_sending. Within the outer loop there is an inner loop, where we wait to be signaled when there is more data to send. The inner loop is exited when priv->send_cookie has changed value, which it does when more data is available or when a TEARDOWN has been received. But if we get a TEARDOWN before send_func() is entered we will get stuck in the inner loop because no one will increase priv->session_cookie anymore. By not entering the outer loop in send_func() if priv->continue_sending is FALSE we make sure that we do not get stuck in send_func()'s inner loop should we receive a TEARDOWN before the send thread has started. Change-Id: I7338a0ea60ea435bb685f875965f5165839afa20 Part-of: <gstreamer/gst-rtsp-server!188>
-
- Jan 27, 2021
-
-
When tunneling RTP over RTSP the stream transports are stored in a hash table in the GstRTSPClientPrivate struct. They are used for, among other things, mapping channel id to stream transports when receiving data from the client. The stream tranports are created and added to the hash table in handle_setup_request(), but unfortuately they are not removed in handle_teardown_request(). This means that if the client sends data on the RTSP connection after it has sent the TEARDOWN, which is often the case when audio backchannel is enabled, handle_data() will still be able to map the channel to a session transport and pass the data along to it. Which eventually leads to a failing assert in gst_rtsp_stream_recv_rtp() because the stream is no longer joined to a bin. We avoid this by removing the stream transports from the hash table when we handle the TEARDOWN request. Part-of: <gstreamer/gst-rtsp-server!186>
-
- Jan 14, 2021
-
-
Tim-Philipp Müller authored
-
- Jan 13, 2021
-
-
Tim-Philipp Müller authored
-
- Dec 23, 2020
-
-
Only sender streams sends the GstRTSPStreamBlocking message, so only these should be counted before setting media status to prepared. Part-of: <gstreamer/gst-rtsp-server!182>
-
- Dec 15, 2020
-
-
Fixes gstreamer/gst-rtsp-server#127 Part-of: <gstreamer/gst-rtsp-server!179>
-
- Dec 06, 2020
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Nov 23, 2020
-
-
Mathieu Duponchelle authored
This lets us provide a clock_rate in a fashion similar to the other code paths in get_rtpinfo() Part-of: <gstreamer/gst-rtsp-server!175>
-
- Nov 16, 2020
-
-
To prevent cases with prerolling when the inactive stream prerolls first and the server proceeds without waiting for the active stream, we will ignore GstRTSPStreamBlocking messages from incomplete streams. When there are no complete streams (during DESCRIBE), we will listen to all streams. Part-of: <gstreamer/gst-rtsp-server!173>
-
Add another seek_one_active_stream test but with a demuxer. The demuxer will flush both streams in opposed to the existing test which only flushes the active stream. This will help exposing problems with the prerolling process after a flushing seek. Part-of: <gstreamer/gst-rtsp-server!173>
-
Otherwise this will cause memory corruption as the property expects a 64 bit integer. Part-of: <gstreamer/gst-rtsp-server!172>
-
The get-storage signal of rtpbin increases the ref count of the storage. So we have to unref it after usage. Part-of: <gstreamer/gst-rtsp-server!171>
-
When play a media with both sender and receiver stream, like ONVIF back channel audio in, gst_rtsp_media_get_rates call gst_rtsp_stream_get_rates for each stream to set the rates. But gst_rtsp_stream_get_rates return false for the receiver steam, which lead a g_assert crash. Instead to get rates on all streams, now just get rates on sender streams. Part-of: <gstreamer/gst-rtsp-server!170>
-
- Oct 27, 2020
-
-
Tim-Philipp Müller authored
-
- Oct 26, 2020
-
-
Tim-Philipp Müller authored
-
- Oct 10, 2020
-
-
When blocking, the sink element will not have received a buffer yet and the position query will fail. Instead, we make use of the running time of the buffer we blocked on. Part-of: <gstreamer/gst-rtsp-server!163>
-
We don't unblock the stream anymore before replying to the play request (883ddc72), so the sinks don't have a last-sample after potentially flush seeking. seek_trickmode waits for preroll however, which means the stream will block and wait for a first buffer. Subsequent calls to get_rtpinfo() can thus make use of the information. See gstreamer/gst-rtsp-server#115 Part-of: <gstreamer/gst-rtsp-server!163>
-
- Sep 30, 2020
-
-
ulpfec correction is obviously useless when receiving a stream over TCP, and in TCP modes the rtp storage receives non timestamped buffers, causing it to queue buffers indefinitely, until the queue grows so large that sanity checks kick in and warnings start to get emitted. Part-of: <gstreamer/gst-rtsp-server!158>
-
This allows negotiating a SDP with all streams present, but only start sending packets at some later point in time Part-of: <gstreamer/gst-rtsp-server!157>
-
rtsp_media_unsuspend() is called from handle_play_request() before sending the play response. Unblocking the streams here was causing data to be sent out before the client was ready to handle it, with obvious side effects such as initial packets getting discarded, causing decoding errors. Instead we can simply let the media streams be unblocked when the state of the media is set to PLAYING, which occurs after sending the play response. Part-of: <gstreamer/gst-rtsp-server!156>
-
- Sep 08, 2020
-
-
Tim-Philipp Müller authored
-
- Sep 07, 2020
-
-
Tim-Philipp Müller authored
-
- Aug 20, 2020
- Aug 03, 2020
-
-
Jordan Petridіs authored
clang 10 is complaining about incompatible types due to the glib typesystem. ``` ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-thread-pool.c:534:10: error: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'GThreadPool **' (aka 'struct _GThreadPool **') [-Werror,-Wincompatible-pointer-types] ``` Part-of: <gstreamer/gst-rtsp-server!145>
-
Jordan Petridіs authored
clang 10 is complaining about incompatible types due to the glib typesystem. ``` ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-thread-pool.c:534:10: error: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'GThreadPool **' (aka 'struct _GThreadPool **') [-Werror,-Wincompatible-pointer-types] ``` Part-of: <gstreamer/gst-rtsp-server!145>
-
- Jul 15, 2020
-
-
Srimanta Panda authored
Fixed a resource leak for mikey message while adding crypto session failed. Part-of: <gstreamer/gst-rtsp-server!144>
-
- Jul 08, 2020
-
-
Tim-Philipp Müller authored
Part-of: <!143>
-
- Jul 06, 2020
-
-
This causes them to send caps events before data flow, which is usually a pretty correct thing to do! Not doing so manifested in a bug where ssrcdemux wouldn't forward the caps it had received with an extra ssrc field, as it hadn't received any caps event. Fixes #85 Part-of: <gstreamer/gst-rtsp-server!141>
-
- Jul 03, 2020
-
-
Tim-Philipp Müller authored
-
- Jul 02, 2020
-
-
Tim-Philipp Müller authored
-
- Jun 23, 2020
-
-
Thibault Saunier authored
-
- Jun 22, 2020
-
-
Sebastian Dröge authored
Part-of: <gstreamer/gst-rtsp-server!138>
-
Sebastian Dröge authored
It's deprecated, unneeded and doesn't do anything anymore. Part-of: <gstreamer/gst-rtsp-server!138>
-
- Jun 19, 2020
-
-
Tim-Philipp Müller authored
-