[Bug 796875] rtsp-client: always allocate both IPV4 and IPV6 sockets

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796875

Mathieu Duponchelle <mduponchelle1 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #373163|needs-work                  |none
             status|                            |
 Attachment #373163|0                           |1
        is obsolete|                            |

--- Comment #3 from Mathieu Duponchelle <mduponchelle1 at gmail.com> ---
Created attachment 373192
  --> https://bugzilla.gnome.org/attachment.cgi?id=373192&action=edit
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.