RTSP (and SDP) client timeout is hard-coded to 10 seconds

[Jack Jansen]

Summary of the bug:

The timeout while waiting for UDP packets in response to opening an RTSP url or SDP file is hard-coded to 10 seconds (the MAX_TIMEOUTS define in rtsp.c). This makes it impossible to decode RTP streams that are intermittently active. It would be good if the hard-coded time out was replaced either by a ?timeout=NNNNN construct, as for UDP reception, or by an AVOption.

The current behaviour is great for TCP-failover in case there is no UDP connectivity, but not good for receiving intermittent streams.

How to reproduce:

open any SDP file for which there are currently no incoming packets.

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Carl Eugen Hoyos]

Reproducible with an invalid sdp file like the following:

v=0
o=- 22714557 1 IN IP4 127.0.0.1
s=123123
t=0 0
m=audio 1234 RTP/AVP 100
c=IN IP4 192.168.1.34
a=rtcp:9 IN IP4 0.0.0.0
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:100 opus/48000/2

Patch sent.

[Andriy Gelman]

should be fixed by commit ​92c40ef882be115e72d2aa02f9032b7ce88f8537