- May 31, 2021
-
-
Tim-Philipp Müller authored
-
- May 24, 2021
-
-
Tim-Philipp Müller authored
Part-of: <gst-rtsp-server!208>
-
- May 05, 2021
-
-
Free the previous caps before reusing the variable for the converter caps. Part-of: <gst-rtsp-server!204>
-
gst_rtsp_message_add_header() makes a copy of the header, instead of taking ownership. Part-of: <gst-rtsp-server!204>
-
Instead of the deprecated gst_element_get_request_pad. Part-of: <gst-rtsp-server!195>
-
- Apr 29, 2021
-
-
Doug Nazar authored
It's possible for the destruction of the source to be delayed. Instead of relying on the dispose() to remove the bus watch, do it ourselves. Part-of: <gst-rtsp-server!202>
-
- Apr 27, 2021
-
-
Marc Leeman authored
Part-of: <gstreamer/gst-rtsp-server!200>
-
Marc Leeman authored
Bumped on these while investigating the example code. Part-of: <gst-rtsp-server!200>
-
- Apr 23, 2021
-
-
On computers with IPv6 disabled it shouldn't result in a test failure. Part-of: <!196>
-
This is an extension to the previous commit. There can also be cases where the start position is not specified, in those cases we should also avoid doing seeking unless it's forced. Part-of: <gstreamer/gst-rtsp-server!197>
-
- Apr 20, 2021
-
-
Doug Nazar authored
We can also skip the seek if the end range is already correct. Avoids initial seek on play start if playing full stream. Part-of: <gstreamer/gst-rtsp-server!194>
-
- Mar 19, 2021
-
-
Sebastian Dröge authored
It's sufficient to run them during the FIRST stage instead of in both. Part-of: <gstreamer/gst-rtsp-server!193>
-
- Feb 15, 2021
-
-
Part-of: <gstreamer/gst-rtsp-server!190>
-
Part-of: <gstreamer/gst-rtsp-server!190>
-
Tim-Philipp Müller authored
Part-of: <gstreamer/gst-rtsp-server!189>
-
Tim-Philipp Müller authored
Fixes gstreamer/gst-rtsp-server#130 Part-of: <gstreamer/gst-rtsp-server!189>
-
- Feb 01, 2021
-
-
Branko Subasic authored
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!187>
-
- Jan 22, 2021
-
-
Branko Subasic authored
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!184>
-
- Jan 08, 2021
-
-
rtspclientsink: Add "update-sdp" signal that allows updating the SDP before sending it to the server Part-of: <gstreamer/gst-rtsp-server!178>
-
- Dec 23, 2020
-
-
Part-of: <gstreamer/gst-rtsp-server!168>
-
As far as I can tell, this is neither explicitly allowed nor forbidden by RFC 7826. Meanwhile, URLs such as rtsp://<IP>:554 or rtsp://<IP>:554/ are in use in the wild (presumably with non-GStreamer servers). GStreamer's prior behavior was confusing, in that gst_rtsp_mount_points_add_factory() would appear to accept a mount path of "" or "/", but later connection attempts would fail with a "media not found" error. This commit makes a mount path of "/" work for either form of URL, while an empty mount path ("") is rejected and logs a warning. Part-of: <!168>
-
- Dec 21, 2020
-
-
rtspclientsink: Use proper types instead of G_TYPE_POINTER for the RTSP messages in the "handle-request" signal Part-of: <gstreamer/gst-rtsp-server!177>
-
- Dec 17, 2020
-
-
Tobias Ronge authored
Only sender streams sends the GstRTSPStreamBlocking message, so only these should be counted before setting media status to prepared. Part-of: <!180>
-
- Dec 15, 2020
-
-
Part-of: <!166>
-
- Dec 14, 2020
-
-
Lawrence Troup authored
Fixes gstreamer/gst-rtsp-server#127 Part-of: <gstreamer/gst-rtsp-server!176>
-
- Nov 18, 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!174>
-
- Nov 16, 2020
-
-
Sebastian Dröge authored
Otherwise this will cause memory corruption as the property expects a 64 bit integer. Part-of: <gstreamer/gst-rtsp-server!169>
-
- Nov 11, 2020
-
-
David Phung authored
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!167>
-
Kristofer Björkström authored
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: <!167>
-
- Oct 23, 2020
-
-
Part-of: <gstreamer/gst-rtsp-server!1>
-
- Oct 19, 2020
-
-
Sebastian Dröge authored
Part-of: <gstreamer/gst-rtsp-server!164>
-
- Oct 10, 2020
-
-
Mathieu Duponchelle authored
This is supported by the RFC, and can be useful on systems where allocating two consecutive ports is problematic, and RTCP is not necessary. Part-of: <!159>
-
- Oct 08, 2020
-
-
Part-of: <gstreamer/gst-rtsp-server!162>
-
Mathieu Duponchelle authored
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!160>
-
Mathieu Duponchelle authored
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!160>
-
- Sep 30, 2020
-
-
Seungha Yang authored
This demo example shows a way of file loop playback of a given source. Note that client seek request is not properly implemented yet. Part-of: <!154>
-
- Sep 29, 2020
-
-
David Phung authored
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!155>
-
- Sep 18, 2020
-
-
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!150>
-
- Sep 09, 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!149>
-
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!146>
-