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
We were previously only ever waiting for a single stream to notify it's
blocked status through GstRTSPStreamBlocking. Actually count streams to
wait for.
Fixes rtspclientsink sending SDP's without out some of the input
streams.
https://bugzilla.gnome.org/show_bug.cgi?id=796624
Avoids confusing configure messages looking or a -good .pc file
that doesn't exist.
Also use plugindir variables that common macros set while at it.
https://bugzilla.gnome.org/show_bug.cgi?id=795466
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
Set transport string to NULL after freeing it, so that
at worst we get a NULL pointer if constructing a new
transport string fails (which shouldn't really fail here).
Also check return value of that, just in case.
CID 1433768.
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
This was broken since the work for delayed transport creation
was merged: the creation of the transports string depends on
calling stream_get_server_port, which only starts returning
something meaningful after a call to stream_allocate_udp_sockets
has been made, this function expects a transport that we parse
from the transport string ...
Significant refactoring is in order, but does not look entirely
trivial, for now we put a band aid on and create a second transport
string after the stream has been completed, to pass it in
the request headers instead of the previous, incomplete one.
https://bugzilla.gnome.org/show_bug.cgi?id=794789
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
As READY_TO_PAUSED can no longer return async, the RECORD
command will be queued before the OPEN command fails
(for example in case the server could not be connected),
and record then waits for ever.
https://bugzilla.gnome.org/show_bug.cgi?id=793896
