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 682481 - multiudpsink: add force-ipv4 option (problem when streaming RTP to multicast address)
multiudpsink: add force-ipv4 option (problem when streaming RTP to multicast ...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.11.x
Other Linux
: Normal major
: 1.0.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-22 14:58 UTC by Elis Popescu
Modified: 2012-10-10 08:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add a force-ipv4 option (3.79 KB, patch)
2012-10-09 18:37 UTC, rohde
committed Details | Review

Description Elis Popescu 2012-08-22 14:58:59 UTC
I am trying to create a simple gstreamer pipe to send a test stream to
a multicast address using RTP protocol. The pipe that I'm using is:

gst-launch-1.0 --gst-debug=1 --verbose audiotestsrc ! mulawenc !
rtppcmupay ! udpsink host=$MULTICAST_IP_ADDR auto-multicast=true
port=$AUDIO_UDP_PORT

Apparently this doesn't work with the latest version of gstreamer
(Gstreamer 0.11.93 or Gstreamer 0.11.92). The error that I get when I
run the pipe is:

(gst-launch-1.0:29785): GLib-GIO-CRITICAL **:
g_socket_multicast_group_operation: assertion
`g_inet_address_get_family (group) == socket->priv->family' failed
Caught SIGSEGV accessing address 0x8

The client side complains as well with this error:
Setting pipeline to PAUSED ...
0:00:01.124949799 29932       0xd81830 ERROR                 udpsrc
gstudpsrc.c:959:gst_udpsrc_stop:<udpsrc0> Failed to leave multicast
group: Error leaving multicast group: Cannot assign requested address
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Could
not get/set settings from/on resource.
Additional debug info:
gstudpsrc.c(897): gst_udpsrc_start (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
could add membership: Error joining multicast group: No such device
Setting pipeline to NULL ...
Freeing pipeline ...

At the client side I use the pipe:
gst-launch-1.0 --gst-debug=1 --verbose udpsrc
multicast-group=$MULTICAST_IP_ADDR auto-multicast=true
port=$AUDIO_UDP_PORT caps="application/x-rtp, media=(string)audio,
clock-rate=(int)8000, encoding-name=(string)PCMU, payload=(int)0,
ssrc=(guint)1350777638, clock-base=(guint)2942119800,
seqnum-base=(guint)47141" ! rtppcmudepay ! mulawdec ! fakesink


If I try the same pipes with the old version of gstreamer (GStreamer
0.10.36), it works fine. Am I missing something or this is a bug?

I'm using Ubuntu 12.04 and the Gstreamer and plugins (base, good, bad)
version is  0.11.93.

After a little bit of investigation it seems that it crashes with SIGSEGV inside the file plugins-good/gst/udsp/gstudpmulti.c in the method gst_multiudpsink_configure_client(..) at the line "GST_ELEMENT_ERROR (sink, RESOURCE, SETTINGS, (NULL),("Could not join multicast group: %s", err->message));" having the err pointer NULL. Apparently the call "g_socket_join_multicast_group (sink->used_socket, addr, FALSE, NULL,&err)" didn't initialize the err pointer when the multicast group joining failed.
Comment 1 Wim Taymans 2012-08-22 15:29:08 UTC
The reason is that udpsink will by default use an IPV6 socket and gio complains then when the ip address is not IPV6. Need to think what to do about it..

This fixes the crash:

commit 916e4c86fac864d2230590d99ec5c54b382e6e7b
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Aug 22 17:23:25 2012 +0200

    udpsink: don't crash on NULL error
    
    Check if there is an error before retrieving its message.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=682481
Comment 2 rohde 2012-10-09 18:37:33 UTC
Created attachment 226137 [details] [review]
Add a force-ipv4 option

Could we add this patch to at least enable the user to force the use of an ipv4 socket? This could also come in handy in other cases.

Trying to decide whether to use an ipv4 or ipv6 based on the host specified might break some existing code. This patch should be safe to introduce.
Comment 3 Wim Taymans 2012-10-10 08:29:55 UTC
commit 6c169312d1feb42fcb922e92f2f127f0ea429cfa
Author: Rasmus Rohde <rohde@duff.dk>
Date:   Wed Oct 10 10:28:24 2012 +0200

    multiudpsink: add force-ipv4 option
    
    Add an option to the multiudpsink that makes it possible to force
    the use of an IPv4 socket.
    
    This can e.g. be used to handle the issue described in
    https://bugzilla.gnome.org/show_bug.cgi?id=682481