- Unicast udpsrcs are now managed in a hash table. This allows for proper cleanup in with shared streams and fixes a memory leak.
- Unicast udpsrcs are now properly cleaned up when shared connections exit. See the update_transport() function.
- Create unit test for shared media.
https://bugzilla.gnome.org/show_bug.cgi?id=764744
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
Deferred calls to start_prepare() can be deferred past the point until
which wait_preroll() and by proxy gst_rtsp_media_get_status() is
prepared to wait. Previously there was no lock and no check for this
situation. This meant that a media could be prepared and unprepared
simultaneously by two different threads. Now a lock is in place and a
suitable check is done.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=759773
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
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.
When doing a port scan (e.g. with nmap) the call to GST_RTSP_CHECK()
will sometimes fail. This call is made before any context is pushed
resulting in an attempt to pop a NULL context.
https://bugzilla.gnome.org/show_bug.cgi?id=757949
default_prepare() takes a transfer-none reference GstRTSPMedia object.
Later on a g_idle_source_new() is created and a pointer to the media
object is passed as user data. If the media is freed before the idle
source is dispatched the media object pointer is invalid, but the idle
source callback expects it to still be valid. To fix this a reference to
the media object is taken when registering the source callback function
and a corresponding release of the reference is done when the souce is
destroyed.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=755748
In parse_keymgmt(), don't mutate the input string that's been passed
as const, especially since we might need the original value again if
the same key info applies to multiple streams (RTX, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=754753
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
