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>
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>
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>
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>
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>
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>
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: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/141>
Otherwise the transports are not set up yet during the PLAY request
handling when unsuspending (and thus unblocking) the media.
In case of live pipelines this then causes the first few packets to go
to the sinks before they know what to do with them, and they simply
discard them which is rather suboptimal in case of keyframes.
For non-live pipelines this is not a problem because the sink will still
be PAUSED and as such not send out the data yet but wait until it goes
to PLAYING, which is late enough.
Adding the transports multiple times is not a problem: if the transport
is already added it won't be added another time and TRUE will be
returned.
This fixes a regression introduced by a7732a68e8
before 1.14.0.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/107
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/135>
Make sure rtsp-media have received a GstRTSPStreamBlocking message from
each active stream when checking if all streams are blocked.
Without this change there will be a race condition when using two or
more streams and rtsp-media receives a GstRTSPStreamBlocking message
from one of the streams. This is because rtsp-media then checks if all
streams are blocked by calling gst_rtsp_stream_is_blocking() for each
stream. This function call returns TRUE if the stream has sent a
GstRTSPStreamBlocking message, however, rtsp-media may have yet to
receive this message. This would then result in that rtsp-media
erroneously thinks it is blocking all streams which could result in
rtsp-media changing state, from PREPARING to PREPARED. In the case of a
preroll, this could result in that rtsp-media thinks that the pipeline
is prerolled even though that might not be the case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/124>
Set expected_async_done to FALSE in default_suspend() if a state change
occurs and the return value from set_target_state() is something other
than GST_STATE_CHANGE_ASYNC.
Without this change there is a risk that expected_async_done will be
TRUE even though no asynchronous state change is taking place. This
could happen if the pipeline is set to PAUSED using
media_set_pipeline_state_locked(), an asynchronous state change starts
and then the media is suspended (which could result in a state change,
aborting the asynchronous state change). If the media is suspended
before the asynchronous state change ends then expected_async_done will
be TRUE but no asynchronous state change is taking place.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/123>
There was a race condition where client was being finalized and
concurrently in some other thread the rtsp ctrl timout was relying on
client data that was being freed.
When rtsp ctrl timeout is setup, a WeakRef on Client is set.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/121>
We always need to take the lock while accessing it as otherwise another
thread might've removed it in the meantime. Also when destroying and
creating a new one, ensure that the mutex is not shortly unlocked in
between as during that time another one might potentially be created
already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/119>
