[FFmpeg-devel] rtsp.c udp_read_packet() fails to return when stream ends, simple fix

[Martin Storsjö]

Hi,

On Wed, 24 Mar 2010, Sam Gerstein wrote:

> I've seen this discussed here and there, but not submitted as a patch; it's
> simple enough that I'm proposing it, and hoping someone familiar with the
> module will review and comment.  This solution solves the problem I have,
> but I wonder if it would be problematic in case of, eg. a flaky connection.
> 
> The problem:
> when udp_read_packet calls select() to look for new data on its sockets, it
> only handles the case where some socket signals.  Non-positive return values
> from select() are ignored, ie. timeouts are ignored and the function
> continues to loop looking for data.
> 
> The trivial solution:
> {see patch below}
> 
> Questions:
> -Is there a case where we would like to continue looping when a timeout
> occurs?  a flaky connection?
>   - if so, how about making a fixed number of tries before giving up?
> -Should the timeout be adjusted from its current value of 100ms?

First and foremost - the timeout is used for rechecking url_interrupt_cb() 
regularly, so we can't increase it arbitrarily. Instead, an "end of 
stream" timeout could be checked separately from the select() timeout.

On to the actual probem - do you suggest that not receiving any RTP packet 
for x seconds should be interpreted as end of stream? What would be a 
suitable timeout for this? In order to handle non-perfect network 
conditions, I'd say this should be on the order of tens of seconds? But 
generally, this may be a good idea.

What's the proper way of signalling end of stream, by the way? A quick 
test with DSS here shows that the server sends a RTCP BYE packet and 
closed the RTSP control connection, but this happens only 50-100 seconds 
after the stream finished. An RTCP BYE packet can be missed of course, so 
some kind of timeout probably is a good fallback.

When using RTSP, the control connection may also timeout on the OS level, 
if the connection gets closed/broken, but a timeout for packets received 
may also be a good idea. And for a pure RTP stream initialized from a 
local SDP file, there's no control connection, so this would be needed 
indeed.

// Martin