GNOME Bugzilla – Bug 602312
multiudpsink Windows 7 64 bits
Last modified: 2013-04-22 21:31:09 UTC
In Windos 7/Vista using set GST_DEBUG=*udpsink*:5 and the 'sender': gst-launch-0.10.exe gstrtpbin ... rtph264pay ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! multiudpsink clients=\"127.0.0.1:56005,192.168.1.101:56000\" I get the following debug info: 0:00:21.073000000 6612 0281B0E0 WARN multiudpsink gstmultiudpsink.c: 410:gst_multiudpsink_render:<multiudpsink0> client 027EB160 gave error 0 (No err or) 0:00:21.074000000 6612 0281B0E0 LOG multiudpsink gstmultiudpsink.c: 425:gst_multiudpsink_render:<multiudpsink0> sent 1186 bytes to 0 (of 2) clients There is no 'sending' happening. The receivers on the local machine and on the remote do not receive anything. (The receivers work fine when tested with another sender(Linux) ). The same pipe works fine in Windows XP. Gstreamer was installed on Windows 7 64 bits using GStreamerWinBuild-0.10.4 I checked the source code and it looks like: ret = sendto (*client->sock, #ifdef G_OS_WIN32 (char *) data, #else data, #endif size, 0, (struct sockaddr *) &client->theiraddr, len); if (ret < 0) { /* some error, just warn, it's likely recoverable and we don't want to * break streaming. We break so that we stop retrying for this client. */ if (errno != EINTR && errno != EAGAIN) { GST_WARNING_OBJECT (sink, "client %p gave error %d (%s)", client, errno, g_strerror (errno)); break; } } else { num++; client->bytes_sent += ret; client->packets_sent++; sink->bytes_served += ret; break; } } } g_mutex_unlock (sink->client_lock); GST_LOG_OBJECT (sink, "sent %d bytes to %d (of %d) clients", size, num, no_clients); The firewall has been disabled for the test. On the same machine I can receive a similar stream sent from 192.168.1.101 (within the LAN, Linux machine).
The error reporting here is wrong for windows. So something's going wrong, but we don't log what it is. I've committed some patches to make the error reporting work right - if you re-test, hopefully we'll get the right error code and message, and then we can figure out what's wrong with the code and fix it.
Hi all I have been commenting on bug 604870 (https://bugzilla.gnome.org/show_bug.cgi?id=604870) as I encountered this problem while looking at that bug. Michael, as you mentioned above WSAGetLastError is missing in gstmultiudpsink.c. I added it and got two error codes while poking around WSAEFAULT (10014) "Bad address. The system detected an invalid pointer address in attempting to use a pointer argument of a call. This error occurs if an application passes an invalid pointer value, or if the length of the buffer is too small. For instance, if the length of an argument, which is a sockaddr structure, is smaller than the sizeof(sockaddr)." WSAEMSGSIZE (10040) "Message too long. A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram was smaller than the datagram itself." Re the size message, could this be related to bug 610364 (https://bugzilla.gnome.org/show_bug.cgi?id=610364) ? I am more than happy to test out things / change some code, but would need a bit of guidance here - I am running on a windows 7 pc, and have tried multiple different pipelines etc - all of them lead to no network traffic appearing because of the break in the code above when an error is detected. Any advice / suggestions would be most welcome, I really want to get this sorted :) Thanks
Some more information: Relevant code section is at http://pastebin.com/b4ss2uw6 On my win 7 machine, the following sizes are in use: len is 16, sizeof(struct sockaddr) is 16, sizeof(struct sockaddr_storage) is 128, sizeof(struct sockaddr_in) is 16 I'm not sure if len should be 16 or 128. http://msdn.microsoft.com/en-us/library/ms740148(VS.85).aspx says the last parameter is supposed to be the size, in bytes, of the address pointed to by the to parameter, which in this case is &client->theiraddr, a struct sockaddr_storage. There seems to be two issues here - one of sizes and one of ipv4 vs ipv6. IPv4/IPv6: There also seems to be something funny going on between IPv4 and IPv6. That seems to be the cause of the WSAEFAULT errors. ::1 works as an address whereas 127.0.0.1 doesn't. Logs at http://pastebin.com/i2bVZEug Then for the size issue, compare gst-launch-0.10 videotestsrc ! udpsink host=::1 port=3000 and gst-launch-0.10 audiotestsrc ! udpsink host=::1 port=3000. The audiotestsrc one tries to send 2048 bytes and succeeds, whereas the videotestsrc one tries to send 153600 bytes and fails with error 10040 (WSAEMSGSIZE). Logs at http://pastebin.com/RUyqCei0
For the EFAULT error: perhaps we're accidentally opening an IPv6 socket, then giving it v4 addresses? For the size issue: I guess that's normal: don't do that then?
> IPv4/IPv6: There also seems to be something funny going on between IPv4 and > IPv6. That seems to be the cause of the WSAEFAULT errors. ::1 works as an > address whereas 127.0.0.1 doesn't. Logs at http://pastebin.com/i2bVZEug This might be related to this bug: https://bugzilla.gnome.org/show_bug.cgi?id=534243
Hi all I'm pretty sure this is related to bug 604870 and bug 534243, of which an updated patch is available but needs to be reviewed and tested
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 534243 ***