After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725872 - Gstreamer 1.2.3 dont work with udp multicast in Windows 7
Gstreamer 1.2.3 dont work with udp multicast in Windows 7
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.3
Other Windows
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-07 04:09 UTC by Andrey
Modified: 2016-05-22 22:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andrey 2014-03-07 04:09:48 UTC
Gstreamer 1.2.3 dont work with udp multicast in Windows 7. Gstreamer does not transmit or receive multicast packets. 
I have scanned ports by Wireshark, but there is not packets sended from Gstreamer. There is no log output with debug option GST_DEBUG=udp*:6 on sender side(server side). Pipeline on sender side  
gst-launch-1.0 --gst-debug=udp*:6  videotestsrc ! video/x-raw,format=RGB, width=320, height=240, framerate=30/1! videoconvert ! avenc_mpeg4 ! rtpmp4vpay config-interval=1 ! udpsink host=224.1.1.1 port=5004 auto-multicast=true

Pipeline of receiver side
gst-launch-1.0 udpsrc uri=udp://224.1.1.1:5004 caps="application/x-rtp, media=(string)video" ! rtpmp4vdepay ! avdec_mpeg4 ! videoconvert ! autovideosink

Debug output of receive side with option --gst-debug=udp*:6 is
gst-launch-1.0  --gst-debug=udp*:6 udpsrc uri=udp://224
1.1.1:5004 caps="application/x-rtp, media=(string)video" ! rtpmp4vdepay ! avdec
mpeg4 ! videoconvert ! autovideosink
Setting pipeline to PAUSED ...
0:00:00.479354698  3744   07EE9C40 DEBUG                 udpsrc gstudpsrc.c:824
gst_udpsrc_start:<udpsrc0> allocating socket for 224.1.1.1:5004
0:00:00.484223673  3744   07EE9C40 DEBUG                 udpsrc gstudpsrc.c:794
gst_udpsrc_resolve:<udpsrc0> IP address for host 224.1.1.1 is 224.1.1.1
0:00:00.487240744  3744   07EE9C40 DEBUG                 udpsrc gstudpsrc.c:837
gst_udpsrc_start:<udpsrc0> got socket 080051D8
0:00:00.490789888  3744   07EE9C40 DEBUG                 udpsrc gstudpsrc.c:844
gst_udpsrc_start:<udpsrc0> binding on port 5004
0:00:00.493673313  3744   07EE9C40 INFO                  udpsrc gstudpsrc.c:912
gst_udpsrc_start:<udpsrc0> have udp buffer of 8192 bytes
0:00:00.496406778  3744   07EE9C40 DEBUG                 udpsrc gstudpsrc.c:965
gst_udpsrc_start:<udpsrc0> joining multicast group 224.1.1.1
0:00:00.498551072  3744   07EE9C40 DEBUG                 udpsrc gstudpsrc.c:985
gst_udpsrc_start:<udpsrc0> bound, on port 5004
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
0:00:00.503949925  3744   07EE9C40 LOG                   udpsrc gstudpsrc.c:105
:gst_udpsrc_unlock_stop:<udpsrc0> No longer flushing
New clock: GstSystemClock
0:00:00.506317904  3744   07EE3EE8 LOG                   udpsrc gstudpsrc.c:421
gst_udpsrc_create:<udpsrc0> doing select, timeout 18446744073709551615
Comment 1 Sebastian Dröge (slomo) 2015-08-05 21:55:38 UTC
Is this still a problem with 1.5.2?
Comment 2 Tim-Philipp Müller 2016-05-22 22:41:07 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!