Component = udpsink
OS = Im using a 64bit kernel enabled Snow Leopard Version 10.6.4.

Description
========
whenever udpsink is used it will not work under OSX (at least under the system i am using).

To produce
=========
type at a command line:
   gst-launch audiotestsrc ! udpsink
The following error is produced.
vvvv Start Error vvvv
  ....
  ERROR: Pipeline doesn't want to pause.
  ERROR: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Could not get/set settings from/on resource.
  Additional debug info:
  gstmultiudpsink.c(804): gst_multiudpsink_configure_client (): /GstPipeline:pipeline0/GstUDPSink:udpsink0:
  Could not set TTL socket option (22): Invalid argument
  ....
^^^^ Error Finish ^^^^

Diagnosis
=======
Seeing that it had to do with trying to set the TTL option of the socket I hunted down three places it could be.
line 165, 174 and/or 182 of gstudpnetutils.c.
I commented out various combination of those lines and found the offending line was line 182.
Original line:
      ret = setsockopt (sockfd, IPPROTO_IP, optname, &ttl, sizeof (ttl));
Modified line for test:
      ret = 0; //setsockopt (sockfd, IPPROTO_IP, optname, &ttl, sizeof (ttl));

Ran make and copied over the new libgstudp.la and libgstudp.so over the original.
Ran the command line:
  gst-launch audiotestsrc ! udpsink
and it worked BUT running the following on ANOTHER command prompt at the same time didn't produce any output (including error nor discernible audio):
  gst-launch udpsrc caps='audio/x-raw-int,depth=16' ! audioconvert ! osxaudiosink

Suspecting that it was to do with the fact that the sender tries to use an IP6 socket first (line 833 of gstmultiudpsink.c) and the receiver might be using an IP4 socket (didnt chase code here).
I commented out line 833 and line 837 (the matching brace) of gstmultiudpsink.c thus forcing it to ALWAYS use IP4 sockets.

Ran make and copied over the two files as before (libgstudp.[la|so]) and proceeded to run the same test.
This time the receiver produced an error (floating point exception).
This is good as it means that the sender (udpsink) is connecting to the receiver (udpsrc).
Regarding the floating point exception I am thinking this is to do with the way I have setup the pipelines and nothing to do with what this bug report is trying to address.

Conclusion
========
Under the OsX system I am using i would suggest the following:
1 - that calling the setsockopt() for IPPROTO_IP on a socket that has been opened as AF_INET6 is an error.
2 - that the assumption in function gst_multiudpsink_init_send() about being able to use an AF_INET6 socket to talk to an AF_INET endpoint will not work(?).

Please excuse my lack of knowledge re: point 2 here as I have not ever done any IP6 work.
It is just what it appears to me.


I hope this is enough information.

Regards,
Alfred

PS
I could not find anything in the guidelines about severity.
So considering that this component just WONT work at all under OsX Snow Leopard, I marked it as a 'blocker'.