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
Without this, RECORD pipelines are broken because
a) we wait for ASYNC_DONE which never happens anymore because udpsrc would be
added later. Previously it was there earlier and due to NO_PREROLL caused the
pipeline to preroll immediately
b) the udpsrc for the pipeline is added later and never set to PLAYING state,
as the corresponding code previously was only for PLAY pipelines.
https://bugzilla.gnome.org/show_bug.cgi?id=763281
On Windows this is a receiver-side setting, on Linux a sender-side setting. As
we provide a socket ourselves to udpsrc, udpsrc is never setting the multicast
loopback setting on the socket... while udpsink does which unfortunately has
no effect here on Windows but on Linux.
https://bugzilla.gnome.org/show_bug.cgi?id=757488
On Linux it is still needed to bind to the multicast address
to filter out random other packets, while on Windows binding
to multicast addresses just fails.
Otherwise we fail to allocate UDP ports if the pool only contains multicast
addresses, which is something that used to work before. For unicast addresses
if the pool contains none, we just allocate them as if there is no pool at
all.
https://bugzilla.gnome.org/show_bug.cgi?id=757488
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
Code refactoring: allocate the UDP ports after the sender and
the reciver parts have been created.
We postpone the creation of the UDP sources until the UDP
ports have been allocated.
https://bugzilla.gnome.org/show_bug.cgi?id=757488
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
* gst/rtsp-server/rtsp-stream.c: add new method gst_rtsp_stream_get_pt.
* gst/rtsp-server/rtsp-media.c (pad_added_cb): find real payloader
element and create the stream with this one instead of the dynpay%d
element.
https://bugzilla.gnome.org/show_bug.cgi?id=712396
* rtsp-auth: Refer to GstRTSPToken, not GstRTSPtoken
* rtsp-auth: Refer to part of constant name as text
* rtsp-auth/-permissions/-token: Refer to Permissions not Permission
* rtsp-session-media: Fix GstRTSPSessionMedia typo
* rtsp-stream: Fix typo when refering to GstBin
https://bugzilla.gnome.org/show_bug.cgi?id=714988
Rename _get_address to _get_multicast_address in GstRTSPStream to
make it clear that this function only deals with multicast.
Make it possible to have both an IPv4 and IPv6 multicast address on
a stream. Give the client an IPv4 or IPv6 address depending on the
address it used to connect to the server.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702002
Allow for ipv4 or ipv6 socket allocations to fail. Only report failure if we
can't allocate any family at all. Also keep track of what port families we
allocated.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=703175
