Commit graph

372 commits

Author SHA1 Message Date
Branko Subasic
2894640cc5 rtsp-client: cleanup transports during TEARDOWN
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>
2021-01-22 16:42:00 +01:00
John Lindgren
c4762da9b7 Make a mount point of "/" work correctly.
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>
2020-12-23 19:45:13 +00:00
Lawrence Troup
6bf45b5965 rtsp-client: Only unref client watch context on finalize, to avoid deadlock
Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/127

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/176>
2020-12-15 12:06:32 +13:00
Kristofer Björkström
ba7d568bb3 rtsp-client: Fix race condition in rtsp ctrl timeout by WeakRef client
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>
2020-05-27 15:31:34 +02:00
Sebastian Dröge
5d8abd9bfd rtsp-client: Fix some race conditions around timeout source removal
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>
2020-05-14 11:07:46 +03:00
Sebastian Dröge
e7802c1be7 rtsp-client: Store the timeout source by pointer instead of id
That way we don't have to retrieve it again from the main context when
destroying it but can directly do so.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/115>
2020-04-28 23:33:49 +03:00
Sebastian Dröge
4188dbb99b rtsp-client: Clean up watch/watch context and related state consistently
And assert that it was cleaned up properly before the client is
finalized. If something is still around when the client is shut down
then something went very wrong before.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/115>
2020-04-28 23:16:18 +03:00
Sebastian Dröge
680ddb9fd3 rtsp-client: Combine the pre-session and post-session timeout
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>
2020-04-28 11:12:30 +03:00
Sebastian Dröge
d33057a031 rtsp-client: Don't ever close the client connection directly when a session is torn down
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>
2020-04-28 11:12:30 +03:00
Sebastian Dröge
f2b82c28a3 rtsp-client: If the TEARDOWN response can be sent directly, directly close the client
Instead of closing it never at all. Previously there was only code that
closed the client asynchronously if sending the response happened
asynchrously at a later time.

Thanks to Christian M for debugging this issue.

Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/102

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/114>
2020-04-27 13:53:22 +03:00
Göran Jönsson
daa18dc867 rtsp-client: Use watch_context before unref
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).
2020-03-09 14:17:34 +01:00
Mathieu Duponchelle
90f7e851f4 rtsp-client: make closing more thread safe
+ 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
2020-01-23 18:08:21 +00:00
Zoltán Imets
aa8126b239 rtsp-client: add property post-session-timeout
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
2020-01-15 11:47:27 +00:00
Edward Hervey
8de843733d rtsp-client: Revitalize dead code
Leftover from 65d9aa327c

CID: 1455379
2019-12-02 10:46:40 +01:00
Niels De Graef
45e77ecdd7 Don't pass default GLib marshallers for signals
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.

Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
2019-11-04 14:16:10 +00:00
Mathieu Duponchelle
dd32924eb0 stream: refactor TCP backpressure handling
The previous implementation stopped sending TCP messages to
all clients when a single one stopped consuming them, which
obviously created problems for shared media.

Instead, we now manage a backlog in stream-transport, and slow
clients are removed once this backlog exceeds a maximum duration,
currently hardcoded.

Fixes #80
2019-10-21 13:49:54 +02:00
Muhammet Ilendemli
d9a182c476 rtsp-client: Generate correct URI for MIKEY in ANNOUNCE responses
Instead of hardcoding the URI, take the actual URI (and especially the correct port)
from the RTSP context.

Fixes #84
2019-10-17 14:05:12 +03:00
Kristofer
1a01d20e40 rtsp-client: Lock shared media
For shared media we got race conditions. Concurrently rtsp clients might
suspend or unsuspend the shared media and thus change the state without
the clients expecting that.
By introducing a lock that can be taken by callers such as rtsp_client
one can force rtsp clients calling, eg. PLAY, SETUP and that uses shared media,
to handle the media sequentially thus allowing one client to finish its
rtsp call before another client calls on the same media.

https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/86
Fixes #86
2019-10-16 13:20:54 +00:00
Kristofer Bjorkstrom
7e1edcf1a4 rtsp-client: RTP Info when completed_sender
Change condition that should be fulfilled regarding RTPInfo.
Replace !gst_rtsp_media_is_receive_only with
gst_rtsp_media_has_completed_sender. It is more correct to actually look
for a sender pipeline that is complete. Only then a RTPInfo should
exist.

gst_rtsp_media_is_receive_only gives different answears depending on
state of server.
If Describe is called wth URL+options for backchannel SDP will give only
audio and only backchannel a=sendonly
If Describe is called on URL+options that gives both audio and video
direction from server to client, pipelines are created. Thus
receive_only will return false, even though Setup only would setup
backchannel.

RTP-Info is only for outgoing streams. Thus one should look if outgoing
streams are complete.
2019-10-01 12:01:26 +02:00
Kristofer
d7ae39657d rtsp-client: RTP Info exists conditionally in PLAY
If RTP Info is missing and it is not a receiver only, eg. audio
backchannel. Then return GST_RTSP_STS_INTERNAL_SERVER_ERROR.
In rfc2326 it says RTP-info is req. but in RFC7826 it is conditional.

Since 1.14 there is audio backchannel support. Thus RTP-info is
conditional now. When audio backchannel only mode, there is no RTP-info.

Fixes #82
2019-09-25 09:14:08 +00:00
Kristofer Björkström
f834700eff rtsp-client: RTP Info must exist in PLAY response
If RTP Info is missing. Then return GST_RTSP_STS_INTERNAL_SERVER_ERROR

Fixes #76
2019-09-04 07:34:37 +00:00
Göran Jönsson
16bc937ed9 Use complete streams for scale and speed.
Without this patch it's always stream0 that is used to get segment event
that is used to set scale and speed. This even if client not doing SETUP
for stream0. At least in suspend mode reset this not working since then
it's just random if send_rtp_sink have got any segment event. There are
no check if send_rtp_sink for stream0 got any data before media is
prerolled after PLAY request.
2019-08-29 07:15:37 +02:00
Mathieu Duponchelle
72504eee99 rtsp-client: define all seek accuracy flags from setup_play_mode
We then pass those to adjust_play_mode, which needs to operate
on the "final" seek flags, as previously the code in rtsp-media
was assuming that accuracy seek flags (accurate / key_unit) should
not be set if the flags passed to the seek method were already set.
2019-08-07 18:04:03 +02:00
Mathieu Duponchelle
0f498eabf4 onvif: Implement and test the Streaming Specification
https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf
2019-06-06 18:45:17 +02:00
Mathieu Duponchelle
7640cb8f21 rtsp-client: add gst_rtsp_client_get_stream_transport()
This will be used in the onvif tests in order to validate the
data transmitted over TCP: for streaming to continue after a
data message has been provided to client->send_func, the client
is responsible for marking the message as sent on the relevant
stream transport.
2019-06-06 18:45:17 +02:00
Mathieu Duponchelle
52d20df0f4 client: Scale implies TRICK_MODE 2019-06-04 14:32:51 +02:00
Mathieu Duponchelle
b9cc3e867a client: compare booleans, not pointers to them 2019-06-04 14:32:51 +02:00
Branko Subasic
bc74589601 rtsp-client: add support for Scale and Speed header
Add support for the RTSP Scale and Speed headers by setting the rate in
the seek to (scale*speed). We then check the resulting segment for rate
and applied rate, and use them as values for the Speed and Scale headers
respectively.

https://bugzilla.gnome.org/show_bug.cgi?id=754575
2019-06-04 14:32:51 +02:00
Branko Subasic
65d9aa327c rtsp-client: allow sub classes to adjust the seek
Adds a new virtual function, adjust_play_mode(), that allows
sub classes to adjust the seek done on the media. The sub class can
modify the values of the the seek flags and the rate.

https://bugzilla.gnome.org/show_bug.cgi?id=754575
2019-06-04 14:32:51 +02:00
Kristofer Bjorkstrom
b578628dc1 rtsp-client: Handle Content-Length limitation
Add functionality to limit the Content-Length.
API addition, Enhancement.

Define an appropriate request size limit and reject requests
exceeding the limit with response status 413 Request Entity Too Large

Related to !182
2019-04-22 09:17:13 +00:00
Göran Jönsson
afb27f91cf rtsp-server: remove recursive behavior
Introduce a threadpool to send rtp and rtcp to avoid recursive behavior.
2019-02-02 10:42:33 +00:00
Sebastian Dröge
4be7424de5 rtsp-client: Only allow to set either a send_func or send_messages_func but not both
And route all messages through the send_func if no send_messages_func
was provided.

We otherwise break backwards compatibility.
2019-01-30 14:40:09 +02:00
Sebastian Dröge
c372643e1e rtsp-client: Add support for sending buffer lists directly
Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/29
2019-01-30 14:40:09 +02:00
Sebastian Dröge
d708f9736b rtsp-server: Add support for buffer lists
This adds new functions for passing buffer lists through the different
layers without breaking API/ABI, and enables the appsink to actually
provide buffer lists.

This should already reduce CPU usage and potentially context switches a
bit by passing a whole buffer list from the appsink instead of
individual buffers. As a next step it would be necessary to
  a) Add support for a vector of data for the GstRTSPMessage body
  b) Add support for sending multiple messages at once to the
    GstRTSPWatch and let it be handled internally
  c) Adding API to GOutputStream that works like writev()

Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/29
2019-01-30 14:39:50 +02:00
Benjamin Berg
621e140a8e client: Fix crash in close handler
The close handler could trigger a crash because it invalidated the
watch_context while still leaving a source attached to it which would be
cleaned up at a later point.
2019-01-29 18:34:08 +00:00
Göran Jönsson
7cfd59820a rtsp-stream: use idle source in on_message_sent
When the underlying layers are running on_message_sent, this sometimes
causes the underlying layer to send more data, which will cause the
underlying layer to run callback on_message_sent again. This can go on
and on.

To break this chain, we introduce an idle source that takes care of
sending data if there are more to send when running callback

https://bugzilla.gnome.org/show_bug.cgi?id=797289
2018-10-23 08:18:52 +01:00
Edward Hervey
ebafccb65a rtsp-client: Remove timeout GSource on cleanup
Avoids ending up with races where a timeout would still be around
*after* a client was gone. This could happen rather easily in
RTSP-over-HTTP mode on a local connection, where each RTSP message
would be sent as a different HTTP connection with the same tunnelid.

If not properly removed, that timeout would then try to free again
a client (and its contents).
2018-10-22 09:35:54 +02:00
Tim-Philipp Müller
62d4c0b179 libs: fix API export/import and 'inconsistent linkage' on MSVC
Export rtsp-server library API in headers when we're building the
library itself, otherwise import the API from the headers.

This fixes linker warnings on Windows when building with MSVC.

Fix up some missing config.h includes when building the lib which
is needed to get the export api define from config.h

https://bugzilla.gnome.org/show_bug.cgi?id=797185
2018-09-24 09:36:21 +01:00
David Svensson Fors
a2e182c3b4 rtsp-client: Avoid reuse of channel numbers for interleaved
If a (strange) client would reuse interleaved channel numbers in
multiple SETUP requests, we should not accept them. The channel
numbers are used for looking up stream transports in the
priv->transports hash table, and transports disappear from the table
if channel numbers are reused.

RFC 7826 (RTSP 2.0), Section 18.54, clarifies that it is OK for the
server to change the channel numbers suggested by the client.

https://bugzilla.gnome.org/show_bug.cgi?id=796988
2018-08-29 14:46:01 +03:00
Sebastian Dröge
bd76c2f9c5 Fix indentation again 2018-08-14 14:31:55 +03:00
Patricia Muscalu
cbe6ae3c48 stream: Added a list of multicast client addresses
When media is shared, the same media stream can be sent
to multiple multicast groups. Currently, there is no API
to retrieve multicast addresses from the stream.
When calling gst_rtsp_stream_get_multicast_address() function,
only the first multicast address is returned.
With this patch, each multicast destination requested in SETUP
will be stored in an internal list (call to
gst_rtsp_stream_add_multicast_client_address()).
The list of multicast groups requested by the clients can be
retrieved by calling gst_rtsp_stream_get_multicast_client_addresses().
There still exist some problems with the current implementation
in the multicast case:
1) The receiving part is currently only configured with
regard to the first multicast client (see
https://bugzilla.gnome.org/show_bug.cgi?id=796917).
2) Secondly, of security reasons, some constraints should be
put on the requested multicast destinations (see
https://bugzilla.gnome.org/show_bug.cgi?id=796916).

Change-Id: I6b060746e472a0734cc2fd828ffe4ea2956733ea

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:31:42 +03:00
Patricia Muscalu
4c6cecf5d6 stream: Choose the maximum ttl value provided by multicast clients
The maximum ttl value provided so far by the multicast clients
will be chosen and reported in the response to the current
client request.

Change-Id: I5408646e3b5a0a224d907ae215bdea60c4f1905f

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:31:42 +03:00
Patricia Muscalu
308480e762 client: Don't reserve multicast address in the client setting case
When two multicast clients request specific transport
configurations, and "transport.client-settings" parameter is
set to true, it's wrong to actually require that these two
clients request the same multicast group.
Removed test_client_multicast_invalid_transport_specific test
cases as they wrongly require that the requested destination
address is supposed to be present in the address pool, also in
the case when "transport.client-settings" parameter is set to true.

Change-Id: I4580182ef35996caf644686d6139f72ec599c9fa

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:31:41 +03:00
Sebastian Dröge
443c2b73e5 Revert "Add new API for setting/getting maximum multicast ttl value"
This reverts commit 7f0ae77e40.

Commits where accidentially squashed together
2018-08-14 14:25:42 +03:00
Sebastian Dröge
29ae15f6f1 Revert "stream: Choose the maximum ttl value provided by multicast clients"
This reverts commit 499e437e50.

Commits where accidentially squashed together
2018-08-14 14:25:14 +03:00
Patricia Muscalu
499e437e50 stream: Choose the maximum ttl value provided by multicast clients
The maximum ttl value provided so far by the multicast clients
will be chosen and reported in the response to the current
client request.

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:10:41 +03:00
Patricia Muscalu
7f0ae77e40 Add new API for setting/getting maximum multicast ttl value
https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:10:20 +03:00
Mathieu Duponchelle
12f8abb549 rtsp-client: always allocate both IPV4 and IPV6 sockets
multiudpsink does not support setting the socket* properties
after it has started, which meant that rtsp-server could no
longer serve on both IPV4 and IPV6 sockets since the patches
from https://bugzilla.gnome.org/show_bug.cgi?id=757488 were
merged.

When first connecting an IPV6 client then an IPV4 client,
multiudpsink fell back to using the IPV6 socket.

When first connecting an IPV4 client, then an IPV6 client,
multiudpsink errored out, released the IPV4 socket, then
crashed when trying to send a message on NULL nevertheless,
that is however a separate issue.

This could probably be fixed by handling the setting of
sockets in multiudpsink after it has started, that will
however be a much more significant effort.

For now, this commit simply partially reverts the behaviour
of rtsp-stream: it will continue to only create the udpsinks
when needed, as was the case since the patches were merged,
it will however when creating them, always allocate both
sockets and set them on the sink before it starts, as was
the case prior to the patches.

Transport configuration will only error out if the allocation
of UDP sockets fails for the actual client's family, this
also downgrades the GST_ERRORs in alloc_ports_one_family
to GST_WARNINGs, as failing to allocate is no longer
necessarily fatal.

https://bugzilla.gnome.org/show_bug.cgi?id=796875
2018-08-01 20:42:34 +02:00
David Svensson Fors
12169f1e84 Limit queued TCP data messages to one per stream
Before, the watch backlog size in GstRTSPClient was changed
dynamically between unlimited and a fixed size, trying to avoid both
unlimited memory usage and deadlocks while waiting for place in the
queue. (Some of the deadlocks were described in a long comment in
handle_request().)

In the previous commit, we changed to a fixed backlog size of 100.
This is possible, because we now handle RTP/RTCP data messages differently
from RTSP request/response messages.

The data messages are messages tunneled over TCP. We allow at most one
queued data message per stream in GstRTSPClient at a time, and
successfully sent data messages are acked by sending a "message-sent"
callback from the GstStreamTransport. Until that ack comes, the
GstRTSPStream does not call pull_sample() on its appsink, and
therefore the streaming thread in the pipeline will not be blocked
inside GstRTSPClient, waiting for a place in the queue.

pull_sample() is called when we have both an ack and a "new-sample"
signal from the appsink. Then, we know there is a buffer to write.

RTSP request/response messages are not acked in the same way as data
messages. The rest of the 100 places in the queue are used for
them. If the queue becomes full of request/response messages, we
return an error and close the connection to the client.

Change-Id: I275310bc90a219ceb2473c098261acc78be84c97
2018-07-23 17:45:00 +03:00
David Svensson Fors
287345f6ac rtsp-client: Use fixed backlog size
Change to using a fixed backlog size WATCH_BACKLOG_SIZE.

Preparation for the next commit, which changes to a different way of
avoiding both deadlocks and unlimited memory usage with the watch
backlog.
2018-07-23 17:44:15 +03:00