[gst-devel] Timeout in rtspsrc

Marco Ballesio gibrovacco at gmail.com
Tue Feb 15 09:11:34 CET 2011


Hi,

good that you found a solution, just a few more comments from me below..

On Tue, Feb 15, 2011 at 3:55 AM, Thierry Panthier
<thierry.devel at gmail.com> wrote:
> Hi Marco,
>
> After a few hours debugging the application and analyzing packets with
> Wireshark I finally found the source of the problem.
>
> The RTCP timeout (5s) works as expected and an EOS message is posted
> on the bus to notify that the source has timed out.

right, the "on-bye-timeout" signal from GstRtpBin is intercepted from
the GstRtspSrc using it and converted to EOS here:

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c#n2279

So if you're interested about the RTCP timeout, you'd only have to
wait for the EOS.

>
> However 'rtspsrc' has two other parameters - "tcp-timeout" and "retry"
> - which are set to a very high value by default.

Are you using TCP as transport, instead of UDP? In such a case you may
not need RTCP at all (just wait for the TCP disconnection).

>
> tcp-timeout : Fail after timeout microseconds on TCP connections (0 = disabled)
>                   flags: readable, writable
>                   Unsigned Integer64. Range: 0 -
> 18446744073709551615 Default: 20000000 Current: 20000000
>
> retry           : Max number of retries when allocating RTP ports.
>                   flags: readable, writable
>                   Unsigned Integer. Range: 0 - 65535 Default: 20 Current: 20
>
> So even though the absence of the sender is detected by 'rtpbin'
> within 5s, 'rtspsrc' enters this retry cycle with a long TCP timeout
> and consequently my application takes minutes to respond.

depending on the degree of reliability you need (and on the resources
the network you use can make available for your case) it might be a
good solution to go forward with TCP. In case you don't really need
it, I still suggest to use UDP and the usual RTCP handling.

>
> The best way to simulate all different scenarios was by using
> 'iptables' to block RTP, RTCP and then finally RTSP packets (simple
> port based filtering).

yup, good approach (for simulation of failures/firewalls)!

Regards

>
> Thanks for your help!
>
> Thierry
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



More information about the gstreamer-devel mailing list