| Summary: | gstreamer sdk 2012.9 udpsink fails on windows 7 | ||
|---|---|---|---|
| Product: | GStreamer SDK | Reporter: | uovobw <uovobw> |
| Component: | Windows SDK Distribution | Assignee: | bugs |
| Status: | REOPENED --- | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | CC: | lrn1986, uovobw |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Windows (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
libgstudp.dll (x86_86)
libgstudp.dll (x86) libgstudp.dll (x86) |
||
|
Description
uovobw
2012-10-08 10:34:09 UTC
There were no changes to the UDP plugin since the first SDK release it seems, so the problem is most likely related to compiler options. (In reply to comment #1) > There were no changes to the UDP plugin since the first SDK release it > seems, so the problem is most likely related to compiler options. Maybe glib's GSocket? I'll check any news on this? i tested some more and found it's happening on 2012.7 as well, i was just never triggering it before. I have the windows 7 machine in hand now and i am trying to restart it with ipv6 disabled, to see if it makes any difference, as i read online that there was a bunch of ipv6 patches added lately that COULD be the cause So it's not a regression, it's just that it never worked. There was an upstrem bug that was closed recently because someone confirmed that the bug was fixed, but I think he was not testing it properly. i agree he was not, i am testing this on windows 7 and, with the ipv6 stack disabled, i get the _same_ error i posted in the first mail. there also seems to be no tcp plugin on the 2012.9 sdk, so there is basically no way of sending/receiving tcp/udp with windows atm... I will provide a new DLL with that fixed ASAP so that you don't have to wait until the next bugfix release. thank you very much! if any testing/help is needed please contact me on the user mail! Created attachment 68445 [details]
libgstudp.dll (x86_86)
Created attachment 68446 [details]
libgstudp.dll (x86)
Issue fixed at least in my side test with: gst-launch-0.10 videotestsrc ! ffenc_mpeg2video ! mpegtsmux ! udpsink gst-launch-0.10 udpsrc uri=udp://localhost:4951 ! decodebin2 ! d3dvideosink sync=false Andoni, I have been trying to get this to work with your attached fix. I think the file named libgstudp.dll (x86_86) is actually the 64-bit version. I tried executing the simple example that you posted in your comment but I couldn't get it to work because I don't have ffenc_mpeg2video as part of my installation. I also wonder why you specified udpsrc port 4951 in your test? Doesn't udpsink default to using port 5004? I then tried executing the example on the udpsrc manual page which looks like this: gst-launch-1.0 -v udpsrc ! fakesink dump=1 (In first terminal) gst-launch-1.0 -v audiotestsrc ! udpsink (In second terminal) and I just get a blank screen. No Data dump. It doesn't produce an error now so that is progress! I am very sorry to report this, but the bug is still not fixed in my system. I checked the path and i downloaded the libgstudp.dll file for my arch (x86) and deployed it in the GSTREAMER_SDK_ROOT_X86/lib/gstreamer-0.10/ directory after renaming the old file to libgstudp.dll_ORIG. The error persists with the same messages of the original bug. If needed i can provide the full GST_DEBUG=*:10 output thanks all for your time, let me know how i can help Just a thought: you said that you've been using gst-launch-1.0 to test it, not gst-launch-0.10. Why? AFAIU, the patched file is for 0.10. Was that just a typo? if referring to Jordan S (comment 11) i have no idea, i used gst-launch-0.10 from the sdk I finally got it working. This patch appears to be good. I can stream the audiotestsrc over udp. It doesn't work for streaming the videotestsrc but I think that's a buffer size problem and not an issue with udpsink. Check the example(In reply to comment #11) > Andoni, > I have been trying to get this to work with your attached fix. I think the > file named libgstudp.dll (x86_86) is actually the 64-bit version. x86 is the architecture name for 32bits and x86_64 for 64bits > > I then tried executing the example on the udpsrc manual page which looks > like this: > gst-launch-1.0 -v udpsrc ! fakesink dump=1 (In first terminal) > gst-launch-1.0 -v audiotestsrc ! udpsink (In second terminal) This won't work as the defaul url for udpsrc is udp://0.0.0.0:4951, so you should use udp://localhost:4951 as in the example. (In reply to comment #15) > I finally got it working. This patch appears to be good. I can stream the > audiotestsrc over udp. It doesn't work for streaming the videotestsrc but I > think that's a buffer size problem and not an issue with udpsink. Streaming raw video with udpsink will never work with udpsink unless you manage to split the big incomming buffers into smaller ones, that's why on my example in Comment10 I encoded and muxed the output of videotestsrc before streaming it. (In reply to comment #12) > I am very sorry to report this, but the bug is still not fixed in my system. > I checked the path and i downloaded the libgstudp.dll file for my arch (x86) > and deployed it in the GSTREAMER_SDK_ROOT_X86/lib/gstreamer-0.10/ directory > after renaming the old file to libgstudp.dll_ORIG. The error persists with > the same messages of the original bug. If needed i can provide the full > GST_DEBUG=*:10 output > > thanks all for your time, > let me know how i can help I think I forgot to run make install and I attached the old file :) Created attachment 68514 [details]
libgstudp.dll (x86)
awesome! i can confirm this udp lib is working (at least on windows 7 32bit and latest sdk with the dll dropped in) as expected! i have some pipelines problem atm but they seem to be failing due to rtp-related problems, so i'd say this patch is a keeper thanks a lot everyone for your work! Me again, it seems there still are some problems with udpsink on windows 7, i am trying to exclude the source of the problem (as i mentioned i had pipelines issues) and i just found that, with the 2012.9 sdk with the libgstudp.dll file dropped in ROOT/lib/gstreamer-0.10/ there are _no_ packets being sent. I tested with: gst-launch-0.10 fakesrc is-live=TRUE num-buffers=150 ! queue ! udpsink host=MYHOST port=1234 on MYHOST (a linux machine connected with a direct cable to the windows one) i am running tcpdump but i see NO packets coming in (and for what it's worth there are no packets being sent on the windows side as well, as i see no traffic in the system monitor, but i guess that is not a good measurement) There are no errors displayed with GST_DEBUG=*:8 and the pipeline works (until, of course, it gets a EOS from the fakesrc) where/how can i look more into this? thanks i have created two debug files: https://www.tapiri.homelinux.org/~uovobw/gst_debug.local.log https://www.tapiri.homelinux.org/~uovobw/gst_debug.remote.log the first for sending to 127.0.0.1 and the other one that would send to 192.168.17.77 The streamer pipeline used is: gst-launch-0.10 fakesrc is-live=TRUE num-buffers=150 ! queue ! udpsink host=MYHOST port=1234 any news on this? could you just try with locahost and not 127.0.0.1 like I requested on IRC? I think we have triggered a completely different bug tested with localhost as metnioned in irc (see comment #10), log here: https://www.tapiri.homelinux.org/~uovobw/gst_debug.localhost.log any news on this? more debug i can provide? this udp/localhost resolution bug is a pretty big showstopper to me, any way i can help please let me know! thanks I haven't found time to look at it yet, but I will before the end of the week any news on this? Hello, There is GstUdp backport from gst-1.0 to SDK (0.10) => https://github.com/heiher/gst-udp |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.