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
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
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
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
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
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
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.
Fix race when setting up source elements.
Since we set the source element(s) to PLAYING state before hooking
them up to the downstream funnel, it's possible for the source element
to receive packets before we actually get to linking it to the funnel,
in which case buffers would be pushed out on an unlinked pad, causing
it to error out and stop receiving more data.
We fix this by blocking the source's srcpad until we have linked it.
https://bugzilla.gnome.org/show_bug.cgi?id=796160
Transport specific sink elements are added to the pipeline
in PLAY request and sockets are already created in SETUP so
it's actually wrong to require the presence of sinks in
_get_*_socket() functions.
https://bugzilla.gnome.org/show_bug.cgi?id=793441
If a multicast client requests different transport settings
than the existing one make sure that this new transport
configuruation is propagated to the multicast udp sink.
https://bugzilla.gnome.org/show_bug.cgi?id=793441
Passwords are usually not stored in clear text, but instead
stored already hashed in a .htdigest file.
Add support for parsing such files, add API to allow setting
a custom realm in RTSPAuth, and update the digest example.
https://bugzilla.gnome.org/show_bug.cgi?id=796637
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 reverts commit 3d275b1345.
While RFC 3264 (SDP) says that sendonly/recvonly are from the point of view of
the requester, the actual RTSP RFCs (RFC 2326 / 7826) disagree and say
the opposite, just like the ONVIF standard.
Let's follow those RFCs as we're doing RTSP here, and add a property at
a later time if needed to switch to the SDP RFC behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=793964
If the media is complete, i.e. one or more streams have been configured
with sinks, then we want to query the position on those streams only.
A query on an incomplete stream may return a position that originates from
an earlier preroll.
https://bugzilla.gnome.org/show_bug.cgi?id=794964
Added it right before pushing the previous commit, it is
incorrect and deadlocks because this function gets called
from the join_bin thread, which already holds the lock,
that's the reason why request_aux_sender didn't take the
lock either.
"do-retransmission" was previously set when rtx-time != 0,
which made no sense as do-retransmission is used to enable
the sending of retransmission requests, where as rtx-time
is used by the peer to enable storing of buffers in order
to respond to retransmission requests.
rtsp-media now also provides a callback for the
request-aux-receiver signal.
https://bugzilla.gnome.org/show_bug.cgi?id=794822
rtsp-media-factory-uri.c: In function ‘rtsp_media_factory_uri_create_element’:
rtsp-media-factory-uri.c:621:17: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
data->factory = g_object_ref (factory);
^
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
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 test_record case was working because async=false had
been added in https://bugzilla.gnome.org/show_bug.cgi?id=757488
but that was incorrect, as it should not be needed.
Removing async=false made the test fail as expected, this is
fixed by not trying to preroll when preparing the media for
RECORD, as start_prepare is called upon receiving ANNOUNCE,
and our peer will not start sending media until it has received
a response to that request, and sent and received a response
to RECORD as well, thus obviously preventing preroll.
https://bugzilla.gnome.org/show_bug.cgi?id=793738
res is a boolean variable which is defined in the function scope and
redefined, with no reason, in the loop scope. This patch removes the
redefinition.
https://bugzilla.gnome.org/show_bug.cgi?id=793592
...and replace all checks for RECORD in GstRTSPMedia which are really
for "sender-only". This way the code becomes more generic and introducing
support for onvif-backchannel later on will require no changes in
GstRTSPMedia.
They are wrong in the ONVIF streaming spec. The backchannel should be
recvonly and the normal media should be sendonly: direction is always
from the point of view of the SDP offerer (the server) according to
RFC 3264.
This adds a new RTSP server, client, media-factory and media subclass
for handling the specifics of the backchannel. Ideally this later can be
extended with other ONVIF specific features.
The return value type is defined with G_DEFINE_POINTER_TYPE,
and gi emits the following warning:
Invalid non-constant return of bare structure or union; register as
boxed type or (skip)
This maps _new_empty() to _new(), which also makes RTSPToken()
work properly now. Since this API wasn't usable from bindings
before, this should hopefully be fine.
https://bugzilla.gnome.org/show_bug.cgi?id=787073
In the multicast case (as in test-multicast, not test-multicast2), the
address could be allocated/reserved (and thus set) already without
allocating the actual socket. We need to allocate the socket here still
instead of just claiming that it was already allocated.
See https://bugzilla.gnome.org/show_bug.cgi?id=791743#c2
SDP are now provided *before* the pipeline is fully complete. In order
to know whether a media is seekable or not therefore requires asking
the invididual streams.
API: gst_rtsp_stream_seekable
https://bugzilla.gnome.org/show_bug.cgi?id=790674
There is not need of adding fakesink elements to the media
pipeline in the dynamic-payloader case.
The media pipeline itself is dynamically updated with
the receiver and sender parts that are based on the client
transport information known after SETUP has been received.
Change-Id: I4e88c9b500c04030669822f0d03b1842913f6cb9
https://bugzilla.gnome.org/show_bug.cgi?id=790674
Media is complete when all the transport based parts are
added to the media pipeline. At this point ASYNC_DONE is
posted by the media pipeline and media is ready to enter
the PREPARED state.
Change-Id: I50fb8dfed88ebaf057d9a35fca2d7f0a70e9d1fa
https://bugzilla.gnome.org/show_bug.cgi?id=790674
If we still have some dynamic paylaoders which haven't posted
no-more-pads yet, don't go to PREPARED if one of the streams
blocked.
The risk was that we would end up not exposing/using all specified
streams.
The downside is that if you have _multiple_ _live_ _dynamic_ payloaders
then it will take a bit more time to start. But only if those 3
conditions are present.
https://bugzilla.gnome.org/show_bug.cgi?id=769521
If we have more than one dynamic payloader in the pipeline, we need
to wait until the *last* one emits 'no-more-pads' before switching
to PREPARED.
Failure to do so would result in a race where some of the streams
wouldn't properly be prepared
https://bugzilla.gnome.org/show_bug.cgi?id=769521
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
If no sinks have been added yet, obtain the current and
the stop position of the stream from the send_src pad.
Change-Id: Iacd4ab4bdc69f6b49370d06012880ce48a7d595a
https://bugzilla.gnome.org/show_bug.cgi?id=788340
