Detecting that the sender has stopped talking to UDPSRC

[Federico Zamperini]

UDP is a connectionless protocol, so the only way to be sure that the 
sender deliberately stopped sending data is to use another channel (a 
UDP message -- unreliable -- or a TCP channel, as RTSP does).
On the other hand, the way you do is good to detect (possibily 
temporary) network failure.
I don't rememeber I ever received an error message on the bus while 
experimenting with udpsrc and network disconnection, though; but I used 
an identity element (with its hand-off signal), not a probe (and added a 
configurable timer to alert when no data arrived in the given interval).
BTW: where do you get the sender ip address?

Federico


Il 22/02/2013 15:39, Wes Miller ha scritto:
> My pipeline is the example receiver pipe for rtpbin from the 1.0 examples,
> converted to 0.10 and coded with a c++ gst_parse_launch() and gstrtpbin.
>
> environment is:                     Windows-XP, VC++ gstreamer 0.10,
> but it'll also need to work on:  Ubuntu 12.04, eclipse, gcc., gstreamer 0.10
>
> How do I detect that the sender has stopped sending, i.e. data has stopped
> flowing into my udpsrc? By this I mean that the sender has lost connection
> to me.  Sending me silence is ok.
>
> I have a bus message handler and added a buffer probe on udpsrc::src. Work
> great despite the parse-launch which I know is less than a perfect method.
>
> When I start my remote sender I get a buffer-probe message (the first one I
> get) telling me data has passed through the port.  For the first frame this
> alerts me that receiving has started and tells me who the sender is, IP and
> port.  Thereafter I get a flood of probe messages, one per received packet.
>
> When I stop the sender I get a bus error saying that the udpsrc has reported
> am "Internal data flow error.". The corresponding error code is 1 (I htink).
> What it really means is that the sender stopped talking, broke the
> connection and my pipeline is going to die.
>
> Certainly, I can test for this set of conditions, but are they a reliable
> indicator that the sender is no longer talking or could they happen for some
> other reason? Is there a probe of some sort that explicitly tells me that
> data (audio in my case) has stopped arribing?
>
>
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Detecting-that-the-sender-has-stopped-talking-to-UDPSRC-tp4658724.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel