[Live-devel] Read 2 video streams from 2 different multicast address on the same port

Ross Finlayson finlayson at live555.com
Thu Nov 8 02:11:30 PST 2007


>We have a multithreaded application (using live555 / linux)

I hope you've read the FAQ about threads.


>Under circumstances, some of our customers want to use for their video
>sources two different multicast addresses (let's say 239.61.87.46 and
>239.61.87.46)

FWIW, those are the same multicast address :-)

>, but the same port (say 8000)

This is a bad idea, as you discovered.

>Unfortunately, when reading the two RTP streams, live555 seems to mix
>the two streams into one.

This is usually an operating system problem.  Some OSs do not handle 
this (different multicast addresses using the same port number) 
properly.  That's why it's a bad idea to use the same port number 
with different multicast addresses.

>The solution is not to bind with INADDR_ANY, but with the desired
>multicast address:
>
>     // Whereas following works: socket will only see datagrams from
>'multicast_addr'
>     saddr.sin_addr.s_addr = inet_addr(multicast_addr);
>     status = bind(sock, (struct sockaddr *)&saddr, sizeof(struct
>sockaddr_in));

No, that's not the way bind() is supposed to work (if it works at all 
for you, then it's only by accident, I think).  I've never before 
heard of anyone (successfully) calling bind() on a multicast address.

>By default, ReceivingInterfaceAddr is INADDR_ANY: that's why we get the
>two video streams mixed on the video output.
>The problem is that ReceivingInterfaceAddr is a global variable. We
>would need here one different value (i.e. multicast address) for each
>reader.

No, if you set ReceivingInterfaceAddr at all, then it needs to be set 
to a *unicast* address - the IP address of the desired network 
interface, not a multicast address.

In any case, you probably should not be running the code 
multi-threaded within a single address space.  Instead, run multiple 
address spaces (i.e., one per receiver).  Again, please read the FAQ 
on threads.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


More information about the live-devel mailing list