Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
When receiving RTCP packets early the funnel is not ready yet and
GST_FLOW_FLUSHING will be returned when pushing data to it's srcpad.
This causes the thread that handle RTCP packets to go to pause mode.
Since this thread is in pause mode there will be no further callbacks to
handle keep-alive for incoming RTCP packets. This will make the session
time out if the client is not using another keep-alive mechanism.
Change-Id: Idb29db05f59c06423fa693a2aeeacbe3a1883fc5
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/211>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/210>
|
|
|
|
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/208>
|
|
Free the previous caps before reusing the variable for the converter caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/204>
|
|
gst_rtsp_message_add_header() makes a copy of the header, instead
of taking ownership.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/204>
|
|
Instead of the deprecated gst_element_get_request_pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/195>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/202>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/200>
|
|
Bumped on these while investigating the example code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/200>
|
|
On computers with IPv6 disabled it shouldn't result in a test failure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/197>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/194>
|
|
It's sufficient to run them during the FIRST stage instead of in both.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/193>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/190>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/190>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/189>
|
|
Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/130
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/189>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/187>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/184>
|
|
sending it to the server
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/178>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/168>
|
|
messages in the "handle-request" signal
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/177>
|
|
Only sender streams sends the GstRTSPStreamBlocking message, so only
these should be counted before setting media status to prepared.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/180>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/166>
|
|
Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/127
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/176>
|
|
This lets us provide a clock_rate in a fashion similar to the
other code paths in get_rtpinfo()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/174>
|
|
Otherwise this will cause memory corruption as the property expects a 64
bit integer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/169>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/167>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/167>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/1>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/164>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/159>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/162>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/160>
|
|
We don't unblock the stream anymore before replying to the
play request (883ddc72bb5bc57c95a9e167814d1ac53fe1b443),
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 https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/115
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/160>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/154>
|
|
The get-storage signal of rtpbin increases the ref count of the storage.
So we have to unref it after usage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/155>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/150>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/149>
|
|
This allows negotiating a SDP with all streams present, but only
start sending packets at some later point in time
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/146>
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/147>
|
|
|
|
|
|
|
|
|
|
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/145>
|