I ment gst-plugins-good 0.10.17, instead of gst-plugins-bad.

This commit seems to be the cause:
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=e2518fedbe8f6eb9cf1cf456381a5e350e2c4001

Reverting to http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=6a53d0a2c983bfeac2f02c9ef9cd3ff155f4e4fd fixes the bug

I don't have a windows system on which I can test this - however, I rewrote the error reporting recently so that on windows, it should give you the correct error in the debug output - instead of just "No error".

If you can re-test with that, maybe it'll provide enough hints for us to figure out the correct _fix_ for this.

(In reply to comment #4)
> I don't have a windows system on which I can test this - however, I rewrote the
> error reporting recently so that on windows, it should give you the correct
> error in the debug output - instead of just "No error".
I saw your commits, but there is another bug there:
https://bugzilla.gnome.org/show_bug.cgi?id=604872
Can you review it, please?
I was getting only an error code and the message was: "(null)" (maybe because I wasn't setting the len parameter in the right way.
I haven't my windows machine right now either, so I can't test it untill tomorrow.

Thanks for pointing out that bug - pushed a fix.

Just telling me what the error code is might be enough to be helpful, even if the message still isn't reported properly.

Using your fix for g_convert() setting lenght=-1 I get:
Could not set TTL socket option (0): S

While setting lenght=sizeof(buf) I get:
Could not set TTL socket option (1113): (null)

Should I reopen #604872?

To whom it may concern: the same error occurs on Mac OS 10.5.8, gst-plugins-good 0.10.18:

gst-launch audiotestsrc ! udpsink

Gives:

gstmultiudpsink.c(846): gst_multiudpsink_init_send (): /GstPipeline:pipeline0/GstUDPSink:udpsink0:
Could not set TTL socket option (22): Invalid argument

Tried to localise where this error is thrown in my case: from gstudpnetutils.c in the last if branch of gst_udp_set_ttl (addr.ss_family = AF_INET6, is_multicast = false). Apparently setting IPV6_UNICAST_HOPS goes alright, but trying to set IP_TTL to the same value (ttl = 64) gives this error (22).

Hi all

I tried using the latest release of the winbuilds (after getting the above ttl error). The pipeline seemed to run (whereas before it stopped), but no traffic appears on in my network dump.

I then downloaded the latest svn, built the gstudp project, and tried with those plugins - i get the same thing, no network traffic appears.

I tried with several different pipelines. The below log is generated by:

videotestsrc ! videoscale ! theoraenc ! queue ! udpsink  host=10.10.10.1 port=12343

I used wireshark to look for any traffic heading to 10.10.10.1, and nothing appeared.

Does the UDP sink currently work in any version on windows ? Is this something wrong with my setup?

0:00:00.079005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:767:gst_multiudpsink_add_internal:<GstUDPSink@01D23138> adding client on host localhost, port 4951
0:00:00.086005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:801:gst_multiudpsink_add_internal:<GstUDPSink@01D23138> added client on host localhost, port 4951
0:00:00.086005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:855:gst_multiudpsink_remove:<udpsink0> remove client with host localhost, port 4951
0:00:00.086005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:767:gst_multiudpsink_add_internal:<udpsink0> adding client on host 10.10.10.1, port 4951
0:00:00.086005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:801:gst_multiudpsink_add_internal:<udpsink0> added client on host 10.10.10.1, port 4951
0:00:00.086005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:855:gst_multiudpsink_remove:<udpsink0> remove client with host 10.10.10.1, port 4951
0:00:00.086005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:767:gst_multiudpsink_add_internal:<udpsink0> adding client on host 10.10.10.1, port 12343
0:00:00.086005000  4320   004F8CB0 DEBUG           multiudpsink gstmultiudpsink.c:801:gst_multiudpsink_add_internal:<udpsink0> added client on host 10.10.10.1, port 12343
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
0:00:00.126008000  4320   01CEDE20 LOG             multiudpsink gstmultiudpsink.c:392:gst_multiudpsink_render:<udpsink0> about to send 42 bytes
New clock: GstSystemClock
0:00:00.126008000  4320   01CEDE20 LOG             multiudpsink gstmultiudpsink.c:399:gst_multiudpsink_render:<udpsink0> sending 42 bytes to client 01D0D2E0
0:00:00.126008000  4320   01CEDE20 WARN            multiudpsink gstmultiudpsink.c:417:gst_multiudpsink_render:<udpsink0> client 01D0D2E0 gave error 0 (No error)
0:00:00.126008000  4320   01CEDE20 LOG             multiudpsink gstmultiudpsink.c:432:gst_multiudpsink_render:<udpsink0> sent 42 bytes to 0 (of 1) clients
0:00:00.126008000  4320   01CEDE20 LOG             multiudpsink gstmultiudpsink.c:392:gst_multiudpsink_render:<udpsink0> about to send 58 bytes
0:00:00.126008000  4320   01CEDE20 LOG             multiudpsink gstmultiudpsink.c:399:gst_multiudpsink_render:<udpsink0> sending 58 bytes to client 01D0D2E0
0:00:00.127008000  4320   01CEDE20 WARN            multiudpsink gstmultiudpsink.c:417:gst_multiudpsink_render:<udpsink0> client 01D0D2E0 gave error 0 (No error)

The Gstreamer WinBuilds release works b/c I reverted the sources to the parent of the commits introducing the regression.
As you see in the log it works (sending 42 bytes to
client 01D0D2E0
). You can also try with:
server -> videotestsrc ! udpsink host=locahost port=1234 clients=locahost:3000
client -> udpsrc uri=udp://locahost:1234 port=3000 ! fakesink dump=true

I am a bit confused as why I see 

"sent 42 bytes to 0 (of 1) clients"

etc in the logs then. Shouldn't that be "sent x bytes to 1 (of 1) clients" if it was working?  I must be doing something stupid, but cannot get a local server / client going, as well as never seeing anything on the wire between two different machines when testing remotely.

Any suggestions ?

I didn't realized that it was using multiudpsink, which doesn't work (#602312)

I didn't know about the other bug - will take this discussion there instead.

Thanks

On Windows the error is thrown in getsockname() (gstudpnetutils.c:168), with errorcode=10022.
Apparently this method can't be called on unbound sockets. See also http://bugs.python.org/issue1049.

Created attachment 155777 [details] [review]
0001-multiudpsink-swallow-errors-trying-to-call-getsockna.patch

There is a better way to do it but this patch fixes partially the bug.

Comment on attachment 155777 [details] [review]
0001-multiudpsink-swallow-errors-trying-to-call-getsockna.patch

This is a pretty nasty hack.

We only use the result of getsockname() to figure out the type of socket - better patch would be to pass that (or pass the whole struct sockaddr *) to this function, and adjust all the callers appropriately.

Pretty ugly hack indeed :)
Maybe something like:
gst_udp_set_ttl (int sockfd, int ttl, gboolean is_multicast, gboolen is_ipv6)

I wouldn't use a boolean - either pass the ss_family member, or the struct sockaddr *. Probably the ss_family is a good choice.

Created attachment 155786 [details] [review]
0001-multiudpsink-avoid-getting-the-socket-family-using-g.patch

The ss_family is get when the socket is created and then passed to set_ttl() and set_loop() instead of retrieving it from socketgetname()

Comment on attachment 155786 [details] [review]
0001-multiudpsink-avoid-getting-the-socket-family-using-g.patch

This one looks fine to me. Do you have commit access?

I don't, can do you it for me?
And thanks for helping me with the patch :)

Created attachment 155909 [details] [review]
Fixes for udp on windows vista / 7

Hi all

I have attached a patch that applies to current git from the patch above and from https://bugzilla.gnome.org/show_bug.cgi?id=534243

I now have working udp traffic on my windows 7 machine.

It needs to be tested on linux and windows XP to make sure I didn't break anything when re-arranging / merging patches based off old code.

I would appreciate it if someone could review how the ss_family is assigned to the sink in the gst_multiudpsink_init_send function, to make sure i didn't miss a case / how it should be handled. The rest of the code is pretty much as is from the other patches.

The patch has already been commited:

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=7f980d28aa23c64dce423c0c0f994b2d136fc7fe

we still got this error:
0:00:00.890625000   128   00382978 INFO     GST_ELEMENT_FACTORY
gstelementfactory.c:403:gst_element_factory_create: creating element
"udpsink"
0:00:00.890625000   128   00382978 INFO        GST_ELEMENT_PADS
gstelement.c:727:gst_element_add_pad:<GstBaseSink@00BA3A18> adding pad
'sink'
0:00:00.890625000   128   00382978 INFO              GST_STATES
gstelement.c:2211:gst_element_continue_state:<udpsink1> committing
state from NULL to READY, pending PLAYING, next PAUSED
0:00:00.890625000   128   00382978 INFO              GST_STATES
gstelement.c:2220:gst_element_continue_state:<udpsink1> continue state
change READY to PAUSED, final PLAYING
Sockfd is 1792, ss_family is 23, ttl is 64, is_multicast is 0
0:00:00.890625000   128   00382978 WARN            multiudpsink
gstmultiudpsink.c:906:gst_multiudpsink_configure_client:<udpsink1>
error: Could not set TTL socket option (10022): A
0:00:00.890625000   128   00382978 INFO        GST_ERROR_SYSTEM
gstelement.c:1763:gst_element_message_full:<udpsink1> posting message:
Could
not get/set settings from/on resource.
0:00:00.890625000   128   00382978 INFO        GST_ERROR_SYSTEM
gstelement.c:1786:gst_element_message_full:<udpsink1> posted error
message: Could not get/set settings from/on resource.
0:00:00.890625000   128   00382978 INFO              GST_STATES
gstelement.c:2555:gst_element_change_state:<udpsink1> have FAILURE
change_state return
0:00:00.890625000   128   00382978 INFO              GST_STATES
gstelement.c:2132:gst_element_abort_state:<udpsink1> aborting state
from READY to PLAYING

Works for me on XP and Vista and for other users too #534243
You should test with this installer: http://ossbuild.googlecode.com/files/GStreamer-WinBuilds-GPL-x86-RC01.msi

we already test that installer:-(
but may be that installer do not contains that fix...
but the same gst-lunch working on linux:-(

The issue still exists on Windows. The following pipeline fails because the TTL option could not be set (Windows error code 10022 WSAEINVAL, i.e. "An invalid argument was supplied"):
gst-launch-0.10 --gst-debug=*udp*:5 filesrc location=<some_small_file> ! udpsink port=5000

Output is:
******************
0:00:00.385077000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1061:gst_multiudpsink_add_internal:<GstUDPSink@029109E8> adding client on host localhost, port 4951
0:00:00.389078000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1089:gst_multiudpsink_add_internal:<GstUDPSink@029109E8> add client with host localhost, port 4951
0:00:00.389078000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1099:gst_multiudpsink_add_internal:<GstUDPSink@029109E8> added client on host localhost, port 4951
0:00:00.389078000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1141:gst_multiudpsink_remove:<udpsink0> found 1 clients with host localhost, port 4951
0:00:00.389578000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1145:gst_multiudpsink_remove:<udpsink0> remove client with host localhost, port 4951
0:00:00.389578000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1061:gst_multiudpsink_add_internal:<udpsink0> adding client on host localhost, port 5000
0:00:00.389578000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1089:gst_multiudpsink_add_internal:<udpsink0> add client with host localhost, port 5000
0:00:00.390078000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:1099:gst_multiudpsink_add_internal:<udpsink0> added client on host localhost, port 5000
Setting pipeline to PAUSED ...
0:00:00.390078000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:936:gst_multiudpsink_init_send:<udpsink0> creating sockets
0:00:00.390078000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:945:gst_multiudpsink_init_send:<udpsink0> have socket
0:00:00.390078000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:988:gst_multiudpsink_init_send:<udpsink0> could not get udp buffer size
0:00:00.390578000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:868:gst_multiudpsink_configure_client:<udpsink0> configuring client 08E3C0B0
0:00:00.390578000  4984   08C4F500 DEBUG           multiudpsink gstmultiudpsink.c:885:gst_multiudpsink_configure_client:<udpsink0> setting unicast ttl to 64
0:00:00.390578000  4984   08C4F500 WARN            multiudpsink gstmultiudpsink.c:908:gst_multiudpsink_configure_client:<udpsink0> error: Could not set TTL socket option (10022): A
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(908): gst_multiudpsink_configure_client (): /GstPipeline:pipeline0/GstUDPSink:udpsink0:
Could not set TTL socket option (10022): A
Setting pipeline to NULL ...
Freeing pipeline ...
******************

gstreamer version is 0.10.36, issue reproduced on Win Vista and Win 7.

In gstmultiudpsink.c at line 886, failure to set the TTL seems to be considered as fatal, but it shouldn't on Windows. From the MSDN documentation, IP_TTL support is not required and may not be supported.

In addition to the fact that a failure to set the TTL on Windows should not be considered fatal, the WSAEINVAL error code may indicate another bug as setsockopt is supposed to return WSAEINVAL only when "The level parameter is not valid, or the information in the buffer pointed to by the optval parameter is not valid". The level is IPPROTO_IP which seems correct and IP_TTL expects a pointer to DWORD which should be ok as the code passes an int*.

Created attachment 226274 [details] [review]
0001-udpsink-errors-setting-the-ttl-option-on-windows-are

Treat errors setting TTL as non fatals on windows