We add different crypto sessions in MIKEY, one for each sender
SSRC. Currently, all of them will have the same security policy, 0.
The rollover counters are obtained from the srtpenc element using the
"stats" property.
https://bugzilla.gnome.org/show_bug.cgi?id=730539
It's what introspection.mak does as well. Should
fix spurious build failures on gnome-continuous
(caused by g-ir-scanner getting compiler details
via python which is broken in some environments
so passing the compiler details bypasses that).
- 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
