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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
When calling gst_rtsp_watch_write_data in gstrtspconnection.c and
backlog is empty it can happen that just a part of a message will be
sent and rest is in backlog queue. If then flush during teardown
just a part of message will be sent.This can lead to client miss
teardown response since it expect to get the last part of message.
The flushing during teardown was introduced to fix a deadlock that now
is fixed more generally in handle_request by temporary setting backlog
size to unlimited.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=749845
If the media was just not seekable, we continue from whatever position we are
and let the client decide if that is what is wanted or not.
Only if the actual seek failed, we can't really recover and should error out.
