GNOME Bugzilla – Bug 696057
udpsink does not work with IPv4 addresses on MacOSX
Last modified: 2013-04-25 10:30:04 UTC
udpsink does not work with IPv4 destination addresses on MacOSX. Tried on both 10.7 and 10.8. All systems were multihomed and IPv6 configured to "automatic", in case that matters. The easiest way to see the problem is as follows: $ gst-launch-1.0 -v audiotestsrc ! mulawenc ! rtppcmupay ! udpsink host="localhost" port="13002" works fine. $ gst-launch-1.0 -v audiotestsrc ! mulawenc ! rtppcmupay ! udpsink host="127.0.0.1" port="13002" fails, with errors WARNING: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Error sending UDP packet Additional debug info: gstmultiudpsink.c(545): gst_multiudpsink_render (): /GstPipeline:pipeline0/GstUDPSink:udpsink0: Reason: Error sending message: Invalid argument The problem turns out to be (after an incredible amount of debugging:-) that gstmultiudpsink opens an IPv6 socket, and then does a sendmsg() to an IPv4 address. Apparently this works on Linux, but not on BSD systems, see for example <http://stackoverflow.com/questions/8087478/using-sendto-on-a-ipv6-socket-to-send-to-a-ipv4-address>. The workaround is to use force-ipv4=true on udpsink, obviously. However, I think that at the very least a better error message would be in place. Even better would be converting the IPv4 address to its ::ffff: form.
It should use two separate sockets, one for only IPv4 and one for only IPv6. This would also fix it on systems that don't allow both protocols to be used with the same socket.
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 534243 ***