Underscorify the test name before setting GST_REGISTRY,
so the registry actually ends up in the current build dir
and not some subdir.
For consistency with the other modules, but should also
avoid problems on windows.
Also fix indentation of environment block.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/126>
If core is built as a subproject (e.g. as in gst-build), make sure to use
the gst-plugin-scanner from the built subproject. Without this, gstreamer
might accidentally use the gst-plugin-scanner from the install prefix if
that exists, which in turn might drag in gst library versions we didn't
mean to drag in. Those gst library versions might then be older than
what our current build needs, and might cause our newly-built plugins
to get blacklisted in the test registry because they rely on a symbol
that the wrongly-pulled in gst lib doesn't have.
This should fix running of unit tests in gst-build when invoking
meson test or ninja test from outside the devenv for the case where
there is an older or different-version gst-plugin-scanner installed
in the install prefix.
In case no gst-plugin-scanner is installed in the install prefix, this
will fix "GStreamer-WARNING: External plugin loader failed. This most
likely means that the plugin loader helper binary was not found or
could not be run. You might need to set the GST_PLUGIN_SCANNER
environment variable if your setup is unusual." warnings when running
the unit tests.
In the case where we find GStreamer core via pkg-config we use
a newly-added pkg-config var "pluginscannerdir" to get the right
directory. This has the benefit of working transparently for both
installed and uninstalled pkg-config files/setups.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/126>
Make hard requirement until we have more fine-grained control
in the unit tests. Of course the presence of the .pc file doesn't
imply that the plugins we need are actually there, but it's at
least a step in the right direction.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/126>
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>
They previously used the same state but different mechanisms and
functions, which was difficult to follow, error prone and simply
confusing.
Also adjust the test for the post-session timeout a bit to be less racy
now that the timing has slightly changed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/115>
There might be other sessions that are running over the same RTSP
connection and we should not simply close the client directly if one of
them is torn down.
By default the connection will be closed once the client closes it or
the OS does. This behaviour can be adjusted with the
post-session-timeout property, which allows to close it automatically
from the server side after all sessions are gone and the given timeout
is reached.
This reverts the previous commit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/115>
When using the basic authentication scheme, we wouldn't validate that
the authorization field of the credentials is not NULL and pass it on
to g_hash_table_lookup(). g_str_hash() however is not NULL-safe and will
dereference the NULL pointer and crash.
A specially crafted (read: invalid) RTSP header can cause this to
happen.
As a solution, check for the authorization to be not NULL before
continuing processing it and if it is simply fail authentication.
This fixes CVE-2020-6095 and TALOS-2020-1018.
Discovered by Peter Wang of Cisco ASIG.
Move the usage of priv->watch_context to beginning of function
gst_rtsp_client_finalize. Instead of use it after
g_main_context_unref (priv->watch_context).
We cannot take the RTSPStream lock while holding a transport backlog
lock, as remove_transport may be called externally, which will
take first the RTSPStream lock then the transport backlog lock.
This ensures we don't end up calling any of transports' callbacks
with a potentially unreffed user_data (in practice, a client that
may have been removed)
In order to address the race condition pointed out at
https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/merge_requests/108#note_403579
we get rid of the send thread pool, and instead spawn and manage
a single thread to pull samples from app sinks and add them to
the transport's backlogs.
Additionally, we now also always go through the backlogs in order
to simplify the logic.
Fixes#97
We cannot hold stream->lock while pushing data, but need
to consistently check the state of the backlog both from
the send_tcp_message function and the on_message_sent function,
which may or may not be called from the same thread.
This commit introduces internal API to allow for potentially
recursive locking of transport streams, addressing a race
condition where the RTSP stream could push items out of order
when popping them from the backlog.
It's taken ownership of by the media, and returned with `transfer none`
from the GstRTSPMedia::create_pipeline() vfunc. If we don't sink it
first then any bindings will wrongly take ownership of the pipeline once
it arrives in bindings code.
+ Take the watch lock prior to using priv->watch
+ Flush both the watch and connection before closing / unreffing
gst_rtsp_connection_close() is not threadsafe on its own, this is
a workaround at the client level, where we control both the watch
and the connection
This is a TCP connection timeout for client connections, in seconds.
If a positive value is set for this property, the client connection
will be kept alive for this amount of seconds after the last session
timeout. For negative values of this property the connection timeout
handling is delegated to the system (just as it was before).
Fixes#83
The internal index of our appsinks, while it can be used to
determine whether a message is RTP or RTCP, is not necessarily
the same as the interleaved channel. Let the stream-transport
determine the channel to check backpressure for, the same way
it determines the channel according to whether it is sending
RTP or RTCP.
The commit "rtsp-client: define all seek accuracy flags from
setup_play_mode" changed the behaviour of when doing a seek.
Before that commit, having the flush flag set would result in a seek
(forced seek).
Even if no seek was needed. One reason to force seek is to flush old buffers
created in Describe requests.
Thus adding force seek also for flush flag will result in play request
with fresh buffers.
Only attempt to use the various timing values iif gst_rtsp_stream_get_info()
returns TRUE. Also avoid the whole clock signalling block if we're not
dealing with senders.
CID: 1439524
CID: 1439536
CID: 1439520
When removing transports an assertion was that the transports passed in
for removal are present in the list, however that can't be assumed.
As an example if a transport was removed from a thread running
send_tcp_message, the main thread can try to remove the same transport
again if it gets a handle_pause_request. This will not effect the
transport list but it will effect n_tcp_transports as it will be
decrement and then have the wrong value.
