[FFmpeg-devel] UDP multicasts mixed up on receive due to wrong bind()

Laurent laurent.aml
Wed Oct 15 00:09:19 CEST 2008


Hi,

Basically, using the same socket port for 2 applications is not a good
idea, as the port is what identifies the application within a host.
This would be obvious if you try to do the same test with unicast
instead of multicast. You would naturally use 2 different ports, as
the destination IP address would be identical for both streams.

Nevertheless, the demultiplexing of UDP packets to sockets is done
using the port, and also the destination address (the multicast
address, for instance). Thanks to that, binding to the multicast
address solves the current problem, on Linux, at least.

However, this is not a "standard" usage of bind. For instance, Windows
XP does not implement this feature.

So, your patch is system-dependant.


IMHO, preventing to play 2 streams on the same port is the correct behavior.

Thanks,


On 10/14/08, Luca Abeni <lucabe72 at email.it> wrote:
> Hi Ramiro,
>
> Ramiro Polla wrote:
> [...]
> >> I think I had a similar patch some time ago (to solve the very same
> >> problem :), but I've been told that it causes problems on windows
> >> (and I could only test it on linux).
> >
> > Could you elaborate on the kind of problems and how to reproduce it. I
> > might take a look...
>
> I do not know the exact problem: the description I received was something
> like "it works on linux, but not on windows". And I never had any way to
> check (no windows here... And wine was unable to reproduce any problem,
> probably because it is based on linux).
>
> Anyway, my patch was here:
> http://roundup.mplayerhq.hu/roundup/ffmpeg/msg2210
> (not identical to this patch, but similar - I think it has the same effect),
> and you can find more details here:
> http://roundup.mplayerhq.hu/roundup/ffmpeg/issue481
>
> The discussion continued talking about the order of multicast join and bind,
> and I produced a new patch:
> http://roundup.mplayerhq.hu/roundup/ffmpeg/msg2250
> but it seems that there was no useful conclusion. You have windows skills,
> so I guess you can understand what's going on, and propose a correct fix ;-)
>
>
>                        Thanks,
>                                Luca
> >
> > Ramiro Polla
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at mplayerhq.hu
> > https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>




More information about the ffmpeg-devel mailing list