rtsp-client: always allocate both IPV4 and IPV6 sockets
authorMathieu Duponchelle <mathieu@centricular.com>
Wed, 25 Jul 2018 17:54:55 +0000 (19:54 +0200)
committerMathieu Duponchelle <mathieu@centricular.com>
Wed, 1 Aug 2018 18:42:34 +0000 (20:42 +0200)
commit12f8abb549e71053a49eb3c4a7bfd6d1d3e5318e
tree75f704f9d811345674fc0992f0c130b2e2cc94f3
parent3baf94ed55d3c58edf292d843a817fa6af3ca084
rtsp-client: always allocate both IPV4 and IPV6 sockets

multiudpsink does not support setting the socket* properties
after it has started, which meant that rtsp-server could no
longer serve on both IPV4 and IPV6 sockets since the patches
from https://bugzilla.gnome.org/show_bug.cgi?id=757488 were
merged.

When first connecting an IPV6 client then an IPV4 client,
multiudpsink fell back to using the IPV6 socket.

When first connecting an IPV4 client, then an IPV6 client,
multiudpsink errored out, released the IPV4 socket, then
crashed when trying to send a message on NULL nevertheless,
that is however a separate issue.

This could probably be fixed by handling the setting of
sockets in multiudpsink after it has started, that will
however be a much more significant effort.

For now, this commit simply partially reverts the behaviour
of rtsp-stream: it will continue to only create the udpsinks
when needed, as was the case since the patches were merged,
it will however when creating them, always allocate both
sockets and set them on the sink before it starts, as was
the case prior to the patches.

Transport configuration will only error out if the allocation
of UDP sockets fails for the actual client's family, this
also downgrades the GST_ERRORs in alloc_ports_one_family
to GST_WARNINGs, as failing to allocate is no longer
necessarily fatal.

https://bugzilla.gnome.org/show_bug.cgi?id=796875
gst/rtsp-server/rtsp-client.c
gst/rtsp-server/rtsp-stream.c