GNOME Bugzilla – Bug 700878
udpsink: Not sending anything on Windows
Last modified: 2013-05-28 09:56:55 UTC
gstmultiudpsink.c:509:gst_multiudpsink_render:<udpsink0> about to send 2048 bytes gstmultiudpsink.c:520:gst_multiudpsink_render:<udpsink0> sending 2048 bytes to client 0000000002D05540 tested with wireshark, there was no udp activity - nothing. debug logs: http://kodtov.com/b/gs2.txt http://kodtov.com/b/gs3.txt http://kodtov.com/b/gs1.txt
slomo: tcp works!
I can confirm that here, and TCP works just fine.
FWIW, it waits forever in WSAWaitForMultipleEvents() to tell us that something can be written to the socket... which never happens. However there are some rare combinations of clients/host/port properties when this happens, but no packets are send there although the socket claims so. This looks like a bug in GLib though.
commit 5b79b8ff3c96acf5a43898062c3b830c18c5b34f Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Thu May 23 18:05:07 2013 +0200 (dyn|multi)udpsink: Bind socket before using it https://bugzilla.gnome.org/show_bug.cgi?id=700878
when does udp do work? is anyone opened a bug for it in GLib, how to make it work?
It wasn't actually a GLib bug (well, GLib could error out properly if stuff is done wrong). Just rebuild with this patch: http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?h=1.0&id=130268bc73c21fd122ce2a2f48ad6500df0b4e41 It's applying cleanly to the last releases. Or just build from the 1.0 branch (or git master).
ohhh youre awesome. i will be trying it out right now. thanks
seems not working yet to bugs left: 1. it can't use ipv4 addresses. it does WSAEFAULT. 2. in udpsrc if i try to send to ipv6 from the udpsink, it doesn't do but seems like ipv4 listen , doesn't receive data from ipv6 send. it is stuck at select and doesn't receives data. 0:00:03.606905209 5084 0000000002D3B500 LOG udpsrc gstudpsrc.c:403:gst_udpsrc_create:<udpsrc0> doing select, timeout 0 i think because of ip filter=ip_any, is filtering for ipv4 only. because wireshark shows data is sent. but no data is receiven in the application. found out wireshark is not good for loopback testing on windows. process explorer shows some events, it helps to select only network, and choose drop filtered events from menu. but with a different computer on network wireshark shows activity. tail of the log of the udpsrc: 0:00:03.600328963 5084 000000000050B030 DEBUG GST_BUS gstbus.c:316:gst_bus_post:<bus0> [msg 000000000050F310] posting on bus 000000000050F310 0:00:03.600439442 5084 000000000050B030 DEBUG bin gstbin.c:3270:gst_bin_handle_message_func:<pipeline0> [msg 000000000050F310] handling child udpsrc0 message of type state-changed 0:00:03.600526981 5084 000000000050B030 DEBUG bin gstbin.c:3563:gst_bin_handle_message_func:<pipeline0> posting message upward 0:00:03.600625990 5084 000000000050B030 DEBUG GST_BUS gstbus.c:316:gst_bus_post:<bus1> [msg 000000000050F310] posting on bus 000000000050F310 0:00:03.601338371 5084 000000000050B030 DEBUG GST_BUS gstbus.c:351:gst_bus_post:<bus1> [msg 000000000050F310] pushing on async queue 0:00:03.601430437 5084 000000000050B030 DEBUG GST_BUS gstbus.c:354:gst_bus_post:<bus1> [msg 000000000050F310] pushed on async queue 0:00:03.601490809 5084 000000000050B030 DEBUG GST_BUS gstbus.c:347:gst_bus_post:<bus0> [msg 000000000050F310] dropped 0:00:03.601605816 5084 000000000050B030 LOG GST_STATES gstelement.c:2644:gst_element_change_state:<udpsrc0> exit state change 1 0:00:03.601709051 5084 000000000050B030 DEBUG GST_STATES gstelement.c:2555:gst_element_set_state_func:<udpsrc0> returned SUCCESS 0:00:03.601776365 5084 000000000050B030 INFO GST_STATES gstbin.c:2602:gst_bin_change_state_func:<pipeline0> child 'udpsrc0' changed state to 4(PLAYING) successfully 0:00:03.601868129 5084 000000000050B030 DEBUG bin gstbin.c:2050:gst_bin_sort_iterator_next:<pipeline0> queue empty, elements exhausted 0:00:03.602340233 5084 000000000050B030 DEBUG GST_STATES gstbin.c:2661:gst_bin_change_state_func:<pipeline0> iterator done 0:00:03.602406641 5084 000000000050B030 LOG GST_STATES gstelement.c:2789:gst_element_change_state_func:<pipeline0> default handler tries setting state from PAUSED to PLAYING (001c) 0:00:03.602469126 5084 000000000050B030 DEBUG GST_STATES gstbin.c:2679:gst_bin_change_state_func:<pipeline0> we have ASYNC elements SUCCESS -> ASYNC 0:00:03.602563607 5084 000000000050B030 DEBUG bin gstbin.c:2092:gst_bin_sort_iterator_free:<pipeline0> free 0:00:03.602676803 5084 000000000050B030 DEBUG bin gstbin.c:2707:gst_bin_change_state_func:<pipeline0> check async elements 0:00:03.602751060 5084 000000000050B030 LOG bin gstbin.c:857:message_check: looking at message 000000000050F110: 1 0:00:03.602873915 5084 000000000050B030 DEBUG bin gstbin.c:877:find_message:<pipeline0> we found a message 000000000050F110 from fakesink0 matching types 00100000 0:00:03.603500268 5084 000000000050B030 DEBUG GST_STATES gstbin.c:2730:gst_bin_change_state_func:<pipeline0> done changing bin's state from PAUSED to PLAYING, now in PAUSED, ret ASYNC 0:00:03.603601390 5084 000000000050B030 DEBUG GST_STATES gstelement.c:2610:gst_element_change_state:<pipeline0> element will change state ASYNC 0:00:03.603707643 5084 000000000050B030 LOG GST_STATES gstelement.c:2650:gst_element_change_state:<pipeline0> exit async state change 2 0:00:03.603775863 5084 000000000050B030 DEBUG GST_STATES gstelement.c:2555:gst_element_set_state_func:<pipeline0> returned ASYNC 0:00:03.603868835 5084 000000000050B030 DEBUG GST_BUS gstelement.c:3012:gst_element_get_bus:<pipeline0> got bus 0000000002D3AC40 0:00:03.603943695 5084 000000000050B030 DEBUG GST_BUS gstbus.c:874:gst_bus_add_watch_full_unlocked:<bus1> New source 0000000002D64540 with id 17 0:00:03.604495791 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1085:gst_bus_poll: running mainloop 0000000002D4A960 0:00:03.604585744 5084 000000000050B030 LOG GST_BUS gstbus.c:502:gst_bus_timed_pop_filtered:<bus1> have 3 messages 0:00:03.604705279 5084 000000000050B030 DEBUG GST_BUS gstbus.c:510:gst_bus_timed_pop_filtered:<bus1> got message 000000000050F710, stream-start from pipeline0, type mask is 4294967295 0:00:03.604775310 5084 000000000050B030 DEBUG GST_BUS gstbus.c:771:gst_bus_source_dispatch:<bus1> source 0000000002D64540 calling dispatch with 000000000050F710 0:00:03.604866470 5084 000000000050B030 DEBUG GST_BUS gstbus.c:977:poll_func: mainloop 0000000002D4A960 quit 0:00:03.598011912 5084 0000000002D3B500 DEBUG GST_PADS gstpad.c:3589:gst_pad_peer_query:<udpsrc0:src> query failed 0:00:03.604948575 5084 000000000050B030 DEBUG GST_BUS gstbus.c:776:gst_bus_source_dispatch:<bus1> source 0000000002D64540 handler returns 1 0:00:03.605074450 5084 0000000002D3B500 DEBUG basesrc gstbasesrc.c:2973:gst_base_src_prepare_allocation:<udpsrc0> peer ALLOCATION query failed 0:00:03.605646166 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1087:gst_bus_poll: mainloop stopped 0000000002D4A960 0:00:03.605845995 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1332:gst_bus_remove_signal_watch:<bus1> removing signal watch 17 0:00:03.605753627 5084 0000000002D3B500 DEBUG basesrc gstbasesrc.c:2980:gst_base_src_prepare_allocation:<udpsrc0> ALLOCATION (1) params: 0000000002D40740 0:00:03.605915120 5084 000000000050B030 DEBUG GST_BUS gstbus.c:797:gst_bus_source_finalize:<bus1> finalize source 0000000002D64540 0:00:03.606022279 5084 0000000002D3B500 LOG basesrc gstbasesrc.c:2614:gst_base_src_loop:<udpsrc0> next_ts 99:99:99.999999999 size 4096 0:00:03.606095026 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1100:gst_bus_poll:<bus1> finished poll with message 000000000050F710 0:00:03.606691797 5084 000000000050B030 LOG GST_MESSAGE gstmessage.c:184:_gst_message_free: finalize message 000000000050F710, stream-start from pipeline0 0:00:03.606198261 5084 0000000002D3B500 DEBUG basesrc gstbasesrc.c:2351:gst_base_src_get_range:<udpsrc0> calling create offset 18446744073709551615 length 4096, time 0 0:00:03.606764544 5084 000000000050B030 DEBUG GST_BUS gstbus.c:874:gst_bus_add_watch_full_unlocked:<bus1> New source 0000000002D64540 with id 18 0:00:03.606963770 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1085:gst_bus_poll: running mainloop 0000000002D4AA20 0:00:03.606905209 5084 0000000002D3B500 LOG udpsrc gstudpsrc.c:403:gst_udpsrc_create:<udpsrc0> doing select, timeout 0 0:00:03.607091757 5084 000000000050B030 LOG GST_BUS gstbus.c:502:gst_bus_timed_pop_filtered:<bus1> have 2 messages 0:00:03.607965631 5084 000000000050B030 DEBUG GST_BUS gstbus.c:510:gst_bus_timed_pop_filtered:<bus1> got message 000000000050F390, new-clock from pipeline0, type mask is 4294967295 0:00:03.608057698 5084 000000000050B030 DEBUG GST_BUS gstbus.c:771:gst_bus_source_dispatch:<bus1> source 0000000002D64540 calling dispatch with 000000000050F390 0:00:03.608227643 5084 000000000050B030 DEBUG GST_BUS gstbus.c:977:poll_func: mainloop 0000000002D4AA20 quit 0:00:03.608315181 5084 000000000050B030 DEBUG GST_BUS gstbus.c:776:gst_bus_source_dispatch:<bus1> source 0000000002D64540 handler returns 1 0:00:03.608421737 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1087:gst_bus_poll: mainloop stopped 0000000002D4AA20 0:00:03.608467317 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1332:gst_bus_remove_signal_watch:<bus1> removing signal watch 18 0:00:03.608628810 5084 000000000050B030 DEBUG GST_BUS gstbus.c:797:gst_bus_source_finalize:<bus1> finalize source 0000000002D64540 0:00:03.609274180 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1100:gst_bus_poll:<bus1> finished poll with message 000000000050F390 New clock: GstSystemClock 0:00:03.609360209 5084 000000000050B030 LOG GST_MESSAGE gstmessage.c:184:_gst_message_free: finalize message 000000000050F390, new-clock from pipeline0 0:00:03.609485479 5084 000000000050B030 DEBUG GST_BUS gstbus.c:874:gst_bus_add_watch_full_unlocked:<bus1> New source 0000000002D64540 with id 19 0:00:03.609562151 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1085:gst_bus_poll: running mainloop 0000000002D4A8E0 0:00:03.609711872 5084 000000000050B030 LOG GST_BUS gstbus.c:502:gst_bus_timed_pop_filtered:<bus1> have 1 messages 0:00:03.609791562 5084 000000000050B030 LOG GST_POLL gstpoll.c:201:release_wakeup: 0000000000508D20: release 0:00:03.609913512 5084 000000000050B030 DEBUG GST_BUS gstbus.c:510:gst_bus_timed_pop_filtered:<bus1> got message 000000000050F310, state-changed from udpsrc0, type mask is 4294967295 0:00:03.610676605 5084 000000000050B030 DEBUG GST_BUS gstbus.c:771:gst_bus_source_dispatch:<bus1> source 0000000002D64540 calling dispatch with 000000000050F310 0:00:03.610799461 5084 000000000050B030 DEBUG GST_BUS gstbus.c:977:poll_func: mainloop 0000000002D4A8E0 quit 0:00:03.610962161 5084 000000000050B030 DEBUG GST_BUS gstbus.c:776:gst_bus_source_dispatch:<bus1> source 0000000002D64540 handler returns 1 0:00:03.611018608 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1087:gst_bus_poll: mainloop stopped 0000000002D4A8E0 0:00:03.611088941 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1332:gst_bus_remove_signal_watch:<bus1> removing signal watch 19 0:00:03.611174065 5084 000000000050B030 DEBUG GST_BUS gstbus.c:797:gst_bus_source_finalize:<bus1> finalize source 0000000002D64540 0:00:03.612098349 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1100:gst_bus_poll:<bus1> finished poll with message 000000000050F310 0:00:03.612221507 5084 000000000050B030 LOG GST_MESSAGE gstmessage.c:184:_gst_message_free: finalize message 000000000050F310, state-changed from udpsrc0 0:00:03.612361266 5084 000000000050B030 DEBUG GST_BUS gstbus.c:874:gst_bus_add_watch_full_unlocked:<bus1> New source 0000000002D64540 with id 20 0:00:03.612444881 5084 000000000050B030 DEBUG GST_BUS gstbus.c:1085:gst_bus_poll: running mainloop 0000000002D4AA20
That IPv6 problem is known and should be fixed in latest git master (not in the 1.0 branch though because the changes are rather intrusive). Try using setting force-ipv4=true on udpsink to be able to use IPv4 addresses.
Does this work for you now?
Yes it works! when i set force-ipv4=true it works for me. I think I have some unrelated errors. If I stream udp of testvideosrc encoded in realtime x264 to 127.0.0.1 it freezes after like 20 seconds. Also I have to connect everything in order - first restart the client, then start the server. otherwise it also not works. It is strange because on loopback I had guessed there shouldn't be udp losses or order mess ups, but seems like there are.