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


[marcelm@almaz ~]$ gst-launch dv1394src ! rtpdvpay ! udpsink host=233.4.117.16 port=8000
[root@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@almaz ~]$ gst-launch dv1394src ! rtpdvpay ! udpsink host=233.4.117.16 port=8000
[root@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@almaz ~]$ gst-launch dv1394src ! rtpdvpay ! udpsink host=233.4.117.16 port=8000
[root@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.