Commit graph

337 commits

Author SHA1 Message Date
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
Louis-Francis Ratté-Boulianne
604240f7eb client: Strip transport parts as whitespaces could be around commas
https://bugzilla.gnome.org/show_bug.cgi?id=758428
2018-07-06 16:13:33 -04:00
Tim-Philipp Müller
2eb4d1b810 Update for g_type_class_add_private() deprecation in recent GLib 2018-06-24 12:48:11 +02:00
Patricia Muscalu
768fb5695c Get payloader stats only for the sending streams
Get/set payloader properties only for streams that actually
contain a payloader element.

https://bugzilla.gnome.org/show_bug.cgi?id=796523
2018-06-13 10:13:12 +03:00
Joakim Johansson
808b49cbfc rtsp-client: Fix session timeout
When streaming data over TCP then is not the keep-alive
functionality working.

The reason is that the function do_send_data have changed
to boolean but the code is still checking the received result
from send_func with GST_RTSP_OK.

The result is that a successful send_func will always lead to
that do_send_data is returning false and the keep-alive will
not be updated.

https://bugzilla.gnome.org/show_bug.cgi?id=795321
2018-04-20 10:13:53 +03:00
Sebastian Dröge
ef878da703 gst: Run everything through gst-indent again 2018-04-04 10:06:06 +03:00
Mathieu Duponchelle
c36d6b477c rtsp-client: do not free string passed to take_header 2018-03-30 23:34:01 +02:00
Mathieu Duponchelle
ae0e08dac2 rtsp-client: Send KeyMgmt header in ANNOUNCE response
When sending back an encrypted RTCP back channel, it is useful
for the client to know the encryption key.

https://bugzilla.gnome.org/show_bug.cgi?id=794813
2018-03-30 17:55:32 +02:00
Mathieu Duponchelle
a093f4442b rtsp-stream: extract handle_keymgmt from rtsp-client
rtspclientsink will also need to parse KeyMgmt headers
sent by the server to decrypt the RTCP backchannel stream

https://bugzilla.gnome.org/show_bug.cgi?id=794813
2018-03-30 17:55:32 +02:00
Göran Jönsson
3a129300f0 rtsp-client:Error handling when equal http session cookie
There are some clients that are sending same session cookie on random
basis.

https://bugzilla.gnome.org/show_bug.cgi?id=753616
2018-03-21 17:39:02 -04:00
Sebastian Dröge
0dc6170582 rtsp-client: Place netaddress meta on packets received via TCP
This allows us to later map signals from rtpbin/rtpsource back to the
corresponding stream transport, and allows to do keep-alive based on
RTCP packets in case of TCP media transport.

https://bugzilla.gnome.org/show_bug.cgi?id=789646
2018-02-28 21:12:43 +02:00
Mathieu Duponchelle
c725ef01a4 All around: add annotations and API guards 2018-02-12 19:16:11 +01:00
Mathieu Duponchelle
03a512e4e1 rtsp-client: add type annotations
gi doesn't seem to be able to figure out the type of the
signal parameters when defined with G_DEFINE_POINTER_TYPE
2018-02-06 18:06:14 +01:00
Edward Hervey
7bf8c4d218 rtsp-client: Don't leak addr
CID #1422260
2017-11-21 09:53:19 +01:00
Edward Hervey
4d98bc5e55 Run gst-indent 2017-11-21 09:53:08 +01:00
Patricia Muscalu
a7732a68e8 Dynamically reconfigure pipeline in PLAY based on transports
The initial pipeline does not contain specific transport
elements. The receiver and the sender parts are added
after PLAY.
If the media is shared, the streams are dynamically
reconfigured after each PLAY.

https://bugzilla.gnome.org/show_bug.cgi?id=788340
2017-11-15 19:56:15 +02:00
Branko Subasic
619ac7b710 rtsp-client: unref 'pipelined_requests' in finalize
The hash table priv->pipelined_requests is not unref:ed in the
finalize funktion. Make sure it is.

https://bugzilla.gnome.org/show_bug.cgi?id=788704
2017-10-09 20:39:14 +02:00
Thibault Saunier
9706199efb Start support for RTSP 2.0
This adds basic support for new 2.0 features, though the protocol is
subposdely backward incompatible, most semantics are the sames.

This commit adds:

- features:
 * version negotiation
 * pipelined requests support
 * Media-Properties support
 * Accept-Ranges support

- APIs:
  * gst_rtsp_media_seekable

The RTSP methods that have been removed when using 2.0 now return
BAD_REQUEST.

https://bugzilla.gnome.org/show_bug.cgi?id=781446
2017-10-05 13:23:48 -03:00
Sebastian Dröge
ffbabb1529 rtsp-client: Fix typo in debug message 2017-08-14 21:04:58 +03:00
Sebastian Dröge
cd4e675f0c rtsp-client: Also handle the (S|G)ET_PARAMETER case of size==0 || !data as keep-alive
If there is no Content-Length header, no body would be allocated and the
'\0' would also not be appended to the body.
2017-01-19 14:57:19 +02:00
Sebastian Dröge
ac1124efb4 rtsp-client: Fix handling of keep-alive GET_PARAMETER/SET_PARAMETER
While they logically have 0 bytes length, GstRTSPConnection is appending
a '\0' to everything making the size be 1 instead.
2017-01-19 14:24:07 +02:00
Dag Gullberg
f00ac2daf2 rtsp-client: add IDLE timeout, before session exists
The RTSP server will not timeout an idle RTSP connection
(note this is different from doing timeout on a RTSP
session).

At least for Apache this is a problem when running RTSP over
HTTPS since it uses one of the threads (there is a rather
limited number) that are available for handling requests.

https://bugzilla.gnome.org/show_bug.cgi?id=771830
2016-11-23 09:45:33 +00:00
Scott D Phillips
01ef7f32b6 client: update do_send_message to match type GstRTSPClientSendFunc
This type mismatch fails building with MSVC

https://bugzilla.gnome.org/show_bug.cgi?id=774640
2016-11-17 23:38:15 +00:00
Branko Subasic
8425ea6969 client: emit signal in the beginning of each rtsp request
These signals let the application validate the requests, configure the
media/stream in a certain way and also generate error status code in
case of error or bad request.

https://bugzilla.gnome.org/show_bug.cgi?id=758062
2016-11-01 20:25:22 +02:00
Göran Jönsson
dbf91ab231 rtsp-client: Session filter in unwatch session
Call session filter with filter_session_media as paramer in
client_unwatch_session if using drop_backlog = FALSE.

In client_unwatch_session its allowed to grow the watchs backlog.
If using drop_backlog = FALSE and the backlog is full it will cause
a deadlock when setting session media state to NULL
if the backlog is not allowed to grow.

https://bugzilla.gnome.org/show_bug.cgi?id=771983
2016-10-25 12:55:59 +03:00
Nikita Bobkov
ff65732270 rtsp-client: Fix factory leaking in find_media() in error cases
https://bugzilla.gnome.org/show_bug.cgi?id=771488
2016-10-20 14:01:38 +03:00
Xavier Claessens
8495c47a9d stream: revert back to create udpsrc/udpsink on DESCRIBE for unicast
This is basically reverting changes introduced in commit f62a9a7,
because it was introducing various regressions:

- It introduces a leak of udpsrc elements that got wrongly fixed by adding
  an hash table in commit cba045e. We should have at most 4 udpsrc for unicast:
  ipv4/ipv6, rtp/rtcp. They can be reused for all unicast clients.
- If a mcast client connects, it creates a new socket in SETUP to try to respect
  the destination/port given by the client in the transport, and overrides the
  socket already set on the udpsink element. That means that if we already had a
  client connected, the source address on the udp packets it receives suddenly
  changes.
- If a 2nd mcast client connects, the destination/port in its transport is
  ignored but its transport wasn't updated.

What this patch does:

- Revert back to create udpsrc/udpsink for unicast clients on DESCRIBE.
- Always have a tee+queue when udp is enabled. This could be optimized
  again in a later patch, but is more complicated. If no unicast clients
  connects then those elements are useless, this could be also optimized
  in a later patch.
- When mcast transport is added, it creates a new set of udpsrc/udpsink,
  seperated from those for unicast clients. Since we already support only
  one mcast address, we also create only one set of elements.

https://bugzilla.gnome.org/show_bug.cgi?id=766612
2016-09-05 13:36:17 +03:00
Nikita Bobkov
de3d0c4522 rtsp-client: Fix leaking of media in error cases
With additional fixes by Kseniya Vasilchuk <vasilchukkseniia@gmail.com>
and myself to make the media refcounting a bit easier to follow.

https://bugzilla.gnome.org/show_bug.cgi?id=755632
2016-08-02 17:46:49 +03:00
Sebastian Dröge
687301af86 rtsp-client: Fix leaking of session in error cases
https://bugzilla.gnome.org/show_bug.cgi?id=755632
2016-08-02 15:18:30 +03:00
Sebastian Dröge
9fab555cc5 rtsp-server: Implement clock signalling according to RFC7273
For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.

For all other clocks we at least signal that it's the local sender clock.

This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.

https://bugzilla.gnome.org/show_bug.cgi?id=760005
2016-04-03 11:22:31 +03:00
Sebastian Dröge
406ed190ac rtsp-server: Fix indentation 2016-03-02 11:48:49 +02:00
Patricia Muscalu
f62a9a7eb9 rtsp-stream: postpone UDP socket allocation until SETUP
Postpone the allocation of the UDP sockets until we know
what transport has been chosen by the client.
Both unicast and multicast UDP sources are created in one
function.

https://bugzilla.gnome.org/show_bug.cgi?id=757488
2016-02-23 17:05:15 +02:00
Sebastian Dröge
c8f179948e rtsp-media: Add property to decide if sending media should be stopped when a client disconnects without TEARDOWN
Without TEARDOWN it might be desireable to keep the media running and continue
sending data to the client, even if the RTSP connection itself is
disconnected.

Only do this for session medias that have only UDP transports. If there's at
least on TCP transport, it will stop working and cause problems when the
connection is disconnected.

https://bugzilla.gnome.org/show_bug.cgi?id=758999
2015-12-28 10:51:56 +02:00
Srimanta Panda
ed70572c6c rtsp-client: suspend media during setup request
SETUP request from clients needs to suspend the media to clear the
prerolled buffers. Otherwise it will not affect the prerolled buffer
and the prerolled buffers will be incorrect (for example block-size
from setup request will not affect the prerolled buffer unless the
media is suspended).

https://bugzilla.gnome.org/show_bug.cgi?id=758268
2015-12-04 15:48:23 +02:00
Jan Schmidt
9e92a0307c rtsp-client: Report RECORD and ANNOUNCE as supported in the OPTIONS 2015-11-17 01:12:28 +11:00
Ognyan Tonchev
8922afb88d rtsp-client: allow application to decide what requirements are supported
Add "check-requirements" signal and vfunc to allow application
(and subclasses) to check the requirements.

Based on patch from Hyunjun Ko <zzoon.ko@samsung.com>

https://bugzilla.gnome.org/show_bug.cgi?id=749417
2015-06-23 14:38:29 +01:00