[gstreamer-bugs] [Bug 349907] New: multiudpsink messes up multicast addresses

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=349907
 GStreamer | gst-plugins-good | Ver: 0.10.x

           Summary: multiudpsink messes up multicast addresses
           Product: GStreamer
           Version: 0.10.x
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: marcelm at luon.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: 2.13/2.14
   GNOME milestone: Unspecified


When using multiudpsink or udpsink (which uses multiudpsink), specifying a
multicast address will cause multiudpsink to send the stream to apparently
random addresses:


[marcelm at almaz ~]$ gst-launch dv1394src ! rtpdvpay ! udpsink host=233.4.117.16
port=8000
[root at almaz test]# tcpdump udp
12:40:47.189004 IP almaz.32798 > 112.145.153.187.8000: UDP, length 972
12:40:47.207319 IP almaz.32798 > 112.145.153.187.8000: UDP, length 972


[marcelm at almaz ~]$ gst-launch dv1394src ! rtpdvpay ! udpsink host=233.4.117.16
port=8000
[root at almaz test]# tcpdump udp
12:40:52.225061 IP almaz.32799 > 96.166.232.97.8000: UDP, length 972
12:40:52.243152 IP almaz.32799 > 96.166.232.97.8000: UDP, length 972



[marcelm at almaz ~]$ gst-launch dv1394src ! rtpdvpay ! udpsink host=233.4.117.16
port=8000
[root at almaz test]# tcpdump udp
12:40:57.024684 IP almaz.32800 > 16.29.84.211.8000: UDP, length 972
12:40:57.263074 IP almaz.32800 > 16.29.84.211.8000: UDP, length 972


Etc.

The problem is in the gst_multiudpsink_add() function in gstmultiudpsink.c (in
gst-plugins-good). There, in the multicast special case the following happens:

      client->multi_addr.imr_multiaddr.s_addr = addr.s_addr;
      client->multi_addr.imr_interface.s_addr = INADDR_ANY;

      client->theiraddr.sin_addr = multi_addr.imr_multiaddr;

      setsockopt (sink->sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &multi_addr,
          sizeof (multi_addr));

There are two diffent struct ip_mreq instances here: multi_addr and
client->multi_addr. Of these, client->multi_addr is initialized but apparently
unused, and multi_addr is *not* initialized but used (the garbage in the
uninitialized multi_addr is what leads to the semi-random addresses).

It seems to me that the local multi_addr is completely unnessecary, and its
current usage is erroneous. If my understanding is correct, the multi_addr
should be removed, and everything should use client->multi_addr instead.

A patch for removing multi_addr and using client->multi_addr instead follows.
The patch works fine in my limited testing.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.