udpsrc multicast sockets ignoring multicast IP

[Tim]

Hi all,

In previous posts I've described behavior where we have a multicast pipeline
using rtspsrc.  We have multiple pipelines running in a single process to be
able to record video/audio from multiple sources.  We noted that frequently
we are seeing SSRC value changes in the RTP session that did not come from
the video/audio source and were trying to understand how that could have
happened.

It turns out that our video/audio sources are using different multicast IP
addresses per source, but all using the same port for their audio RTP stream
and all using the same port for the video RTP stream (e.g. source 1 using IP
address A and port X for video and Y for audio and source 2 using IP address
B and port X for video and Y for audio).  From all of my reading this should
not be a problem, but we are seeing the sockets for each pipeline picking up
RTP payloads from others causing the SSRC change, upstream pad creation,
etc.  Making each video source and audio source use a unique port number
resolved the issue.

Should udpsrc be using IP address/port combo during socket creation?

Thank you for all of your help.

-Tim





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mercredi 25 septembre 2019 à 09:15 -0500, Tim a écrit :

> Hi all,
>
> In previous posts I've described behavior where we have a multicast pipeline
> using rtspsrc.  We have multiple pipelines running in a single process to be
> able to record video/audio from multiple sources.  We noted that frequently
> we are seeing SSRC value changes in the RTP session that did not come from
> the video/audio source and were trying to understand how that could have
> happened.
>
> It turns out that our video/audio sources are using different multicast IP
> addresses per source, but all using the same port for their audio RTP stream
> and all using the same port for the video RTP stream (e.g. source 1 using IP
> address A and port X for video and Y for audio and source 2 using IP address
> B and port X for video and Y for audio).  From all of my reading this should
> not be a problem, but we are seeing the sockets for each pipeline picking up
> RTP payloads from others causing the SSRC change, upstream pad creation,
> etc.  Making each video source and audio source use a unique port number
> resolved the issue.
>
> Should udpsrc be using IP address/port combo during socket creation?

Multicast registration is system wide, so in many cases, all socket
receives packets from random stream. We have code that drop the
irrelevant packets, though I don't know enough of the details to
explain why things don't get filtered out properly for you case.

>
> Thank you for all of your help.
>
> -Tim
>
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim]

Thank you for engaging Nicolas!  What additional details could I provide you
to assist?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mercredi 25 septembre 2019 à 10:04 -0500, Tim a écrit :
> Thank you for engaging Nicolas!  What additional details could I provide you
> to assist?

Best I can do is provide the link to relevant code:

https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/gst/udp/gstudpsrc.c#L910

There is not much traces there, so you will likely have to add some
traces to figure-out what's missing.

>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel