Commit graph

236 commits

Author SHA1 Message Date
Mathieu Duponchelle
6d319f8e49 rtsp-stream: make use of blocked_running_time in query_position
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>
2020-10-08 22:28:04 +02:00
Mathieu Duponchelle
a446ba4fb0 rtsp-stream: collect rtp info when blocking
We don't unblock the stream anymore before replying to the
play request (883ddc72bb),
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>
2020-10-08 22:28:04 +02:00
Mathieu Duponchelle
3b9eaa092e rtsp-media: set a 0 storage size for TCP receivers
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>
2020-09-09 20:18:44 +00:00
Mathieu Duponchelle
5699ada939 rtsp-stream: preroll on gap events
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>
2020-09-09 17:46:40 +00:00
Mathieu Duponchelle
34590b342e rtsp-stream: explicitly set caps on udpsrc elements
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>
2020-07-06 10:20:32 +00:00
Sebastian Dröge
8052957c24 rtsp-media: Mark out parameters accordingly in gst_rtsp_media_get_rates()
And the same for gst_rtsp_stream_get_rates().

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/118>
2020-05-03 13:31:37 +00:00
Sebastian Dröge
65bfa84d7a rtsp-stream-transport: Fix accidental API/ABI breakage with message_sent callbacks
The old API is preserved now and new API was added that provides the
additional parameter to the callback.

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

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/116>
2020-05-01 10:45:45 +03:00
Michael Olbrich
a696d980b5 rtsp-stream: use mcast_udpsink[0] last-sample if available for rtpinfo
Otherwise no sink is found for multicast sreams and the less accurate
fallback is used to determine the current sequence number and timestamp.
2020-03-30 16:57:05 +02:00
Mathieu Duponchelle
8410c69da9 rtsp-stream: fix deadlock on transport removal
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.
2020-02-24 20:24:29 +00:00
Mathieu Duponchelle
fa41cbe9a4 rtsp-stream: clear backlog when removing transport
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)
2020-02-24 20:24:29 +00:00
Mathieu Duponchelle
54b6b3bcab rtsp-stream: marshal calls to send_tcp_message to a single thread
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.
2020-02-24 20:24:29 +00:00
Mathieu Duponchelle
50ecbb1596 rtsp-stream: properly protect TCP backlog access
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.
2020-02-24 20:24:29 +00:00
Mark Nauwelaerts
0ed32e0d53 rtsp-stream: check for NULL transports prior to ref'ing 2020-01-11 22:58:48 +01:00
Mathieu Duponchelle
e0a4355d6b rtsp-stream: fix checking of TCP backpressure
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.
2020-01-09 14:10:44 +01:00
Adam x Nilsson
9c5ca231a6 rtsp-stream: Removing invalid transports returns false
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.
2019-11-25 19:12:10 +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
Adam x Nilsson
0b1b6670c8 rtsp-stream : fix race condition in send_tcp_message
If one thread is inside the send_tcp_message function and are done
sending rtp or rtcp messages so the n_outstanding variable is zero
however have not exit the loop sending the messages. While sending its
messages, transports have been added or removed to the transport list,
so the cache should be updated. If now an additional thread comes to
the function send_tcp_message and trying to send rtp messages it will
first destroy the rtp cache that is still being iterated trough by the
first thread.

Fixes #81
2019-10-14 19:40:00 +00:00
Göran Jönsson
d1d404912e rtsp-stream: Not wait on receiver streams when pre-rolling
Without this patch there are problem pre-rolling when using audio back
channel.

Without this patch a probe will be created for all streams including
the stream for audio backchannel. To pre-roll all this pads have to
receive data. Since the stream for audio backchannel is a receiver this
will never happen.

The solution is to never create any probes for streams that are for
incomming data and instead set them as blocking already from beginning.
2019-06-28 13:31:34 +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
Nikita Bobkov
f31f79f60e Reverse playback support
GStreamer plays segment from stop to start when doing reverse playback.
RTSP implies that media should be played from start of Range header to
its stop. Hence we swap start and stop times before passing them to
gst_element_seek.

Also make gst_rtsp_stream_query_stop always return value that can be
used as stop time of Range header.
2019-06-04 14:32:51 +02:00
Branko Subasic
421ac85150 rtsp-media: allow specifying rate when seeking
Add new function gst_rtsp_media_seek_full_with_rate() which allows the
caller to specify the rate for the seek. Also added functions in
rtsp-stream and rtsp-media for retreiving current rate and applied rate.

https://bugzilla.gnome.org/show_bug.cgi?id=754575
2019-06-04 14:32:51 +02:00
Sebastian Dröge
8d3bef4c1e rtsp-server: Add various Since: 1.14 markers 2019-04-23 15:01:32 +03:00
Sebastian Dröge
802a648723 rtsp-server: Add various missing Since: 1.16 markers 2019-04-23 14:56:42 +03:00
Göran Jönsson
3cfe88632f rtsp_server: Free thread pool before clean transport cache
If not waiting for free thread pool before clean transport caches, there
can be a crash if a thread is executing in transport list loop in
function send_tcp_message.

Also add a check if priv->send_pool in on_message_sent to avoid that a
new thread is pushed during wait of free thread pool. This is possible
since when waiting for free thread pool mutex have to be unlocked.
2019-04-11 08:02:52 +02:00
Ulf Olsson
d09b7c8e4f rtsp-stream: Add support for GCM (RFC 7714)
Follow-up to !198
2019-04-10 08:43:29 +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
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
Edward Hervey
a48711fa9d rtsp-stream: Use cached address when allocating sockets
If an address/port was previously decided upon (ex: multicast in the
SDP), then use that instead of re-creating another one

Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/57
2019-01-29 14:42:35 +01:00
Patricia Muscalu
3be1b9bba8 Add source elements to the pipeline before activation
In plug_src we changed the element state before adding it to
the owner container. This prevented the pipeline from intercepting
a GST_STREAM_STATUS_TYPE_CREATE message from the pad in order
to assign a custom task pool.

Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/53
2018-12-06 08:59:04 +00:00
Linus Svensson
185385924d rtsp-stream: Use seqnum-offset for rtpinfo
The sequence number in the rtpinfo is supposed to be the first RTP
sequence number. The "seqnum" property on a payloader is supposed to be
the number from the last processed RTP packet. The sequence number for
payloaders that inherit gstrtpbasepayload will not be correct in case of
buffer lists. In order to fix the seqnum property on the payloaders
gst-rtsp-server must get the sequence number for rtpinfo elsewhere and
"seqnum-offset" from the "stats" property contains the value of the
very first RTP packet in a stream. The server will, however, try to look
at the last simple in the sink element and only use properties on the
payloader in case there no sink elements yet, and by looking at the last
sample of the sink gives the server full control of which RTP packet it
looks at. If the payloader does not have the "stats" property, "seqnum"
is still used since "seqnum-offset" is only present in as part of
"stats" and this is still an issue not solved with this patch.

Needed for gst-plugins-base!17
2018-11-14 12:29:58 +00:00
Linus Svensson
1c4d3b36fb rtsp-stream: Plug memory leak
Attaching a GSource to a context will increase the refcount. The idle
source will never be free'd since the initial reference is never
dropped.
2018-11-14 12:29:58 +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
Patricia Muscalu
c394de2348 New property for socket binding to mcast addresses
By default the multicast sockets are bound to INADDR_ANY,
as it's not allowed to bind sockets to multicast addresses
in Windows. This default behaviour can be changed by setting
bind-mcast-address property on the media-factory object.

https://bugzilla.gnome.org/show_bug.cgi?id=797059
2018-09-28 13:27:48 +03: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
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
048e24a7c6 rtsp-stream: Don't require address pool in the transport specific case
If "transport.client-settings" parameter is set to true, the client is
allowed to specify destination, ports and ttl.
There is no need for pre-configured address pool.

Change-Id: I6ae578fb5164d78e8ec1e2ee82dc4eaacd0912d1

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:31:42 +03:00
Patricia Muscalu
a7bb684e9b Add new API for setting/getting maximum multicast ttl value
Change-Id: I5ef4758188c14785e17fb8fbf42a3dc0cb054233

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:31:41 +03:00
Mathieu Duponchelle
c414158022 rtsp-stream: avoid duplicating the first multicast client
In dcb4533fed , we made it so
clients were dynamically added and removed to the multicast
udp sinks, as such we should no longer add a first client in
set_multicast_socket_for_udpsink

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:31:41 +03:00
Sebastian Dröge
d06f3af0be Revert "rtsp-stream: avoid duplicating the first multicast client"
This reverts commit 3357094440.

Commits where accidentially squashed together
2018-08-14 14:25:53 +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
17335e9906 Revert "rtsp-stream: Don't require address pool in the transport specific case"
This reverts commit a9db3e7f09.

Commits where accidentially squashed together
2018-08-14 14:25:37 +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
a9db3e7f09 rtsp-stream: Don't require address pool in the transport specific case
If "transport.client-settings" parameter is set to true, the client is
allowed to specify destination, ports and ttl.
There is no need for pre-configured address pool.

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:10:23 +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
3357094440 rtsp-stream: avoid duplicating the first multicast client
In dcb4533fed , we made it so
clients were dynamically added and removed to the multicast
udp sinks, as such we should no longer add a first client in
set_multicast_socket_for_udpsink

https://bugzilla.gnome.org/show_bug.cgi?id=793441
2018-08-14 14:10:02 +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