GStreamer-devel

Timeout in rtspsrc

Classic

List

Threaded

8 messages Options

Thierry Panthier

Timeout in rtspsrc

Hi,

I'm using rtspsrc to request video from an IP camera.

Everything works fine in normal conditions however if I unplug the network cable from the camera my pipeline takes several minutes to timeout.

This is the error message I get minutes later:

code = 7

domain = gst-resource-error-quark

error = Could not open resource for reading and writing.

debug = gstrtspsrc.c(3839): gst_rtspsrc_loop_udp (): /GstPipeline:RTSPPlayer/GstRTSPSrc:rtspsrc9:

Could not connect to server. (System error: Connection refused)

I've gone through the documentation of rtspsrc but there's no way to specify a timeout for RTP packets. Could someone tell me the best way to detect the absence of data in the pipeline? It doesn't necessarily have to be on rtspsrc. I just need a way to quickly detect that the pipeline is not handling any data.

Regards,

Thierry

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Marco Ballesio

Re: Timeout in rtspsrc

Hi,

On Tue, Feb 8, 2011 at 9:37 AM, Thierry Panthier
<[hidden email]> wrote:

> Hi,
> I'm using rtspsrc to request video from an IP camera.
> Everything works fine in normal conditions however if I unplug the network
> cable from the camera my pipeline takes several minutes to timeout.
> This is the error message I get minutes later:
>    code = 7
> domain = gst-resource-error-quark
>    error = Could not open resource for reading and writing.
>   debug = gstrtspsrc.c(3839): gst_rtspsrc_loop_udp ():
> /GstPipeline:RTSPPlayer/GstRTSPSrc:rtspsrc9:
> Could not connect to server. (System error: Connection refused)
> I've gone through the documentation of rtspsrc but there's no way to specify
> a timeout for RTP packets.

as you're likely using UDP as transport layer, RTP packets cannot be
timed out (yes, it's an unreliable protocol). RTCP can help you here,
as you'd just need to enable it and listen for (missing) Sender
Reports, translated in "on-ssrc-active" signals from the session
element in the GstRtspSrc (which is usually a GstRtpBin).

Could someone tell me the best way to detect the
> absence of data in the pipeline? It doesn't necessarily have to be on
> rtspsrc. I just need a way to quickly detect that the pipeline is not
> handling any data.

RTCP packets are (usually) sent with intervals of 5s. If you want
something faster, you can install a data probe somewhere in the pipe
resetting a timeout each time a buffer transits through the pad. When
the timer triggers, then a timeout occurred and you can unilaterally
terminate the communication.

Regards

> Regards,
> Thierry
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>

Thierry Panthier

Re: Timeout in rtspsrc

Hi Marco,

Sorry I didn't make myself clear. You were right I'm actually looking
for a way to handle the RTCP timeout for a specific SSRC.

> as you're likely using UDP as transport layer, RTP packets cannot be
> timed out (yes, it's an unreliable protocol). RTCP can help you here,
> as you'd just need to enable it and listen for (missing) Sender
> Reports, translated in "on-ssrc-active" signals from the session
> element in the GstRtspSrc (which is usually a GstRtpBin).

The problem is that the rtspsrc bin does not have this signal. And if
I try to connect to it I get:

TypeError: <__main__.GstRTSPSrc object (rtspsrc0) at
0x919beb4>: unknown signal name: on-ssrc-active

The rtspsrc documentation says it is built on top of gstrtpbin but how
do I get access to it?

If could simply have access to the signals "on-ssrc-active" and
"on-timeout" that would be great.

However if the implementation does not allow me to do that then I
would like to know if it is possible to add an element to my bin to
detect a "frozen stream". I've gone through all the options given by
gst-inspect but couldn't find anything useful.

> RTCP packets are (usually) sent with intervals of 5s. If you want
> something faster, you can install a data probe somewhere in the pipe
> resetting a timeout each time a buffer transits through the pad. When
> the timer triggers, then a timeout occurred and you can unilaterally
> terminate the communication.

5s for me it's good enough for my application.

Thanks in advance,

Thierry

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Marco Ballesio

Re: Timeout in rtspsrc

Hi,

On Wed, Feb 9, 2011 at 1:41 AM, Thierry Panthier
<[hidden email]> wrote:

> Hi Marco,
>
> Sorry I didn't make myself clear. You were right I'm actually looking
> for a way to handle the RTCP timeout for a specific SSRC.
>
>> as you're likely using UDP as transport layer, RTP packets cannot be
>> timed out (yes, it's an unreliable protocol). RTCP can help you here,
>> as you'd just need to enable it and listen for (missing) Sender
>> Reports, translated in "on-ssrc-active" signals from the session
>> element in the GstRtspSrc (which is usually a GstRtpBin).
>
> The problem is that the rtspsrc bin does not have this signal. And if
> I try to connect to it I get:
>
> TypeError: <__main__.GstRTSPSrc object (rtspsrc0) at
> 0x919beb4>: unknown signal name: on-ssrc-active
>
> The rtspsrc documentation says it is built on top of gstrtpbin but how
> do I get access to it?

it's not possible to get such a signal from the rtspsrc, which is just
a specialised bin (see here to believe:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rtspsrc.html).

As you already suspect, it's instead possible to get such a signal
from the GstRtpBin used as a manager (I'm sorry I mistakenly wrote
"session" earlier, but it's actually possible to do the same with the
GstRtpSession element) inside the RtspSrc. You can get it through the
GstBin api:

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstBin.html

Basically, iterate through the children and get the one instantiating
a GstRtpBin. A more quick-and-dirty way would be to use
gst_bin_get_by_name and something like "rtpbin0" for the name.

Regards

>
> If could simply have access to the signals "on-ssrc-active" and
> "on-timeout" that would be great.
>
> However if the implementation does not allow me to do that then I
> would like to know if it is possible to add an element to my bin to
> detect a "frozen stream". I've gone through all the options given by
> gst-inspect but couldn't find anything useful.
>
>> RTCP packets are (usually) sent with intervals of 5s. If you want
>> something faster, you can install a data probe somewhere in the pipe
>> resetting a timeout each time a buffer transits through the pad. When
>> the timer triggers, then a timeout occurred and you can unilaterally
>> terminate the communication.
>
> 5s for me it's good enough for my application.
>
>
> Thanks in advance,
>
> Thierry
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

Thierry Panthier

Re: Timeout in rtspsrc

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.

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

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.

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).

Thanks for your help!

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

Marco Ballesio

Re: Timeout in rtspsrc

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
<[hidden email]> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Wim Taymans

Re: Timeout in rtspsrc

In reply to this post by Thierry Panthier

On 02/15/2011 02:55 AM, Thierry Panthier 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.
>
> However 'rtspsrc' has two other parameters - "tcp-timeout" and "retry"
> - which are set to a very high value by default.
>
> 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.

There are many ways the sender can 'disappear':

1) it is not sending RTP packets anymore. This is detected by rtpbin
using the
regular RTP timeout mechanisms (which is 5 times the deterministic RTCP
reporting interval or about 25 seconds).

2) the server closes the RTSP TCP connection. If there is still RTP
traffic going on,
this is allowed by the RTSP spec and the client will try to reconnect
when it needs
to.

The 'retry' property on rtspsrc has nothing to do with this, it's just
the amount of
attempts it does to allocate two udp ports.

Wim

> 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).
>
> Thanks for your help!
>
> Thierry
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

Thierry Panthier

Re: Timeout in rtspsrc

> The 'retry' property on rtspsrc has nothing to do with this, it's just the
> amount of
> attempts it does to allocate two udp ports.

Oops... true! Sorry for that.

As for the transport layer I'm using UDP. Everything is fine now. All
I had to do was set the tcp-timeout to 3s to make it more responsive
when starting up. I know it's very short but we're running everything
in a local 100Mbps network so if four TCP SYNs are not enough to get a
connection, then the application shouldn't even bother trying any
longer.

Regards,

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