Add a boolean to indicate that the rtsp-stream is running on the
'client' side of an RTSP connection, for sending streams via
RECORD. In that case, the roles of the client/server ports
in transport setup are swapped.
https://bugzilla.gnome.org/show_bug.cgi?id=758180
When RTSP server trying update transport during multicast, it throws an
assert. The assert is thrown because it is trying to get the parent of
an non-existing funnel element.
https://bugzilla.gnome.org/show_bug.cgi?id=760150
Based on the protocol, create the rtsp stream pipeline. If only TCP or
only UDP is set as the transport protocol, it will not add the extra tee
or queue element to the pipeline. Both these elements will be added, if
it supports both TCP and UDP protocols. This improves the pipeline
performance when one protocol is present.
https://bugzilla.gnome.org/show_bug.cgi?id=758179
Adding them when not needed will start some logic inside rtpbin that might be
problematic. Also if e.g. for a sender media we suddenly receive RTP data, we
would start up a rtpjitterbuffer and behave in weird ways.
We still set up the UDP sources for RTP receiving for a sender media to be
able to receive any packets sent by the client for NAT traversal. They will
all go to a fakesink though.
Having an rtpjitterbuffer in the media pipeline will cause the pipeline to be
NO_PREROLL, which will cause deadlocks when seeking the media as it will never
receive ASYNC_DONE after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=758319
On POSIX this setting is for sender sockets, on Windows for receiver sockets.
Previously we were only setting this for sender sockets, which caused looped
back packets to be received on Windows if a multicast transport was used.
Add gst_rtsp_stream_(get|set)_buffer_size and use it to configure the
UDP TX buffer size.
Incorporates a patch by Hyunjun Ko <zzoon.ko@samsung.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=749095
Because of duplicated g_signal_connect for request-aux-sender signal,
wrong stream pointer is passed to the signal handler.
Instead of passing each stream, pass stream array and get the relevant stream.
https://bugzilla.gnome.org/show_bug.cgi?id=747839
RTCP packets were not sent because the same tr_cache_cookie was used for
both RTP and RTCP. So only one of the tr_cache lists were populated
depending on which one was sent first. If the tr_cache list is not
populated then no packets can be sent. Most often this happened to be
RTCP. Now seperate RTCP and RTP transport cache cookies are added which
resulted in both the tr_cache_lists to be populated regardless of which
one was sent first.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=743734
Fixes crash when two threads access handle_new_sample() at the same
time, one for RTP, one for RTCP.
Otherwise, when iterating over the transports cache, it might be modified by
another thread at the same time if the transports cookie has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=742954
rtsp-stream.c:1351:3: error: non-void function 'gst_rtsp_stream_get_retransmission_time' should return a value [-Wreturn-type]
g_return_if_fail (GST_IS_RTSP_STREAM (stream));
^
rtsp-stream.c:1384:3: error: non-void function 'gst_rtsp_stream_get_retransmission_pt' should return a value [-Wreturn-type]
g_return_if_fail (GST_IS_RTSP_STREAM (stream));
^
The sequence number is not monotonic for RTP packets after pause. The
reason is basepayloader generates a randon sequence number when the
pipeline goes from ready to pause. With this fix generation of sequence
number will be monotonic when going from pause to play request.
https://bugzilla.gnome.org/show_bug.cgi?id=736017
The RTCP parts, in specific the RTCP udpsinks, are not flushed when
seeking and will always continue counting the time. This leads to
the NPT after a backwards seek to be something completely different
to the actual seek position.
https://bugzilla.gnome.org/show_bug.cgi?id=732644
When a UDP multicast transport is used it is expected that the server listens
for RTP and RTCP packets on the multicast group with the corresponding port.
Without this we will never get RTCP packets from clients in multicast mode.
https://bugzilla.gnome.org/show_bug.cgi?id=732238
Release the object lock before calling the filter functions. We need to
keep a cookie to detect when the list changed during the filter
callback. We also keep a hashtable to make sure we only call the filter
function once for each object in case of concurrent modification.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732950
